methods.
Add overridden getPreparedSendBsqTx and getPreparedSendBtcTx methods
with utxoCandidates param.
If utxoCandidates is not null we apply it to our coinSelector.
As the coin selector is re-used we re-set it immediately after
it was applied (inside coin selector select method).
Set preferences in nonBsqCoinSelector
This change gives CLI users a 'stop' command to shutdown a daemon.
- Server side gRPC boilerpate was added to :proto and :daemon.
- When the new GrpcShutdownService accepts a 'stop' request from the CLI,
it calls UserThread.runAfter(BisqHeadlessApp.getShutDownHandler(), 500, MILLISECONDS);
- Method help file 'stop-help.txt' was added to :core.
- Client side gRPC boiler plate and 'stop' implementation was added to :cli.
The order of checks was wrong.
PRE: it was checking the SignaturePubKey for messages that
were handled by other subsystems, such as OfferAvailability.
POST: make sure that this is a relevant message before checking that
its signature matches the trade.
TriggerPriceService is changed to use a BootstrapListener
on the P2PService so that it can start after the P2P network
is ready.
Fixes#5190 : Prevents an Uncaught Exception error at startup.
If user preferences were set to a bisq explorer that has been
retired, switch it to another explorer from the provided list.
Users can still choose their own explorer, or enter a custom
explorer address (such as their local node).
Adds countryCode to AmazonGiftCardAccountPayload
Account upgrade done at startup => Eurozone accounts will prompt for country.
Trade buyer step 2 prompts use of the appropriate Amazon website for buying gift card.
Undo the earlier simplification changes to getTransactionConfidence,
which preserved its original but broken behaviour. Fix the original
stream pipeline so that each matching tx input maps to the confidence of
the connected parent tx (if any), not the child tx. In this way, it
correctly considers parent tx confidences when determining the most
recent confidence of all the matching inputs & outputs.
Before it was simply feeding a repeating list of identical objects into
getMostRecentConfidence, via the erroneous line:
.map(o -> tx.getConfidence())
(Also add a missing @Nullable annotation & make getMostRecentConfidence
private instead of protected.)
Finally, simplify BisqWalletListener.onTransactionConfidenceChanged, by
no longer feeding a singleton list into getMostRecentConfidence whose
element is already a return value of that method, as that is a no-op.
Do not attempt to create an offer if the server wallet is
unavailable. And if the wallet is encrypted, do not attempt
to create an offer if the wallet is not unlocked.
Attempt to remove a bottleneck during the transactions view load, as
revealed by JProfiler, by optimising the code to determine if any given
transaction and trade are related. Since both these sets will tend to
grow linearly with time, causing quadratic slowdown of TransactionsView,
try to alleviate (without completely fixing) the problem.
To do this, add a cached set of disputed trade IDs to DisputeListService
so that TransactionAwareTradable.is(Dispute|RefundPayout)Tx can be made
O(1) in the common case that the given trade is not involved in any
dispute. Also avoid calling Sha256Hash::toString by passing tx IDs as
Sha256Hash objects directly to is(Deposit|Payout)Tx, and short circuit
an expensive call BtcWalletService.getTransaction in isDelayedPayoutTx,
in the common case, by pre-checking the transaction locktime.
This also fixes a bug in isRefundPayoutTx whereby it incorrectly returns
false if there are >1 disputes in the list returned by RefundManager but
the given trade is not involved in the last one.
Use a guava SetMultimap (a many-to-many mapping without duplicates) to
cache the set of live txs in the user's wallet with a given address as
an input or output. As with the cache of output counts from the previous
commit, compute all the tx sets in one go (by a tx stream followed by a
map inverse) and store in an ImmutableSetMultimap<Address, Transaction>,
invalidating the entire cache immediately upon each wallet change event.
This is to fix another (larger) quadratic time bug in DepositView, when
getting the confidence (i.e. confirmation count) of each wallet address.
Also simplify getTransactionConfidence & onTransactionConfidenceChanged
methods slightly, which generated (possibly unintentionally) repeating &
singleton lists of TransactionConfidence objects to pass to
WalletService.getMostRecentConfidence(..) respectively.
