Strip all input witnesses from the depositTx message fields sent from
the buyer, until the last (DelayedPayoutTxSignatureResponse) message is
sent, where they can be bundled in as an extra field. Since the witness
data doesn't affect the final deposit tx id, the seller does not need to
know it until actually publishing the tx.
In the (fully) segwit case, this allows the buyer to prevent the seller
from publishing the deposit tx until the buyer has a valid, fully signed
delayedPayoutTx. Provide the final witness data in an extra 'depositTx'
field in DelayedPayoutTxSignatureResponse, which the seller can merge
with his depositTx witness block (for his own input signatures).
Include a new 'delayedPayoutTxSellerSignature' field with the prepared
delayed payout tx sent to the buyer, in DelayedPayoutTxSignatureRequest.
This will allow the buyer to compute the final, signed delayedPayoutTx
as early as possible and withhold their deposit tx witness from the
seller until they know they have a valid delayedPayoutTx, preventing its
premature publishing in the fully segwit case. (To be done in a later
commit - for now just save the seller's delayedPayoutTx signature.)
As part of this, run the SellerSignsDelayedPayoutTx trade task at an
earlier step (just after payout tx creation) to make its signature
available to the seller ASAP. Also rename 'delayedPayoutTxSignature' to
'delayedPayoutTxBuyerSignature' in DelayedPayoutTxSignatureResponse.
In the CLI, this method now takes a single argument, the path to a json
file (a payment account form). The json text is read from the file
and sent to the server, where it is serialized to a new PaymentAccount
instance, saved, and sent back to the CLI as a protobuf.PaymentAccount.
- Modified existing gRPC boilerplate in grpc.proto and GrpcPaymentAccountsService.
- Modified existing method signatures in CoreApi and CorePaymentAccountsService.
- Replaced existing method impl in CorePaymentAccountsService and
removed dead code.
- Replaced the CLI's existing 'createpaymentacct' method impl.
- Modified existing tests.
Returns a list of supported payment method IDs. This gives CLI users
the correct payment method id for creating a new payment account.
- Added gRPC service GetPaymentMethods to grpc.proto.
- Added gRPC boilerplate method to GrpcPaymentAccountsService.
- Added implimentation to CoreApi -> CorePaymentAccountsService.
- Refactored PaymentAccountTest hierarchy.
- Add api method to CLI.
This change fixes the recently bloated wallet balances api. Now there
is one CLI getbalance [bsq|btc] method that calls a getbalances(currency-code)
on the server. The server returns full wallet balance information for
BSQ, BTC, or both if the CLI's currency argument is absent.
- grpc.proto: Reduced number of getbalance(s) proto services from
four to one.
- GrpcWalletsService: Reduced number of getbalance(s) gRPC service
boilerplate methods from four to one.
- CoreApi, CoreWalletsService: Reduced number of getbalance(s) gRPC
service implementation methods from four to one.
- CliMain: Reduced number of getbalance(s) commands from four to one.
- BalancesInfo: Changed BsqBalanceInfo & BtcBalanceInfo field names
to bsq and btc, respectively, to make calling their accessors
more readable, less verbose.
- BtcBalanceInfo, BsqBalanceInfo: Defined static final EMPTY instances
as place holders in a BalancesInfo returned by the gRPC server, when
one or the other balance types is not requested. Would be nice
to serve Optional.empty() instead, but protobuf does not support
it or null.
- Adjusted affected api tests and build doc.
This change adds proto support for paying maker fees in bsq or btc.
The implementation will come in a future PR.
- Added makerFeeCurrencyCode field to CreateOfferRequest proto.
- Added isCurrencyForMakerFeeBtc field to OfferInfo proto wrapper.
- Add takerFeeCurrencyCode field to TakeOfferRequest proto.
This change adds proto serivces and messages to support new api
implementations for serving bsq, btc or all wallet balances.
- RPC GetBsqBalances will return complete BSQ balance info.
- Message BsqBalanceInfo is proto returned by rpc GetBsqBalances.
- RPC GetBtcBalances wil return complete BTC balance info.
- Message BtcBalanceInfo is proto returned by rpc GetBtcBalances.
- RPC GetBalances returns complete BTC and BSQ balance info.
- Message BalancesInfo is proto returned by rpc GetBalances.
RPC GetBalance remains unchnaged, still returns only the available
BTC balance. It may be deprecated and removed in a future PR.
A service address can be filtered out using the admin key. This would
be useful if a federated server failed, it could be filtered out so
that the auto-confirmation operates with the remaining services. If
all federated service addresses were filtered out the user would have to
either confirm manually or use their own explorer service.
This PR adds trade closing method stubs to keep funds in the
Bisq wallet or send them to an external BTC wallet.
- Add grpc protos
- Add new methods to GrpcTradesService, CoreApi
- Stub out implementations in CoreTradesService
- Add methods to CLI
API users will need to see their role as maker/taker when looking at trade details.
- Add getRole(trade) to TradeUtil.
- Add getTradeRole(tradeId) to CoreApi, CoreTradesService.
- Add role field to TradeInfo proto and its wrapper class.
- Add new core.offer.takeoffer.TakeOfferModel
Would have been nice to move more logic from
bisq.desktop.main.offer.takeoffer.TakeOfferDataModel,
but it has JFX dependencies that cannot be use in :core.
- Add grpc protos to support takeoffer, confirmpaymentsent, confirmpaymentreceived
Only takeoffer is implemented in this commit.
- Refactor OfferInfo grpc proto wrapper, and add offer state field
- Add new TradeInfo grpc proto wrapper
- Implement takeoffer on server and cli side
- Refactor offer/trade tests, add test cases
This will be used for monitoring seed nodes.
Instead of requesting all data (we cannot request all in fact as it is too large)
we request the number of items the node has.
This code will not have any impact atm. It will be triggered once a new monitor module gets added which
will send the GetInventoryRequest to the seeds.
There are a number of use cases where a user may want to see a single
offer instead of every offer for a currency pair on the buy or sell side.
The changes are:
- Add getoffer to grpc.proto
- Add new method to GrpcOffersService, CoreApi, CoreOffersService
- Add new method to CLI
- Adjust create offer tests to use this new convenience
The CreateOfferRequest's price field type was changed from long to string,
so a CLI param like 10000.0055 can be passed to the server as is, to be
scaled and converted there. In general, we want to keep validation logic
on the CLI as simple as possible, and use existing core logic to
validate args and convert arg types when needed.
Add signed witness to PayoutTxPublishedMessage
Remove usage of RefreshTradeStateRequest but leave it for backward compatibility
Move removeMailboxMessageAfterProcessing calls in finally branch
Rename methods
This commit contains most of the changes suggested by @chimp1984 in
his api-suggestions branch. See
961703ecea
A new 'registerdisputeagent' method was also added to MainCli, finishing
the work to support registration of mediators and refund agents on
arbitration daemons running in regtest mode. This method cannot be
used to register dispute agents on mainnet; users will see an error
msg if they try.
to add auto confirm for other currencies in the future. The generic part
is only used where we would have issues with backward compatibility like
in the protobuf objects. Most of the current classes are kept XMR
specific and could be generalized once we add other assets, but that
would be an internal refactoring without breaking any network or
storage data. I think it would be premature to go further here as we
don't know the details of other use cases. I added the methods used from
clients to AutoConfirmResult, not sure if the API is well defined by
that, but as said that could become subject of a future refactoring once
another auto confirm feature gets added. Goal of that refactoring was
to avoid that we need more fields for trade and the the UI would have to
deal with lots of switch cases based on currency.
Sorry that is a larger commit, would have been hard to break up...
instead which stores the stateName. [1]
- Adjust protobuf methods
- Add UNDEFINED to AutoConfirmResult.State to support cases where we
get no data to set the enum.
- Add NO_MATCH_FOUND (used in follow up commits)
- Refactoring: Improve constructors
[1]
Enums in protobuf are not well supported. They are global so an enum
with name (e.g. State) inside Trade conflicts with another enum inside
Message with the same name. So they do not reflect encapsulation in the
class like in java.
We moved over time to the strategy to use strings (from enum.name())
instead of the enum, avoiding also cumbersome fromProto and toProto
code and being more flexible with updates.
The autoConfirmResultState enum inside Trade was a bit confusing to me
as it was a different structure as in the java code. We try to mirror
the structure as far as possible.
If a user has an existing account with phone number or email as
account ID we show a popup at startup where we require that he sets the
user name. This popup has no close button so he is forced to enter a
value. If there are multiple account multiple popups will be shown.
To not break signed accounts we keep accountId as internal id used for signing.
Old accounts get a popup to add the new required field userName but accountId is
left unchanged. Newly created accounts fill accountId with the value of userName.
In the UI we only use userName.
Input validation does only check for length (5-100 chars). Not sure what
are the requirements at Revolut. Can be changes easily if anyone gets
the specs.
Add re-open dispute button to mediation views (not refund agent as
there it might be dangerous if he would close 2 times and pay out twice.
If a dispute was reopened and a message was sent afterwards the receiver
will auto-reopen the dispute as well and the UI shows the number
indicator.
Add search field to traders dispute views.
Fix DisputeMsgEvents which was handling only legacy arbitration cases
and now uses mediation and refund agent. Used to update state in case
the UI is not selected.
Add "send private notification" button for mediators and refund agents.
Add report button for mediators and refund agents
Generates report text of all disputes with more detailed information
which should be used for reporting.
Add "Dump text of all disputes" button for getting a text representation
of all disputes including the messages for mediators and refund agents.
This is not used for report but might be useful for search, etc.
Do not show legacy arbitration tabs (for traders as well for
arbitrators) if no cases available.
Add 5 new enum entries for Reason for dispute:
OPTION_TRADE
SELLER_NOT_RESPONDING
WRONG_SENDER_ACCOUNT,
TRADE_ALREADY_SETTLED,
PEER_WAS_LATE
Hide NO_REPLY, SCAM and PROTOCOL_VIOLATION in UI (still in code if we still
need it and re-activate them).
Add report button:
Generates report text of all disputes with more detailed information
which should be used for reporting.
Add "Dump text of all disputes" button for getting a text representation
of all disputes including the messages. This is not used for report but
might be useful for search, etc.
Do not show legacy arbitration tabs (for traders as well for
arbitrators) if no cases available.
Add 3 new enum entries for Reason for dispute:
OPTION_TRADE
SELLER_NOT_RESPONDING
WRONG_SENDER_ACCOUNT
Hide NO_REPLY and PROTOCOL_VIOLATION in UI (still in code if we still
need it and re-activate them)
Use now the complete object data for signature creation. We use the protobuf data for creating the signature with DER encoding. We restict ourself more regarding backward compatibility but I think it is not a big problem.
If a new field is added to Filter and deployed the maintainer needs to publishes a new filter object. By using the new version he cannot remove the old filter from the network as the protobuf data is different and sig verification on the P2P datastorage level will fail. This is intended to keep the old filter alive for some time to support not updated users. We do not remove invalid filters anymore from our local storage to enable seed nodes to support also old filter objects.
For not updated users the new filter will fail at sig verification because the protobuf data is different. So they ignore the new filter and still use the old filter. For updated users the old filter will fail and the new filter is accepted. As it has a newer date it would also replace the old filter anyway. If the maintainer wants to delete the old filter from the network he can use the old app version and remove the filter. It is recommended to keep a copy of the data directory before the update so that the removal of the older filter is possible.
Refacorings:
- Rename isPeersPaymentAccountDataAreBanned to arePeersPaymentAccountDataBanned
- Rename isSignerPubKeyBanned to isWitnessSignerPubKeyBanned
* XMR seller is prompted to enter txId and viewkey.
* looks up the XMR transaction to verify that it has confirmed
* user can run their own validating service, or use the ones provided
* 100% agreement of all chosen services is necessary for confirmation
* feature can be configured and turned on/off from settings screen
* feature can be globally turned off via admin filter
* two code review passes from chimp1984
* one text review from m52go
Main part missing is the XMR proof service request processing. I did not
get the service compiled yet, so could not test response data and error
conditions.
Further it is missing a "news badge" and popup to guide the user to the
new feature.
Only basic dev tested so far.
Anyone welcome to pick the project up from here as I might not have
time soon to continue.
The new method returns current buy or sell offers for a fiat ccy.
These changes need refactoring and polishing before merging, but they're
committed in this state to be safe (don't lose work). Changes include:
* New core.grpc classes
CoreOffersService
GrpcOffersService
model.OfferInfo
* CoreApi -- The new CoreOffersService is injected into CoreApi and
the old getOffers() and placeOffer() impls were moved into the
new CoreOffersService. The getOffers implementation was re-done.
Other changes are just rearranging location of core method calls.
* GrpcServer -- The new GrpcOffersService replaced the old
GetOffersService and PlaceOfferService.
* grpc.proto -- The old GetOffers and PlaceOffer services were combined
into a single Offers service, and the PlaceOffer rpc was renamed
as CreateOffer. These are the only substantive changes; the rest
is just rearranging location of the service defs in the file.
Also created a lighterweight OfferInfo proto message wrapper to
be passed between server & client (client has no access to core's
Offer and OfferPayload).
* OfferInfo -- A new wrapper around the OfferInfo proto message.
* CliMain -- The new GetOffers service stub was added.
Some (maybe too much) number and ccy formatting logic was
copied & modified from core. Some tedius string formatting
was added too (needs to be tidied up).
* License comments were also copied to several classes, and I
made a mistake in reverting changes to the wrong file.
TODO add unit tests
The 'getaddressbalance' and 'getfundingaddresses' methods now send
new AddressBalanceInfo proto messages instead of a formatted String
to the client. The AddressBalanceInfo message contains addressString,
balance, and # of confirmations (transaction confidence) fields.
Changes include:
* A new AddressBalanceInfo proto message
* A wrapper class for the new AddressBalanceInfo proto
* New 'getaddressbalance' and 'getfundingaddresses' signatures in server
* AddressBalanceInfo display logic in client
* Removal of balance formatting logic in server
* Refactoring of balance formatting logic in client
This change is a refactoring of the gRPC Wallets service
for the purpose of making CoreApi the entry point to
all core implementations. These changes should have been
made in PR 4295.
See https://github.com/bisq-network/bisq/pull/4295
The gRPC Wallet proto def name was changed to Wallets because
this service manages BSQ and BTC wallets, and GrpcWalletService
was changed to GrpcWalletsService for the same reason.
This PR should be reviewed/merged after PR 4308.
See https://github.com/bisq-network/bisq/pull/4308
This PR's branch was created from the PR 4308 branch.
This addresses task 4 in issue 4257.
https://github.com/bisq-network/bisq/issues/4257
This PR should be reviewed/merged after PR 4304.
https://github.com/bisq-network/bisq/pull/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 2 in issue 4257
https://github.com/bisq-network/bisq/issues/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 #1 in issue https://github.com/bisq-network/bisq/issues/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 #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.
Previously, each wallet-related method was implemented with its own grpc
service. There is no need to do this, as a grpc service may declare
multiple rpc methods. This commit refactors everything wallet-related
into a single GrpcWalletService and also extracts a CoreWalletService
from CoreApi in order to avoid the latter becoming overly large.
Ideally, there would be no need for an abstraction in bisq.grpc called
CoreWalletService; we would ideally use such a service implemented in
bisq.core. The closest we have is WalletsManager, but it is not designed
to be used the way we are using it here in the grpc context. Rather than
making changes directly to core (which can be very risky), we will
rather make them here in this layer, designing exactly the "core wallet
service" we need, and can then later see about folding it into the
actual core.
This change removes non-idiomatic gRPC *Reply proto message fields.
The client should not receive success/fail values from server methods
with a void return type, nor an optional error_message from any server
method. This change improves error handling by wrapping an appropriate
gRPC Status with a meaningful error description in a StatusRuntimeException,
and placing it in the server's response StreamObserver. User error
messages are mapped to general purpose gRPC Status codes in a new ApiStatus
enum class. (Maybe ApiStatus should be renamed to CoreApiStatus.)
Implemented lockwallet, unlockwallet, removewalletpassword, and
setwalletpassword methods with basic error handling.
Also added basic error handling to existing getbalance method,
and removed unused BalancePresentation from CoreAPI.
TODO: update help text
There is no actual requirement for this method, so removing it. It also
helps improve the implementation by removing the need for the static
'instance' field.
The former class is dead code, together with its store service, as they
were only referenced from CorePersistenceProtoResolver::fromProto, the
binding logic and from AppendOnlyDataStoreService by orphaned migration
code. However, migration from the old persisted data was completed long
ago and the store file is no longer being read or written from anywhere
in the codebase.
Also remove the associated PersistableEnvelope proto message type, along
with the TradeStatisticsList message type. The latter is long deprecated
and has no corresponding Java class implementing PersistableEnvelope, so
removing it won't change behaviour (outside the exception message thrown
when attempting to resolve it).
* Add signed witness filter
- Add a filter to pubkeys used in AccountAgeWitness signing
- Fix inverted arbitrator signing of initial account age witnesses from
disputes
- Add test to verify that signed witness filter works
- Add test to verify that the arbitrator signing was fixed
* Fix codacy complaints
* Prevent NullPointerException during toggle group initialization
* Add scrollbar to filter window
* Format test class
Co-authored-by: Christoph Atteneder <christoph.atteneder@gmail.com>
Remove an unnecessary PersistableEnvelope interface by making them
standalone @Value classes with private List fields, instead of extending
PersistableList. As they weren't using any functionality of the latter
other than the getList() and stream() methods, this should not alter
behaviour, outside MeritList::toString.
Also comment out the MERIT_LIST PersistableEnvelope protobuf message
type, which shouldn't be encountered as merit lists were never persisted
directly to a storage file.
This removes the last superfluous PersistableEnvelope implementations,
leaving the following type hierarchy:
PersistableEnvelope *
+- NavigationPath
+- PeerList
+- PersistableList *
+- ThreadedPersistableEnvelope *
| +- AccountAgeWitnessStore
| +- BlindVoteStore
| +- DaoStateStore
| +- PersistableNetworkPayloadList * is abstract
| +- ProposalStore
| +- SequenceNumberMap
| +- SignedWitnessStore
| +- TempProposalStore
| \- TradeStatistics2Store
\- UserThreadMappedPersistableEnvelope *
+- AddressEntryList
+- DisputeList *
| +- ArbitrationDisputeList
| +- MediationDisputeList
| \- RefundDisputeList
+- UserThreadMappedPersistableList *
| +- BallotList
| +- MyBlindVoteList
| +- MyProofOfBurnList
| +- MyProposalList
| +- MyReputationList
| +- MyVoteList
| +- PaymentAccountList
| \- UnconfirmedBsqChangeOutputList
+- PreferencesPayload
+- TradableList
\- UserPayload
This is done primarily for concision. This change also repackages
bisq.grpc => bisq.proto.grpc in anticipation of repackaging the
definitions in pb.proto from 'protobuf' to 'bisq.proto'. There should
not be any compatibility issues with doing this, but it's out of scope
here. When complete, the relationship between bisq.proto.grpc and
bisq.proto will be more intuitively clear, i.e. that bisq.proto.grpc has
certain dependencies on bisq.proto classes, but not the other way
around.
