Use AvailabilityResult.INVALID_SNAPSHOT_HEIGHT instead of AckMessage with error.
Show description in error popup instead of enum name.
Return PRICE_CHECK_FAILED instead of UNKNOWN_FAILURE at error at price check also for non api users.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Add burningManSelectionHeight and tradeTxFee in Dispute.
Call validateDonationAddressMatchesAnyPastParamValues and validateDonationAddress
only if legacy BM was used.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Use BurningManService.getBtcFeeReceiverAddress at createFeeTx tasks.
Verify takers burningManSelectionHeight if BurningManService.isActivated at MakerProcessesInputsForDepositTxRequest and OpenOfferManager.
Stores burningManSelectionHeight in ProcessModel.
Add BurningManService fields to OfferAvailabilityModel, PlaceOfferModel, OpenOfferManager and Provider
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
More restrictive limits will still apply based on payment method.
It is intended to avoid that a new users who do not fully understand
the process of a Bisq trade to cause an arbitration case with high
amounts and therefore higher risks and costs for the DAO.
Explain that the API's getoffer(s) and takeoffer methods only
work as expected when the user's node has payment account/methods
matching the available offers' own payment methods.
- getoffers returns only the offers with payment methods matching
those set up on the user's node
- getoffer will only return the offer if the user's node has a
payment method matching the payment method associated with the
requested offer
- takeoffer will fail if the user's node does not have a matching
payment method
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.
Non-CLI clients need a better way of accessing payment details
than a contract json string.
- Add grpc.proto PaymentAccountPayloadInfo field: payment_details.
- Adjust proto wrapper PaymentAccountPayloadInfo to new field.
- Add test asserts to verify payment details are sent to client.
- Fix a test name: testKeepFunds -> testCloseTrade.
Based on branch `master` @ Sat 12 Mar 2022 01:42 PM -03 ,
commit c6293b5273
- is_fiat_sent -> is_payment_started_message_sent
Payment can be in altcoin.
- is_fiat_received -> is_payment_received_message_sent
Payment can be in altcoin.
- is_withdrawn -> is_completed
Trade can be closed with funds kept in Bisq wallet.
Java client code can still use the camelCase field naming convention,
and other language bindings will not be forced to do the same.
Snake_case field names are also recommended in the Protocol Buffers
Sytle Guide: https://developers.google.com/protocol-buffers/docs/style
This protobuf definition and service stub has been in place since
the start of work on the API, but was never fully implmented, nor
intended to be included in the API beta & v1 releases.
Its presence added a useless section to the gRPC API Reference doc.
https://ghubstan.github.io/slate
Based on branch `7-more-grpcproto-comments`,
PR https://github.com/bisq-network/bisq/pull/6068.
We will consider each problematic number field one at a time.
Note: changing field types in following commits will break
the API's backward compatibility, but devs agree it's OK since
it is still in beta.
This commit adds comments to grpc.proto to be pulled into a new API
reference doc. Some of the comments highlight issues to be resolved
in following PRs.
The main focus is on documenting gRPC Offers service definitions in
grpc.proto:
- Comment each field in the Offers service's messages.
- Add TODO comments about fixing field defs with usability &
consistency problems.
Other API reference doc related changes to grpc.proto:
- Comment each gRPC service's rpc method definitions, however briefly.
- Improve some existing rpc method comments.
Banner comments were replace by simple service description comments.
Rpc methods were commented, some field level comments were moved to
to bisq-grpc-api-doc comment conventions.
The bisq-grpc-api-doc generator needs comments spefic to protobuf
message definitions, not groups of message defs. This kind of
information can be included in the message specific comments.
Also changed some existing comments, and added others to suggest
a commenting style for .proto message and field defs.
