Skip to content
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

Merged
merged 19 commits into from
Dec 29, 2021

Conversation

ghubstan
Copy link
Member

@ghubstan ghubstan commented Dec 3, 2021

New API features:

  • Create XMR payment accts with API.
  • Create XMR offers with API.
  • Trade XMR using v1 protocol, not swapping.

Testing new API XMR support, docs:

  • Created apitest cases for XMR support.
  • Created XMR/BTC trade simulation script (regtest only).
  • Updated api beta test guide for XMR support.

Based on PR #5876

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.
@ripcurlx
Copy link
Contributor

ripcurlx commented Dec 20, 2021

I just went through the scenarios of creating an XMR account and executed a successful trade. Here are my comments as an API user.

  • createcryptopaymentacct: ☑️
    I think we should add this to the documentation as we do it for createpaymentacct as well. ATM you need to look at simulation scripts to find out how to create altcoin accounts which might be the main use cases for API usage. Maybe we could even just re-use the createpaymentacct method with different parameters to make altcoin accounts a first class citizen.

  • createoffer: ☑️
    Is there a reason why we named the payment account id argument --payment-account and not --payment-account-id? I think it would be more consistent with the other API methods if we would support the argument with ...-id as well. WDYT?

  • editoffer

Trading process

Everything worked as expected I only recognized this time that using the keepfunds command is necessary to complete the trade (or isn't it?), but when just checking the gettrade command there is no change happening. So this might be confusing for API users.

➜  bisq git:(6-api-xmr-trading) ✗ ./bisq-cli --password=mySecret gettrade --trade-id=yfxmel-4f5caead-1ceb-459e-8111-bc5b2f259e42-180
ID      My Role              Price in BTC for 1 XMR  Amount(XMR)  Tx Fee (BTC)  Maker Fee(BSQ)  Deposit Published  Deposit Confirmed  Buyer Cost(BTC)  XMR Sent  XMR Received  Payout Published  Withdrawn  XMR Buyer Address
yfxmel  XMR seller as maker              0.00395772         5.05    0.00002450            0.03  YES                YES                     0.02000000  YES       YES           YES               NO         46tM15KsogEW5MiVmBn7waPF8u8ZsB6aHjJk7BAv1wvMKfWhQ2h2so5BCJ9cRakfPt5BFo452oy3K8UK6L2u2v7aJ3Nf7P2
➜  bisq git:(6-api-xmr-trading) ✗ ./bisq-cli --password=mySecret --port=9998 keepfunds --trade-id=yfxmel-4f5caead-1ceb-459e-8111-bc5b2f259e42-180
funds from trade yfxmel-4f5caead-1ceb-459e-8111-bc5b2f259e42-180 saved in bisq wallet
➜  bisq git:(6-api-xmr-trading) ✗ ./bisq-cli --password=mySecret gettrade --trade-id=yfxmel-4f5caead-1ceb-459e-8111-bc5b2f259e42-180             
ID      My Role              Price in BTC for 1 XMR  Amount(XMR)  Tx Fee (BTC)  Maker Fee(BSQ)  Deposit Published  Deposit Confirmed  Buyer Cost(BTC)  XMR Sent  XMR Received  Payout Published  Withdrawn  XMR Buyer Address
yfxmel  XMR seller as maker              0.00395772         5.05    0.00002450            0.03  YES                YES                     0.02000000  YES       YES           YES               NO         46tM15KsogEW5MiVmBn7waPF8u8ZsB6aHjJk7BAv1wvMKfWhQ2h2so5BCJ9cRakfPt5BFo452oy3K8UK6L2u2v7aJ3Nf7P2

Maybe adding another column with trade state?

@ghubstan
Copy link
Member Author

Is there a reason why we named the payment account id argument --payment-account and not --payment-account-id?
I think it would be more consistent with the other API methods if we would support the argument with ...-id as well. WDYT?

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 --payment-account-id.

@ghubstan
Copy link
Member Author

Everything worked as expected I only recognized this time that using the keepfunds command is necessary to complete the
trade (or isn't it?), but when just checking the gettrade command there is no change happening.
So this might be confusing for API users.

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 keepfunds cmd is consistent with the final step in the UI. I think this needs some more study from both of us before I change it to say... automatically moving completed trade from open-trades list to closed-trades list in the "next to last" step of the protocol.

@ripcurlx
Copy link
Contributor

  • createcryptopaymentacct: ☑️
    I think we should add this to the documentation as we do it for createpaymentacct as well. ATM you need to look at simulation scripts to find out how to create altcoin accounts which might be the main use cases for API usage. Maybe we could even just re-use the createpaymentacct method with different parameters to make altcoin accounts a first class citizen.

@ghubstan Any thoughts on this as well?

@ghubstan
Copy link
Member Author

Any thoughts on this as well?

Not yet. I hope to have some thought-time later today.

@ghubstan
Copy link
Member Author

ghubstan commented Dec 22, 2021

Is there a reason why we named the payment account id argument --payment-account and not --payment-account-id?
I think it would be more consistent with the other API methods if we would support the argument with ...-id as well. WDYT?

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 --payment-account-id.

@ripcurlx, do you agree a resolution of this issue deserves its own PR?

@ghubstan
Copy link
Member Author

Everything worked as expected I only recognized this time that using the keepfunds command is necessary to complete the
trade (or isn't it?), but when just checking the gettrade command there is no change happening.
So this might be confusing for API users.

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 keepfunds cmd is consistent with the final step in the UI. I think this needs some more study from both of us before I change it to say... automatically moving completed trade from open-trades list to closed-trades list in the "next to last" step of the protocol.

@ripcurlx, do you agree the resolution of this issue deserves its own PR?

@ghubstan
Copy link
Member Author

  • createcryptopaymentacct: ballot_box_with_check
    I think we should add this to the documentation as we do it for createpaymentacct as well. ATM you need to look at simulation scripts to find out how to create altcoin accounts which might be the main use cases for API usage. Maybe we could even just re-use the createpaymentacct method with different parameters to make altcoin accounts a first class citizen.

@ghubstan Any thoughts on this as well?

@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?

@ghubstan
Copy link
Member Author

ghubstan commented Dec 22, 2021

Maybe adding another column with trade state?

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 keepfunds and withdrawfunds.

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 keepfunds and withdrawfunds cmds. Completion of a trade always automatically results in trade being moved to closed-trades file, and proceeds being moved (or left in) internal bisq wallet. API users can always use the sendbtc and sendbsq cmds to move funds to external addresses.

What do you think of that?

@ripcurlx
Copy link
Contributor

Maybe adding another column with trade state?

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 keepfunds and withdrawfunds.

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 keepfunds and withdrawfunds cmds. Completion of a trade always automatically results in trade being moved to closed-trades file, and proceeds being moved (or left in) internal bisq wallet. API users can always use the sendbtc and sendbsq cmds to move funds to external addresses.

What do you think of that?

Yes, I think that is what @jmacxx implemented here as well: #5870

@ghubstan ghubstan changed the title API XMR/BTC trading pair support API XMR/BTC trading pair support (#6) Dec 28, 2021
Copy link
Contributor

@ripcurlx ripcurlx left a 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.

@ripcurlx ripcurlx added this to the v1.8.1 milestone Dec 29, 2021
@ripcurlx ripcurlx merged commit d5dc836 into bisq-network:master Dec 29, 2021
@ghubstan ghubstan deleted the 6-api-xmr-trading branch January 3, 2022 12:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants