This API bug was relying on the UI purposed TaskRunner to bubble up an
insufficient funds error to the client, but it cannot do that.
This change blocks the takeoffer attempt if sufficient funds are not
found after the swap model calculates the taker's trade amounts.
Related: https://github.com/bisq-network/bisq/pull/6221
Based on https://github.com/bisq-network/bisq/pull/6250.
Based on branch `add-api-price-service-getaverageprice`.
Returns volume weighted average BSQ price in BTC and USD over N days.
The need for this arose while creating a Java BSQ Swap bot example
(PR pending). API bots can use this to determine whether or not to
take swap offers based on their price distance above or below the 30
(or 90) day trade price average.
Returns name of the BTC network API daemon is connected to.
I am working on some Java bot examples in another repo, and want to stop
worrying about accidentally simulating trade payments on mainnet, despite
all the warnings I add in comments. The 'getnetwork' method allows bots
to know what network the API daemon is connected to, and gives API bot
devs and users a way to avoid one potential source of costly mistakes.
API CLI manpage and apitest case are included in this commit.
incremente subaddress index at the start of the trade
Add subaccounts
Rename XmrAccountHelper to XmrAccountDelegate
Add map as final non null value
Persist subaccounts in User
Add display of used subaddresses and tradeId in account summary.
Main address and account index are the unique key for sub accounts.
Use the initial subaddress chosen by the user.
chimp1984 code review patch.
News badge/info for Account, disable old ones.
Show XMR subaddress popup info at Account (news badge), not startup.
Don't depend on silent, UI purposed task runner errors if confirmpaymentstarted
or confirmpaymentreceived msgs are sent outside the proper context.
Throw a FailedPreconditionException instead, and it will be translated
into the proper gPRC StatusRuntimeException before being sent to client.
For BTC buyers and sellers, block the messaging attempt if the taker
deposit tx has not been confirmed.
For BTC sellers, block an attempt to send a confirmpaymentreceived message
until after receiving a confirmpaymentstarted message has been sent from
the buyer.
This API bug was relying on offer availability checks, but those do
not check the taker's wallet. The take offer model makes the check convenient,
and a core.api NotAvailableException can be thrown from CoreTradesService,
then mapped to the appropriate gPRC UNAVAILABLE exception sent to clients.
A new test case is added for this change: Bob's wallet is emptied, he
fails to take an offer, and Alice returns Bob's BTC.
This is causing erroneous PRICE_OUT_OF_TOLERANCE errors when trying
to take offers having (fixed) price!=0, and isUsingMktPriceMargin=true
in the payload.
The API daemon editoffer's treatment of (fixed) price and
isUsingMktPriceMargin flag in the API has been inconsistent with the UI.
With this change: when isUsingMktPriceMargin=true, (fixed) price is
set to 0 on the server. API clients, however, still must show the
calculated price when isUsingMktPriceMargin=true, making this fix hard
to test in the client. The server will now throw an exception if
(fixed) price and isUsingMktPriceMargin flag in the API are not
properly set in the API server.
This fix is intended to prevent issues such as
https://github.com/bisq-network/bisq/issues/6170 from happening for
this reason. The offer maker edited offers with API, creating
inconsistent state described above. It is hoped the user's offers
can be fixed by editing them in the UI.
Based on `master`.
