Takes an address, amount, and optional txfeerate param,
returns a lightweight TxInfo proto.
Also overloaded two BtcWalletService methods to allow sendbtc
to pass in the tx fee rate -- overriding the fee service and
custom fee rate setting.
txId and tx.getId are the same.
We got some reports where users have no deposit tx displayed in the
trade after spv resync but cannot move the trade to failed trades.
It seems the invalid txId is still stored in the trade but the tx itself
got removed from the wallet after reysnc. We check not that both the tx
and the txId need to be present.
So we map those setters to our UserThread.
How to reproduce issue?
Restore from seed triggered following exception:
Dec-08 13:20:04.547 [ STARTING] ERROR bisq.common.setup.CommonSetup: Stack trace:
java.lang.IllegalStateException: Not on FX application thread; currentThread = STARTING
at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:291)
at com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:424)
at javafx.scene.Parent$3.onProposedChange(Parent.java:471)
at com.sun.javafx.collections.VetoableListDecorator.setAll(VetoableListDecorator.java:113)
at com.sun.javafx.collections.VetoableListDecorator.setAll(VetoableListDecorator.java:108)
at javafx.scene.control.skin.LabeledSkinBase.updateChildren(LabeledSkinBase.java:272)
at javafx.scene.control.skin.LabeledSkinBase.lambda$new$11(LabeledSkinBase.java:220)
at com.sun.javafx.scene.control.LambdaMultiplePropertyChangeListenerHandler.lambda$new$1(LambdaMultiplePropertyChangeListenerHandler.java:49)
at javafx.beans.value.WeakChangeListener.changed(WeakChangeListener.java:86)
at com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:181)
at com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
at javafx.beans.property.StringPropertyBase.fireValueChangedEvent(StringPropertyBase.java:104)
at javafx.beans.property.StringPropertyBase.markInvalid(StringPropertyBase.java:111)
at javafx.beans.property.StringPropertyBase.access$000(StringPropertyBase.java:50)
at javafx.beans.property.StringPropertyBase$Listener.invalidated(StringPropertyBase.java:231)
at com.sun.javafx.binding.ExpressionHelper$SingleInvalidation.fireValueChangedEvent(ExpressionHelper.java:136)
at com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
at javafx.beans.property.StringPropertyBase.fireValueChangedEvent(StringPropertyBase.java:104)
at javafx.beans.property.StringPropertyBase.markInvalid(StringPropertyBase.java:111)
at javafx.beans.property.StringPropertyBase.access$000(StringPropertyBase.java:50)
at javafx.beans.property.StringPropertyBase$Listener.invalidated(StringPropertyBase.java:231)
at com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:348)
at com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
at javafx.beans.property.StringPropertyBase.fireValueChangedEvent(StringPropertyBase.java:104)
at javafx.beans.property.StringPropertyBase.markInvalid(StringPropertyBase.java:111)
at javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:145)
at javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:50)
at bisq.core.app.WalletAppSetup.lambda$init$1(WalletAppSetup.java:170)
at com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:181)
at com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
at javafx.beans.binding.ObjectBinding.invalidate(ObjectBinding.java:170)
at com.sun.javafx.binding.BindingHelperObserver.invalidated(BindingHelperObserver.java:52)
at com.sun.javafx.binding.ExpressionHelper$SingleInvalidation.fireValueChangedEvent(ExpressionHelper.java:136)
at com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
at javafx.beans.property.IntegerPropertyBase.fireValueChangedEvent(IntegerPropertyBase.java:107)
at javafx.beans.property.IntegerPropertyBase.markInvalid(IntegerPropertyBase.java:114)
at javafx.beans.property.IntegerPropertyBase.set(IntegerPropertyBase.java:148)
at bisq.core.btc.setup.WalletsSetup$1.onSetupCompleted(WalletsSetup.java:245)
If present in the sendbsq command, the parameter will override the fee
service and custom fee rate setting for the BSQ transaction.
Also changed the sendbsq grpc return type to a lightweight TX proto wrapper.
Besides some small refactoring in the CLI, all the changes are
adjustments for this new sendbsq parameter and its new grpc return value.
is not exceeding TOLERATED_SMALL_TRADE_AMOUNT (0.01 BTC) we
return true for verifyPeersTradeAmount.
Before such offers could not be taken even the witness
check would be irrelevant as the trade amount is below the
threshold where we require account age witness.
BtcWalletService was changed to allow the api to override tx fee
rates from the sendbsq and sendbtc methods. The api methods will
still be able to use the network fee service and custom tx fee rate
preference, and set / unset the custom tx fee rate preference, but
the change will permit the addition of an optional txFeeRate parameter
to the sendbsq and sendbtc methods (todo). A few other minor changes
(style and removal of never thrown ex spec) were also made to this class.
Two BtcWalletService methods were refactored.
- The redundant (was always true) boolean isSendTx argument was removed
from the completePreparedVoteRevealTx method signature.
- The redundant (was always true) boolean useCustomTxFee was removed
from the completePreparedBsqTx method signature.
- The completePreparedSendBsqTx method was overloaded with a 2nd parameter
(Coin txFeePerVbyte) to allow api to override fee service and custom
tx fee rate when sending BSQ or BTC.
- The completePreparedBsqTx method was overloaded with a 3rd parameter
(Coin txFeePerVbyte) to allow api to override fee service and custom
tx fee rate when sending BSQ or BTC.
The following line was deleted from the completePreparedBsqTx method
because txFeePerVbyte is now an argument:
Coin txFeePerVbyte = useCustomTxFee ? getTxFeeForWithdrawalPerVbyte() : feeService.getTxFeePerVbyte();
This useCustomTxFee value was always true, and redudant here because
getTxFeeForWithdrawalPerVbyte() returns feeService.getTxFeePerVbyte()
or the custom fee rate preference. i.e.,
Coin txFeePerVbyte = useCustomTxFee ? getTxFeeForWithdrawalPerVbyte() : feeService.getTxFeePerVbyte();
is equivalent to
Coin txFeePerVbyte = getTxFeeForWithdrawalPerVbyte();
LockupTxService, UnlockTxService, BsqSendView, and BsqTransferService
were adjusted to this BtcWalletService refactoring.
When seller if offline we resend the CounterCurrencyTransferStartedMessage at startup.
That caused the trade state set to BUYER_SENT_FIAT_PAYMENT_INITIATED_MSG and then after
the msg was stored in mailbox to BUYER_STORED_IN_MAILBOX_FIAT_PAYMENT_INITIATED_MSG.
Those 2 msg trigger diff. UI states which led to the UI glitch that the UI moved to
step 2 and then to step 3 which was correct but confusing to the user.
Now we only apply BUYER_SENT_FIAT_PAYMENT_INITIATED_MSG is trade state ordinal is
smaller avoiding that UI glitch.
The api is going to need this method, so it was moved from desktop to core.
- Moved the method from WithdrawalView to WalletService.
- Removed an unused initilizer in WithdrawalView.
We check if the txIds of the inputs matches our maker fee tx and taker fee tx and if the depositTxAddress we
use for the confidence lookup is use as an output address.
This prevents that past txs which have the our depositTxAddress as input or output (deposit or payout txs) could
be interpreted as our deposit tx. This happened because if a bug which caused re-use of the Multisig address
entries and if both traders use the same key for multiple trades the depositTxAddress would be the same.
We fix that bug as well but we also need to avoid that past already used addresses might be taken again
(the Multisig flag got reverted to available in the address entry).
- Add check to swapTradeEntryToAvailableEntry to not swap MULTI_SIG entries.
- Remove swap for MULTI_SIG entries at resetAddressEntriesForPendingTrade
- Add check to swapToAvailable to not swap MULTI_SIG entries.
- Remove swaps for MULTI_SIG entries
- Add setCoinLockedInMultiSigAddressEntry method
- Make coinLockedInMultiSig final and remove setter but use it in constructor.
- Rename getCoinLockedInMultiSig to getCoinLockedInMultiSigAsCoin
We use an immutable list when operating on AddressEntry so changes on the
object would not be reflected in the list.
The only mutable field (beside non critical cache fields) is the keyPair.
Might be good to refactor that as well at some point.
- Add setCoinLockedInMultiSigAddressEntrymethods
- Apply API changes:
-- resetCoinLockedInMultiSigAddressEntry
-- setCoinLockedInMultiSigAddressEntry
-- renamed methods
Users need to be able to preserve their acct age when moving a
payment account to a new client.
Also adjusted affected tests, and did some minor refactoring
of the custom gson type adaptor.
This change fixes the blocking problem in the fee rate request api.
Also redefined the TxFeeRateInfo.
- Redefined grpc.proto message TxFeeRateInfo, added
lastFeeServiceRequestTs field. (CLI user may want to know
TS of last fee request.)
- Adjusted TxFeeRateInfo proto wrapper.
- Adjusted CurrencyFormat and BtcTxFeeRateTest to new TxFeeRateInfo.
- Added @Getter annotation to FeeService. (CLI user may want to know
TS of last fee request).
- Pass resultHandler from GrpcWalletsService through CoreApi, to
CoreWalletsService's tx fee rate api methods.
These do not buy enough in the way of performance, at the cost of
so many additional lines. Buy these checks should be done for
debug log statements that have expensive parameters.
Make sure the taker checks the value of the 2-of-2 multisig output of
the deposit tx created by the maker, before signing it. This avoids a
potential security hole, where the maker attempts to steal most of the
deposit by using the wrong output value and adding an extra 'change'
output to himself.
Note that there's no actual vulnerability at present, as the output
value is indirectly checked via the validation of the delayed payout tx.
In particular, the extra checks added in 345426f as part of #4789 (Fix
remaining blackmail vulnerabilities) place a lower bound on the delayed
payout tx input value and with it the deposit tx output value. However,
explicitly checking the amount is more robust.
To persist in the very last moment before exit might cause problems on some OS.
We do not have confirmed that this might be an issue but to be on the safe side
we add a 1 sec. delay between persistence completed and exit.
and do not read or write persisted data.
We had recently a case where a user downgraded from 1.4.2 to 1.3.9 and
this caused failed trades and the wallet funds have been missing due to
some complexities of the wallet wegwit upgrade. The fund could be recovered
but it took quite some effort.
As downgrade is never tested and can lead to all kind of weird bugs we
should prevent that users accidentally can do it.
If there is valid reason to downgrade they can remove the version file.
Make sure to use the segwit version of Script.correctlySpends in
TradeWalletService.finalizeDelayedPayoutTx, which requires the input
value and witness to be passed explicitly (as the latter holds the
actual signature). This was causing BuyerFinalizesDelayedPayoutTx to
fail to do any kind of signature check.
Also refactor the method slightly and remove a redundant call to
WalletService.checkScriptSig (which does the same thing as
TransactionInput.verify) in the branch used by the seller.
Disallow non-P2WH depositTx inputs from the taker, while continuing to
allow them from the maker, so that offers created pre-v1.5.0 can still
be taken. (After some time, those inputs could be disallowed too.)
This is mainly to prevent mass blackmail attacks, where more victims'
money could be locked up than the DAO could possibly compensate them all
for. (This is probably only an attractive attack for a buyer anyway, at
least with the earlier commits.)
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).
Improve validation of the buyer's delayed payout tx (both before & after
they get the final DepositTxAndDelayedPayoutTxMessage from the peer), by
finalising it independently of the seller. This is now possible since
their 2-of-2 signature is included in the DelayedPayoutSignatureRequest.
Check that the final delayedPayoutTx received from the seller matches it
byte-for-byte (which actually makes its receipt redundant now).
This also fixes an apparent security bug, where the final validation of
the delayedPayoutTx appears to skip any kind of signature check (only a
deposit tx hash check, which is still necessary).
Finally, optimistically check the deposit tx against the input of the
prepared delayedPayoutTx received from the seller, in the case that the
former is non-malleable (that is, the fully segwit case) and thus has a
stable ID given by the hash of the buyer's preparedDepositTx.
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.
Make sure witness data is stripped from the seller's prepared deposit
tx, in addition to ScriptSig data, to prevent the buyer from being able
to publish it prematurely (before having signed the delayed payout tx).
- Add missing boilerplate error handling to GrpcPaymentAccountsService.
- Edit some PaymentAccountForm & PaymentAccountTypeAdapter exception
messages that would be passed to CLI; they should be in the same
style as existing CLI err msgs.
These are failing on the tip of release/1.5.0 currently due to extra
validation added to PersistenceManager, causing the build to fail upon
merging upstream. Add missing PersistenceManager.shutDown calls to the
tearDown methods of the affected tests to fix.
We need to set addDecryptedDirectMessageListener without
delay as otherwise we could miss direct messages (detected
with localhost testing, with tor its likely slower and
would not have been triggered).
This is not really needed as we call it at each state change of the
trade but gives more redundancy in case we missed one or once
changes are applied and a dev forgets to call it.
Multiple repeated calls do have close to zero costs.
The deposit confirmed state is set after we applied the mailbox messages,
which led to a task failure due wrong phase and the message was not applied.
Further it can be that the wallet is still syncing and the deposit
confirmed state is set in any time in the future.
To fix the first problem we add a bit of delay so that the trade has
been updated when we apply the mailbox messages. A better fix would be to change
the order of the methods but that is a bit tricky to get right and I dont want to
risk that for that release.
The second problem would require a large change to trigger the mailbox
processing based on wallet state. We prefer to be more tolerant with
the expected phase instead so allow the mailbox message to be processed
also in the DEPOSIT_PUBLISHED state.
This has no risks as the payout tx would be invalid anyway if the
buyer has cheated and sent the msg in not confirmed deposit tx state (only
possible with code manipulation).
A better fix would to add a listener for the wallet and process
the mailbox msg once wallet is ready and trade state set, but I
leave that for another PR.
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.
This class uses the gson PaymentAccountTypeAdapter to generate editable
json forms for PaymentAccount sub-types, and instantiate PaymentAccount
instances from edited json forms.
Changed the core getPaymentMethods() -> getFiatPaymentMethods() to avoid
"Unnecessary use of fully qualified name 'PaymentMethod.getPaymentMethods'
due to existing static import 'bisq.core.payment.payload.PaymentMethod.*'"
Had to change the getPaymentMethods() names to getPaymentMethodIds() to
avoid this codacy issue:
"Unnecessary use of fully qualified name 'PaymentMethod.getPaymentMethods'
due to existing static import 'bisq.core.payment.payload.PaymentMethod.*'"
If 'PaymentMethod.getPaymentMethods' was changed to 'getPaymentMethods',
a recursive loop would result, ending in an out of stack heap crash.
This renaming of the method on the server is correct, but the CLI's
'getpaymentmethods' name was not changed.
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.
We relied on the shutdwon routine to be called reliably but it seems that is not the case as some bug reports show.
So we call requestPersistence at every write access of the trade object
Showing 'x' days until limits lifted (signed, pending)
Showing clock icon (signed, pending)
Showing outlined check icon (aging accounts)
Showing account age (unsigned or aging)
Changed column name from 'Signed since' to 'Account info'
Fixed bug when switching between altcoins and fiat order books
the account info column was being added back to the table in
the wrong position.
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.
- Add optional makerFeeCurrencyCode argument to CLI's 'createoffer'.
- Add optional takerFeeCurrencyCode argument to CLI's 'takeoffer'.
- Add isCurrencyForMakerFeeBtc field to OfferInfo proto wrapper.
- Pass fee currency argument down to CoreOffersService and CoreTradesService's
create and take offer methods.
- Add maybeSetFeePaymentCurrencyPreference method to OfferUtil to
conditionally set the 'payFeeInBtc' preference before creating
or taking an offer.
- Adjust affected tests.
Moved just enough code out of BsqSendView to avoid desktop/api
'sendbsq' duplication, at the cost of adding 1 new method to
BsqSendView.
- Created new BsqTransferModel to hold tx details shared by desktop and api.
- Created new BsqTransferService to send bsq using a BsqTransferModel shared
by desktop and api.
- Uncommented CoreWalletsService#sendBsq implementation.
- Uncommented sendbsq tests.
All the boilerplate for this method is included in this change, but
the implementation in CoreWalletsService#sendBsq is commented out
until the needed logic to send bsq is refactored out of desktop's
BsqSendView class -- to be included in the next PR.
- Added new method to CLI.
- Added the gRPC server boilerplate.
- Added the core implementation, commented out.
- Enabled tests.
- Added three new methods to CLI:
getbalances ... returns complete bsq and btc balance info
getbsqbalance ... returns complete bsq balance info
getbtcbalance ... returns complete btc balance info
The old getbalance method is deprecated and will be removed
if there is agreement to do that.
- Made the needed changes in the CLI's output formatting classes.
- Added new tests to existing BsqWalletTest, added new BtcWalletTest
and WalletBalancesTest.
- Added disabled tests for funding a bsq wallet (todo in next PR).
- Added new method to CLI, split some long msg strings into two lines,
and added a white space after a braceless else statement.
- Added the gRPC server boilerplate.
- Added the core implementation.
- Added a test, and moved method wallet tests into their own package.
This change adds proto wrappers for sending bsq, btc, or all balances
to the CLI. They will be used in future api method implementations:
getbsqbalance, getbtcbalance and getbalances.
