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.
