-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API XMR/BTC trading pair support (#6) #5893
Conversation
V1 offer instances have a makeFee value, but not BSQ swap offers. This needs to be investigated. See commit d57d6e9.
This makes it easier to compare to EditOfferValidator.toString
The editoffer validation bug fixes: - A trigger-price edit forced offer.price-margin=0.00. This needs to be checked in new apitest case asserts. - An activate state (only) edit forced offer.isUseMarketBasedPrice=true. The CLI does not have the offer instance, and cannot know the correct value of the isUseMarketBasedPrice param sent in the editoffer request. The daemon has to figure this out. If the editType parameter value sent to daemon is ACTIVATION_STATE_ONLY, use the current offer.isUseMarketBasedPrice. The refactoring includes more useful and readable information in core's EditOfferValidator and MutableOfferPayloadFields toString methods, for debugging with the daemon log. And some adjustments for allowing edits to XMR offers.
There are no asserts, but helpful for looking at affects of CLI commands from terminal because apitest cases use gRPC service stubs instead of terminal.
Method tests are combined in scenario pkg tests to reduce test harness startup/shutdown time.
I just went through the scenarios of creating an XMR account and executed a successful trade. Here are my comments as an API user.
Trading processEverything worked as expected I only recognized this time that using the
Maybe adding another column with trade state? |
At the time I thought abbreviating the param name was a good idea, but it was not. I should make it consistent and change it to |
This is confusing and seemingly unnecessary to API users, but if it is not done, the completed trade will not be moved from the pending/open trades list (persistence file), to the closed trades list (persistence file). I am almost certain there is a keep funds button click required as the last step in the UI / protocol. (The alternative last step in the UI is to move-funds-to-external-wallet.) The |
@ghubstan Any thoughts on this as well? |
Not yet. I hope to have some thought-time later today. |
@ripcurlx, do you agree a resolution of this issue deserves its own PR? |
@ripcurlx, do you agree the resolution of this issue deserves its own PR? |
@ripcurlx, I agree this should have been added to the api docs long ago. Do you agree a resolution of this issue deserves its own PR? |
I need to think about this for awhile... I would like to make a "another column with trade state" adjustment in another PR that simply removes the This suggestion would mean a diff from UI: the closing out of a trade cannot be followed up in the API by the UI analog's What do you think of that? |
Yes, I think that is what @jmacxx implemented here as well: #5870 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK - I agree to move the rest into separate PRs.
New API features:
Testing new API XMR support, docs:
Based on PR #5876