Default value is false, so same behaviour as before the change.
If no payment account is setup then we also show all payment methods.
In that case (no payment account) we disable the toggle as well as set it to false.
p2PService.getP2PDataStorage().getAppendOnlyDataStoreMap().
p2PService.getP2PDataStorage().getAppendOnlyDataStoreMap() iterates
over all services including the historical data store service. It used the
getMap method which should not be used at historical data store service as
it is not clear if the live data or all data should be accessed.
This change fixes the underlying problems behind five compiler warnings:
"Generating equals/hashCode implementation but without a call to superclass".
Some core classes use @Value and @Data annotations where not necessary, for
example, where equals, hashCode, and toString are implemented by the developer,
and where final class and field modifiers are defined by the developer.
From lombok classes and documents for the shortcut annotations
@Value https://projectlombok.org/features/Value and
@Data https://projectlombok.org/features/Data,
we find some implicit annotations applied by these shortcuts are not needed.
Adjustments are described below.
- Tx Replace @Value with @Getter.
- TxOutput Replace @Data with @Getter and @Setter.
- ChangeParamProposal Replace @Value with @Getter.
- GetInventoryRequest, GetInventoryResponse
An @EqualsAndHashCode(callSuper = false) is added to supress build
warnings.
The periodicRefreshOffersTimer gets started at offer publishing.
Before the stopPeriodicRefreshOffersTimer got overwritten by the start in offer
publishing so it did not had any effect beside that we restarted it. Now we
process offer publishing without delay and a stop after the call would stop
the refresh timer.
Change comments (after understanding the domain usage better)
Maintain the set at add and remove methods
Use HashMap instead of ConcurrentHashMap as that class is only used
from UserThread and other fields are not threadsafe either.
this supports the historical data store.
Using p2PService.getP2PDataStorage().getAppendOnlyDataStoreMap()
would not deliver all the data.
User stream API
We iterate over all trades and messages, so it is expected that
the msg which are not assigned to that trade fails.
We need to change the handleDecryptedMessageWithPubKey to check
first if the msg and trade matches, but that will be done in a dedicated PR.
now all dao store files and request a shut down of the app.
After a restart the resource files are used. This avoids cases where a resync from
genesis got triggered (observed on seed nodes, not on desktop apps).
Seed nodes and headless apps get shut down automatically.
In case of the desktop app we show a warn popup with shutdown
button and no close button, so we enforce a shutdown to avoid
complications in case the user would continue.
Redesign the UI
Add import/export of payout settings
Add ability to import from mediation ticket
Mediator does not need private key
User can sign using own wallet or private key
Validation of input fields
Calculate the tx fee based on inputs
Display of the generated txid & hex so it can be checked
Call flush at openOfferManager shutdown.
Remove unused method.
Force broadcaster to send out immediately, otherwise we could
have a 2 sec delay until the bundled messages sent out.
As the normal maps are not using a ConcurrentHashMap it is
likely unnecessary as well that I am not aware of a
multi-threaded access.
But as it does not show any difference in performance
it is likely the bit more safe option.
directly and we did not remove the item from the cache)
- Add getSignedWitnessMapValues method for access to signedWitnessMap values
- Remove Getter for signedWitnessMap
- Add removeSignedWitness method (used in test only)
- Use addToMap in test instead of direct access to map
- Remove getSignedWitnessSetCache entry matching
signedWitness.getHashAsByteArray() as well.
See comment. @sqrrm: Can you cross check?
The getSignedWitnessSet is called very often and is a bit
expensive. We cache the result in that map but we
remove the cache entry if we get a matching SignedWitness
added to the signedWitnessMap.
The accountAgeWitnessMap is very large (70k items) and
access is a bit expensive. We usually only access less
than 100 items, those who have offers online. So we
use a cache for a fast lookup and only if
not found there we use the accountAgeWitnessMap and
put then the new item into our cache.
Change the specific sign window to sign an imported account in the form
of accountAgeWitnessString,pubKeyString. The SignSpecificWitness never
worked due to missing pubKey data and this is a way to import the missing data.
Redesign the UI
Add import/export of payout settings
Add ability to import from mediation ticket
Mediator does not need private key
User can sign using own wallet or private key
Validation of input fields
Calculate the tx fee based on inputs
Display of the generated txid & hex so it can be checked
The delay was too long. Some users have 100 - 200
offers and with the 700 ms delay it takes 70-140 sec.
This causes more stress for the network and UI due
permanent adding of offers. We decreased delay to 30 ms per offer.
So with 200 offers it would be about 6 sec. Maybe we could reduce
it even further but as it is hard to test in the live network with
so many offers it is better to not be too radical with the change.
This change was prompted by the recent changes in the main branch to
allow a tx memo field to be set from the UI and API.
This and the prior PR address the API's need to be able to fetch a
tx (with a memo). The API can now get a completed trade's withdrawal
txid and pass it as a gettransaction parameter.
See previous PR "Append nullable withdrawalTxId field to Trade".
https://github.com/bisq-network/bisq/pull/4937
A summary of changes by file:
grpc.proto
- Added withdrawalTxId field to existing TradeInfo proto & wrapper.
- Reordered fields in TradeInfo proto.
- Added new fields to be displayed by TxInfo proto in CLI.
- Fixed typo: unsetTxFeeRatePreference -> UnsetTxFeeRatePreference.
- Added new GetTransaction rpc.
GrpcWalletsService - Added new getTransaction gRPC boilerplate.
CoreWalletsService - Added new getTransaction implementation.
TxInfo - Added the new fields for displaying a tx summary from CLI.
This is not intended to be more than a brief summary; a block explorer
or bitcoin-core client should be used to see the complete definition.
TradeInfo - Added the new withdrawalTxId field defined in grpc.proto.
CliMain - Added new 'case gettransaction'.
TransactionFormat - Formats a TxInfo sent from the server to CLI.
ColumnHeaderConstants - Added console headers used by TransactionFormat.
TradeFormat - Displays a completed trade's WithdrawalTxId if present.
Apitest - Adjusted affected tests: assert tx memo is persisted and
test gettransaction.
The withdrawalTxId field will be set in TradeManager#onWithdrawRequest
upon successful trade completion and withdrawal of funds.
Persisting withdrawalTxId will allow the api and ui to find the withdrawalTxId
for a completed trade after the seller withdraws funds to an external wallet.
In turn, the withdrawal tx's memo field will be accessible in a new (todo)
api getTx(txID) api method.
Changed:
- Appended field 'string withdrawal_tx_id = 40' to pb.proto's Trade message.
- Added nullable 'String withdrawalTxId' to Trade entity class.
- Added trade.setWithdrawalTxId(transaction.getTxId().toString()) in
TradeManager#onWithdrawRequest's callback.
- Added optional memo parameter to the api's sendbtc and
withdrawfunds commands.
- Removed the @Nullable annotation was removed because protobuf
does not support null.
- Visibility in two wallet check methods were changed from private
to pkg protected so the CoreTradeService could use them.
- Adjusted affected tests. (Asserting the memo field was set on a
transaction cannot be checked from apitest yet.)
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.
