Move the 'confirmations' field from TransactionsListItem to the nested
'LazyFields' class, so that it is correctly lazily initialised when
'getNumConfirmations()' is called, instead of just returning 0 for
hidden list items with uninitialised tooltips + confidence indicators.
This makes the logic consistent with that in TxConfidenceListItem and
fixes a bug in the BTC transactions view CSV export, where only the
already rendered list items would have nonzero confirmation counts.
Add a 'lazyFields' volatile field to DepositListItem to detect
initialisation of the associated memoised 'LazyFields' supplier,
allowing confidence updates to be short-circuited when the corresponding
indicator has not yet been lazily loaded.
This is for consistency with the 'LazyFields' logic just added to
TxConfidenceListItem and should make the UI more responsive if a new
block arrives when the funds deposit list is in view, by avoiding the
entire list of item tooltips & confidence indicators from being force-
initialised.
Add a 'LazyFields' static class and memoised supplier field to the base
class TxConfidenceListItem, similar to that added to the classes
DepositListItem & TransactionsListItem. This allows lazy loading of
tooltips & tx confidence indicators, just as for those classes.
This removes the current remaining bottleneck in the BSQ tx view load,
revealed by JProfiler. (Note that there is still a quadratic time bug
remaining due to the use of a confidence listener for each list item,
since the BSQ wallet internally uses a CopyOnWriteArrayList, whose
backing array is cloned for each listener addition or removal. However,
it isn't clear that fixing this will give a noticable speedup unless
there are an extremely large number of BSQ txs in the wallet.)
Take care to add the tx confirmation count to LazyFields, to prevent
issues when exporting the list as a CSV. Also add a volatile
'lazyFields' field to detect lazy initialisation of the supplier and
short circuit confidence updates for uninitialised indicators.
Precompute and pass a map of txIds to BsqSwapTrade instances to the
BsqTxListItem constructor in 'BsqTxView.updateList()', in place of the
tradable repository, so that the tradables don't need to be repeatedly
scanned to find the optional matching BSQ swap trade for each BSQ tx.
This fixes a quadratic time bug and significantly speeds up the BSQ tx
view load for users with many past trades.
Remove the direct call to 'updateList' in the 'BsqTxView.activate()'
method, as it is later called indirectly via 'onUpdateAnyChainHeight()'.
This nearly doubles the loading speed of the BSQ tx list (in the DAO /
BSQ Wallet tab), since 'updateList' is very slow when there are many txs
in the wallet.
In the (hopefully rare) case that the user has multiple past trades that
end in arbitration, the entire wallet tx output set was scanned once for
every such trade (via 'TransactionAwareTrade.isRefundPayoutTx' calls),
to look for any outputs matching the payout address. This potentially
causes a slowdown of the Transaction view load for each new arbitration
case added. To avoid this problem, cache the last set of recipient
address strings of the provided tx, as the next call to
'isRefundPayoutTx' is likely to be for the same tx.
Also check that there is exactly one input (the multisig input) for any
candidate delayed payout tx, to speed up 'isDelayedPayoutTx' in case the
wallet contains many unusual txs with nonzero locktime.
Eliminate a minor quadratic time bug, caused by the unnecessary addition
of a (BtcWalletService) TxConfidenceListener for each list item in the
Transactions view. (Since the confidence listeners are internally held
in a CopyOnWriteArraySet, this sadly runs in quadratic time, slowing
down the Transactions view load a little.)
The confidence listener is apparently redundant because of a set of
calls to 'TransactionsListItem.cleanup' immediately upon construction of
the item list, which removes all the listeners just added. (This code
appears to date from at least February 2016, in commit c70df86.)
(The confidence indicators are kept up to date by simply reloading the
entire list upon each wallet change event.)
Use a crude Bloom filter (of sorts) to cut down the quadratic number of
calls to 'TransactionAwareTradable.isRelatedToTransaction' (that is, one
for each tx-tradable pair) during the Transactions view load. In this
way, we may reduce the number of calls roughly 40-fold, for a Bisq
instance with similar numbers of BSQ swap trades and escrow trades.
(Sadly, profiling does not show a 40-fold reduction in the size of the
'isRelatedToTransaction' hotspot, likely due to the remaining calls
being expensive ones involving disputed trades or unusual txs with
nonzero locktime, e.g. dust attacks or funds from Electrum wallets.)
To this end, partition the wallet transactions into 64 pseudo-randomly
chosen buckets (with a dedicated bucket for txs which might be delayed
payouts, namely those with nonzero locktime). Add an interface method,
'TransactionAwareTradable.getRelatedTransactionFilter', which returns an
IntStream of all the indices of buckets where a related tx may plausibly
be found. Where this is unclear, e.g. for trades involved in a dispute,
just return everything (that is, the range 0..63 inclusive).
Add a class, 'RelatedTransactionFilterSlices', that holds a provided
list of TransactionAwareTradable instances and 64 bitsets of all the
slices through their respective filters (each realised as 64-bit word
instead of a streams of integers). In this way, a list of tradables
plausibly related to any given tx may be quickly found by simply
selecting the appropriate bitset of the 64 (by the tx bucket index).
Inline a local variable, to eliminate another minor Sha256Hash.toString
hotspot in the Transactions view load, this time coming from
'TransactionsAwareOpenOffer.isRelatedToTransaction'. This is helpful in
the case that the user has a large number of (possibly disabled) BSQ
swap offers.
Move the line,
Set<Tradable> tradables = tradableRepository.getAll();
to the top level of 'TransactionsView.updateList', instead of needlessly
calling 'TradableRepository.getAll' (which builds a new set every
invocation) for each wallet transaction being iterated over.
This was causing a significant slowdown of the view load.
Use a mutable static tuple field to cache the last result of
'Sha256Hash.toString', which is used to get the ID string of the input
tx, when calling 'TransactionAwareTrade.isRelatedToTransaction'. In this
way, consecutive calls to 'isRelatedToTransaction' on the same input tx
(over all the past trades, as done by 'TransactionsView.updateList') are
sped up significantly, since hex encoding the txId is a bottleneck.
Replace the "Optional.ofNullable(...)..." constructs with more direct
code using short-circuit operators, as this is shorter and a little
faster. Also use "trade.get[Deposit|Payout]TxId()" instead of the code
"trade.get[Deposit|Payout]TxId().getTxId()", as (upon inspection of the
code) there should never be a case where the deposit/payout transaction
field of a Trade object is set but the respective txID field is null (or
set to an inconsistent value).
Also remove a redundant 'RefundManager.getDisputesAsObservableList'
method call, which was also slowing things down slightly.
The minor speedups afforded by the above are important because the
method 'TransactionAwareTrade.isRelatedToTransaction' is called a
quadratic number of times and consequently a major bottleneck when
loading the Transactions view.
This helps to avoid that the legacy BM would get the rest in case there are capped shares.
It still can be that a candidate exceeds the cap and by the adjustment becomes capped. We take that into account and the legacy BM would get some share in that case.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Left side is amount to burn to reach the max allowed receiver share based on the burned amount of all BM.
The right side is the amount to burn to reach the max allowed receiver share based the boosted max burn target.
Increase ISSUANCE_BOOST_FACTOR from 3 to 4.
Add help overlay to burn target table header.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
This helps to avoid that the legacy BM would get the rest in case there are capped shares.
It still can be that a candidate exceeds the cap and by the adjustment becomes capped. We take that into account and the legacy BM would get some share in that case.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Left side is amount to burn to reach the max allowed receiver share based on the burned amount of all BM.
The right side is the amount to burn to reach the max allowed receiver share based the boosted max burn target.
Increase ISSUANCE_BOOST_FACTOR from 3 to 4.
Add help overlay to burn target table header.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
It is not included in BurningManCandidate candidate map as that would complicate things.
We only want to show it in the UI for informational purposes.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Split up into 4 service classes
- BurningManService: Common stuff
- BurningManInfoService: For displaying BurningMan data
- BtcFeeReceiverService: For getting btcFeeReceivers
- DelayedPayoutTxReceiverService: For getting delayedPayoutTxReceivers. This is the critical part where we need to have a deterministic data and which could break trade consensus.
WIP refactoring. More to come...
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Add getAverageDistributionPerCycle method to BurningManService.
Show receiver address when BM is selected.
Refactor code, cleanups, UI improvements.
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>
We cannot add a new field as that would break DAO consensus.
Add optional text field for burningManReceiverAddress to CompensationProposal UI.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Some commits were missed from the first implementation in #6431.
The user limit is applied to offer entry via AccountAgeWitnessService.
Offers are filtered according to limits in OfferFilterService.
If limit changed, the cache in OfferFilterServices must be cleared.
Previously the BSQ fee payment was determined by parsing a raw tx
without relying on the DAO. Unfortunately this turned out to be
problematic, so with this change the BSQ fee paid is obtained from
the DAO tx, as originally preferred by chimp1984.
Unconfirmed transactions will not be able to have their BSQ fees
checked so early requests for validation will skip the fee check.
This is not a problem since maker fee validation is done by the
taker and in the majority of cases will be already confirmed; taker
fee validation is done after the first confirm at trade step 2.
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.
Do not pay out the security deposit of the trade peer to the
arbitration case winner.
Amounts are filled out based on which option the
Arbitrator chooses:
If BTC buyer is selected as case winner they will get
trade amount + buyer security deposit.
If BTC seller is selected as case winner they will get
trade amount + seller security deposit.
If custom payout is selected arbitrator can specify
custom amounts as they wish.
In case of a `||` the statement gets removed as it always is true.
At getUserPaymentAccounts we refactor further the steam to a HashSet constructor operation as the filter method gets removed.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Move AddressException, NodeAddressException and DisputeReplayException to DisputeValidation.
Use DisputeValidation.ValidationException as type for DisputeManager.validationExceptions.
Remove Nullable annotation for dispute field in those exceptions.
Remove null checks when those DisputeValidation.ValidationException are used.
This is the tool used for Manual Payouts and message sign/verify.
Replaces the monolithic code with a class for each tab in the UI.
This refactoring was necessary in preparation for adding a new tab.
