Implement simplest possible trading script #4257
Comments
|
@cbeams, These method names are not well thought out, and I'll work on improving them. I will also stub out some of the new endpoints in branch rpc-wallet-protection+scratch, or a new branch based on master, if you merge PR 4214 before you go no break. Have a good long break. |
|
Thanks, @ghubstan. Please see my comments about this in the video I just posted at keybase://chat/bisq#grpc-api/657 |
@cbeams , You may have already turned into a pumpkin, but here's my feedback regarding the video. I'm OK with switching from a gRPC to REST API if that's what will be needed to get Bisq into I'll study the :daemon readiness problem, and work on the this issue while you're away -- keeping in mind what you talked about in the recording. |
This addresses task #1 in issue bisq-network#4257. This new gRPC WalletService method displays the BTC wallet's list of receiving addresses. The balance and number of confirmations for the most recent transaction is displayed to the right of each address. Instead of returning a gRPC data structure to the client, the service method returns a formatted String. If the BTC wallet has no unused addresses, one will be created and included in the returned list, and it can be used to fund the wallet. The new method required injection of the BtcWalletService into CoreWalletsService, and the usual boilerplate changes to grpc.proto, CliMain, and GrpcWalletService. Some of the next PRs (for bisq-network#4257) will require some common functionality within CoreWalletsService, so these additional changes were included: * a private, class level formatSatoshis function * a public getNumConfirmationsForMostRecentTransaction method * a public getAddressBalance method * a private getAddressEntry method A unit test that verifies a successful return status was added to cli/test.sh.
This addresses task 2 in issue 4257 bisq-network#4257 This new gRPC Wallet service method displays the balance and number of confimirmations of the most recent transaction for the given BTC wallet address. The new method required the usual boilerplate changes to grpc.proto, CliMain, and GrpcWalletService. Two unit tests to check error msgs was added to cli/test.sh.
This addresses task 4 in issue 4257.
bisq-network#4257
This PR should be reviewed/merged after PR 4304.
bisq-network#4304
This new gRPC Wallet service method creates a dummy PerfectMoney
payment account for the given name, number and fiat currency code,
as part of the required "simplest possible trading API" (for demo).
An implementation supporting all payment methods is not in the
scope.
Changes specific to the new rpc method implementation follow:
* New createpaymentacct method + help text was added to CliMain.
Help text formatting was also changed to make room for larger
method names and argument lists.
* The PaymentAccount proto service def was renamed PaymentAccounts
to avoid a name collision, and the new rpc CreatePaymentAccount
was made part of the newly named PaymentAccounts service def.
* New GrpcPaymentAccountsService (gRPC boilerplate) and
CorePaymentAccountsService (method implementations) classes were
added.
* The gRPC GetPaymentAccountsService stub was moved from GrpcServer
to the new GrpcPaymentAccountsService class, and
GrpcPaymentAccountsService is injected into GrpcServer.
* A new createpaymentacct unit test was added to the bats test
suite (checks for successful return status code).
Maybe bit out of scope, some small changes were made towards making
sure the entire API is defined in CoreApi, which is used as a
pass-through object to the new CorePaymentAccountsService. In the
next PR, similar refactoring will be done to make CoreApi the
pass-through object for all of the existing CoreWalletsService
methods. (CoreWalletsService will be injected into CoreApi.)
In the future, all Grpc*Service implementations will call core
services through CoreApi, for the sake of consistency.
This addresses task 4 in issue 4257.
bisq-network#4257
This PR should be reviewed/merged after PR 4304.
bisq-network#4304
This new gRPC PaymentAccounts service method creates a dummy
PerfectMoney payment account for the given name, number and fiat
currency code, as part of the required "simplest possible trading
API" (for demo). An implementation supporting all payment
methods is not in the scope.
Changes specific to the new rpc method implementation follow:
* New createpaymentacct method + help text was added to CliMain.
Help text formatting was also changed to make room for larger
method names and argument lists.
* The PaymentAccount proto service def was renamed PaymentAccounts
to avoid a name collision, and the new rpc CreatePaymentAccount
was made part of the newly named PaymentAccounts service def.
* New GrpcPaymentAccountsService (gRPC boilerplate) and
CorePaymentAccountsService (method implementations) classes were
added.
* The gRPC GetPaymentAccountsService stub was moved from GrpcServer
to the new GrpcPaymentAccountsService class, and
GrpcPaymentAccountsService is injected into GrpcServer.
* A new createpaymentacct unit test was added to the bats test
suite (checks for successful return status code).
Maybe bit out of scope, some small changes were made towards making
sure the entire API is defined in CoreApi, which is used as a
pass-through object to the new CorePaymentAccountsService. In the
next PR, similar refactoring will be done to make CoreApi the
pass-through object for all of the existing CoreWalletsService
methods. (CoreWalletsService will be injected into CoreApi.)
In the future, all Grpc*Service implementations will call core
services through CoreApi, for the sake of consistency.
This addresses task 4 in issue 4257.
bisq-network#4257
This PR should be reviewed/merged after PR 4304.
bisq-network#4304
This new gRPC PaymentAccounts service method creates a dummy
PerfectMoney payment account for the given name, number and fiat
currency code, as part of the required "simplest possible trading
API" (for demo). An implementation supporting all payment
methods is not in the scope.
Changes specific to the new rpc method implementation follow:
* New createpaymentacct method + help text was added to CliMain.
Help text formatting was also changed to make room for larger
method names and argument lists.
* The PaymentAccount proto service def was renamed PaymentAccounts
to avoid a name collision, and the new rpc CreatePaymentAccount
was made part of the newly named PaymentAccounts service def.
* New GrpcPaymentAccountsService (gRPC boilerplate) and
CorePaymentAccountsService (method implementations) classes were
added.
* The gRPC GetPaymentAccountsService stub was moved from GrpcServer
to the new GrpcPaymentAccountsService class, and
GrpcPaymentAccountsService is injected into GrpcServer.
* A new createpaymentacct unit test was added to the bats test
suite (checks for successful return status code).
Maybe bit out of scope, some small changes were made towards making
sure the entire API is defined in CoreApi, which is used as a
pass-through object to the new CorePaymentAccountsService. In the
next PR, similar refactoring will be done to make CoreApi the
pass-through object for all of the existing CoreWalletsService
methods. (CoreWalletsService will be injected into CoreApi.)
In the future, all Grpc*Service implementations will call core
services through CoreApi, for the sake of consistency.
|
Can we consider not using Bitcoin Core's convention for API naming withoutanyspacesorcapitalization? It's a pain to read and to write too, because it's hard to spot a typo. I suggest using_snake_case_which_means_putting_underscores_where_spaces_would_be. Before someone suggests CamelCase, while it would be just like writing Java, I would be against it, because its space economy leads to some awkward reading as well: LikeWhenThereIsAShortWordInTheName. |
|
I'd recommend holding off on such a change until closer to an initial release, and to think really carefully about it. The reason for mimicking Bitcoin Core is not because all lower case is necessarily best, but because it is perhaps most familiar to people in this space, and more likely to "feel right" to someone working with Bitcoin Core a lot. If we were to follow more general *nix command line utility conventions, I'd recommend kebab case, e.g. the way many unix utilities are named, e.g. Note that it could also be (not now, later) that we choose to go with a more sophisticated approach to the cli involving subcommands, e.g. So again, my 2 sats are to just hold off for now and let the continuing implementation inform the final design. Make this change once, later, when we're more confident about it, ideally with some real world users having tried things out and given some feedback. HTH. |
This addresses task 5 in issue 4257 bisq-network#4257 This new gRPC PaymentAccounts service method displays the user's saved payment accounts. A unit test to check a successful return status code was added to cli/test.sh. This PR should be reviewed/merged after PR 4322. bisq-network#4322
This addresses task bisq-network#1 in issue bisq-network#4257. This new gRPC WalletService method displays the BTC wallet's list of receiving addresses. The balance and number of confirmations for the most recent transaction is displayed to the right of each address. Instead of returning a gRPC data structure to the client, the service method returns a formatted String. If the BTC wallet has no unused addresses, one will be created and included in the returned list, and it can be used to fund the wallet. The new method required injection of the BtcWalletService into CoreWalletsService, and the usual boilerplate changes to grpc.proto, CliMain, and GrpcWalletService. Some of the next PRs (for bisq-network#4257) will require some common functionality within CoreWalletsService, so these additional changes were included: * a private, class level formatSatoshis function * a public getNumConfirmationsForMostRecentTransaction method * a public getAddressBalance method * a private getAddressEntry method A unit test that verifies a successful return status was added to cli/test.sh.
This addresses task 2 in issue 4257 bisq-network#4257 This new gRPC Wallet service method displays the balance and number of confimirmations of the most recent transaction for the given BTC wallet address. The new method required the usual boilerplate changes to grpc.proto, CliMain, and GrpcWalletService. Two unit tests to check error msgs was added to cli/test.sh.
This addresses task 4 in issue 4257.
bisq-network#4257
This PR should be reviewed/merged after PR 4304.
bisq-network#4304
This new gRPC PaymentAccounts service method creates a dummy
PerfectMoney payment account for the given name, number and fiat
currency code, as part of the required "simplest possible trading
API" (for demo). An implementation supporting all payment
methods is not in the scope.
Changes specific to the new rpc method implementation follow:
* New createpaymentacct method + help text was added to CliMain.
Help text formatting was also changed to make room for larger
method names and argument lists.
* The PaymentAccount proto service def was renamed PaymentAccounts
to avoid a name collision, and the new rpc CreatePaymentAccount
was made part of the newly named PaymentAccounts service def.
* New GrpcPaymentAccountsService (gRPC boilerplate) and
CorePaymentAccountsService (method implementations) classes were
added.
* The gRPC GetPaymentAccountsService stub was moved from GrpcServer
to the new GrpcPaymentAccountsService class, and
GrpcPaymentAccountsService is injected into GrpcServer.
* A new createpaymentacct unit test was added to the bats test
suite (checks for successful return status code).
Maybe bit out of scope, some small changes were made towards making
sure the entire API is defined in CoreApi, which is used as a
pass-through object to the new CorePaymentAccountsService. In the
next PR, similar refactoring will be done to make CoreApi the
pass-through object for all of the existing CoreWalletsService
methods. (CoreWalletsService will be injected into CoreApi.)
In the future, all Grpc*Service implementations will call core
services through CoreApi, for the sake of consistency.
This addresses task 5 in issue 4257 bisq-network#4257 This new gRPC PaymentAccounts service method displays the user's saved payment accounts. A unit test to check a successful return status code was added to cli/test.sh. This PR should be reviewed/merged after PR 4322. bisq-network#4322
|
Suggestions on improving the format of |
ghubstan
changed the title
|
All functionality required for a simplest possible trading script was merged in PRs before and including #4966. Work on scripts is in progress. |
ghubstan
changed the title
This is a work in progress, but when done, will resovle issue bisq-network#4257.
|
Issue will be closed when #5093 is merged. |
ghubstan
changed the title
|
Hey, great to see this merged. Quick question: would it be possible to write an alternative UI using this API? I'm mainly interested in having UI running on desktop detached from backend running on server, not changing the contents of the UI. |
I can't say absolutely not, but it would be weird. The api does not yet support all features of the Bisq desktop, and the api's server only works with the If there is good adoption of the api after a louder release -- and it is stable, works and scales -- there is a good chance the back-end will be modified to serve RESTful HTTP 1.1 clients. When and if that happens would be the time start building alternative UIs. |
|
Thanks for the answer! This is not urgent and I'm not concerned with gRPC vs REST - anything would work for me. Having all required APIs and a headless server is more important. |
I meant to say REST clients "too". But there will have to be consensus among devs about how. It will be awhile... |
|
AFAIK REST can be auto-generated from gRPC spec (I believe LND does this), not sure about the details, so that way shouldn't be too difficult. Anyway, no rush, a few months is completely fine for me. If my priorities change there's a good chance I will contribute to it myself, will let you know if it happens. |
Here is an experiment I did with a reverse proxy https://github.com/ghubstan/bisq-grpc-gateway. |
After implementing rpc wallet protection methods (ISSUE 4214 + PR 4214), we need a minimum set of endpoints to enable trading from the gRPC API, and a bats script for test / demo purposes.
The goal of the set of PRs that will accompany this issue is to allow a user to perform all of the following functions with the gRPC API (the UI should not be needed for any setup).
Get Funding Addresses
Method Signature:
getfundingaddressesShow existing unused BTC addresses in the wallet.
If there are no unused addresses in the wallet, the server will create one.
Analog to bitcoin-cli method getnewaddress
Get Address Balance
Method Signature:
getaddressbalance addressShow BTC balance for given address in the wallet, with number of confirmations of the most recent transaction included. (TODO Show list of txIds included as well?)
Analog to bitcoin-cli method listreceivedbyaddress
Fund a BTC wallet
No new method is needed to fund a wallet. User sends BTC from an external wallet to a Bisq "Fund your wallet" address, then awaits confirmations.
Use Case:
* User finds an unused funding address by calling
getfundingaddresses.* User sends BTC via
bitcoin-cli sendtoaddress "addr" amt.* User polls status of the funding TX by calling
getaddressbalance addressand/orgetbalance.Create a Payment Account
Method Signature:
createpaymentacct acct-name paymentmethod acct-number currency(The different payment methods will have different attributes, the above signature is specific to PerfectMoney)
In the interest in keeping it simple at this stage, the 1st impl can only create a "PerfectMoney dummy" account, mimicking the default payment method created by the UI when running Bisq in regtest / dev mode with the DAO setup used to test every new release.
Get Payment Accounts
Method Signature:
getpaymentacctsShow list of all payment methods created by the user in the UI or
createpaymentacct. The returned id is a required parameter of thecreateoffermethod.Get Existing Offers
Method Signature:
getoffers buy | sell, currencyOutput would display same info as UI's Offer Book, plus a unique identifier to be used in
a
takeoffermethod.Create Offer
Method Signature:
createoffer buy|sell [TBD]BUY Offer Parameters:
payment-method amt currency pct-from-mkt-price min-amt [pct-sec-deposit]SELL Offer Parameters:
payment-method amt currency pct-from-mkt-price min-amt [pct-sec-deposit]Note: there may be differences in the non-unique BUY/SELL offer params shown above (todo).
Take Offer
Method Signature:
takeoffer offer-idTaker must have a matching payment-method associated with selected offer.
Funding source defaults to Bisq wallet.
Fee currency defaults to BTC.
(Support for displaying BSQ balance and paying trade fee with BSQ not in scope.)
Get Offer Status
Method Signature:
getofferstatus offer-idDisplays status of offer, including trade protocol steps that have and have not been completed.
Offer creators & takers will see different offer status information, but both will see the same
initial state:
WAITING_FOR_BLOCKCHAIN_CONFIRMATION(of deposit fees)Offer States seen by Takers:
START_PAYMENTWAITING_FOR_PAYMENT_ARRIVALOffer States seen by Creators:
WAITING_FOR_PAYMENTPAYMENT_RECEIVEDNote: there may be some states unique to SELL offer creators/takers and BUY offer creators/takers.
Creators and takers will also see the same final status:
COMPLETED(can move funds)Start Payment
Method Signature:
paymentstarted offer-idCalled by BTC buyers after submitting a payment.
Payment Received
Method Signature:
paymentreceived offer-idCalled by BTC sellers after receiving a payment.
Cancel Offer
Method Signature:
canceloffer offer-idAllow user to cancel an existing offer that has not passed the
START_PAYMENTstage of the trade protocol.Move BTC from completed trades to Bisq BTC wallet
Method Signature:
movefundsMove BTC funds and trade fees to Bisq wallet after a successful trade completion.
Withdraw BTC to an external wallet
Method Signature:
withdrawfunds "addr"Withdraw BTC from Bisq wallet to external BTC address
BATS test script(s) to test and demo end-to-end functionality
The text was updated successfully, but these errors were encountered: