When the user uses our federated BTC nodes, we merge the hard-coded
nodes with the ones provided by the filter. The hard-coded node's
operator field is set to the node's operator and operator field of the
nodes from the filter is set to "Provided by filter". When the same BTC
node is in the hard-coded list and the filter, Bisq adds both to the
merged list because the operator field is different.
This change explicitly marks the onionAddress, hostName, address, and
port field to be used in the hashCode and equals implementation.
We try to connect to the first 7 Bitcoin Core nodes always in the same
order. Only if connections to these nodes fail we look further into the
list. This change shuffles the node addresses before passing them to
BitcoinJ thus removing the bias from the first 7 prioritized nodes.
Add previously used nodes which are intended to get retired but got
added again due shortage of stable nodes. Those marked unstable should
be banned by filter as long they stay unstable.
By that the newly added fields will not alter the byte array used for the hash and the signature, thus it will not cause issues with removing an old filter which did not inculde those new fields.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Filter offers at OfferBookViewModel when the DaoState changes.
Check for offers amount exceeds trade limit at OpenOfferManager and add it to invalidOffers.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Reduce a hotspot searching the BSQ wallet for the user's votes, upon
selecting a list item of the Vote Result view, by optimising the method
'BsqWalletService.isWalletTransaction(String)'. Do this by adding a
lazily initialised Map field, 'walletTransactionsById', kept in sync
with the existing 'walletTransactions' List field, similar to the tx-by-
id cache removed from the base class in the previous commit, so that a
linear scan of that list can be avoided. Don't bother to make the cache
thread safe, however, since 'isWalletTransaction' is only called from
the user thread and wasn't thread safe to begin with -- access to
'walletTransactions' isn't synchronised, and it is updated only on the
user thread, after a 100 ms delay upon any changes to the BSQ wallet.
Also remove the unused methods 'getUnverifiedBsqTransactions()' and
'getBsqWalletTransactions()' from the class.
This was added in an earlier commit (57b2b4b8) to speed up the Trade
History view, via the method 'getConfidenceFotTxId(String)', by
replacing a linear scan of the live wallet txs with a lookup into a
lazily initialised map. However, the delegating 'WalletService' method
'getTransaction(Sha256Hash)' already serves this purpose, with
'o.b.w.Wallet' itself maintaining a map of all the wallet txs. Use that
method instead, taking care to exclude dead txs from the lookups, to
exactly preserve the current behaviour.
Also do some minor cleanup of the class, mainly to remove IDE warnings.
Alleviate a cubic time bug during the update of the bonded roles
repository, reducing it to quadratic running time. On Mainnet, this
gives a roughly ten-fold speedup and should allow better scaling in the
event that many new bonded roles are added.
Replace calls to 'BondedRolesRepository.findBondedAssetByHash' with a
lookup into a lazily initialised map of bonded assets (Roles) by hash
(reset at the start of each call to 'BondRepository.update()' to prevent
stale caching). This avoids rescanning the roles list for every pair of
roles and lockup tx outputs, thus reducing the number of steps (to
highest order) from:
#roles * #roles * #lockup-tx-outputs
to:
#roles * #lockup-tx-outputs
(The logs show 2 or 3 calls to 'BondedRepository.update()' every time a
new block arrives, and while this was only taking around a second or so
on Mainnet, it could potentially grow to something problematic with
cubic scaling in the number of bonded roles.)
This restores the functionality that was removed in b5beea58. However,
this implementation utilizes the JavaCV library rather than the
webcam-capture library as discussed in #4940. As a result, this should
now provide macOS support.
3000 items are about 180.325 kB.
For nodes not being online for longer the repeated requests consumes quite some time.
With 15k we can expect a 1 MB payload which is still acceptable.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
