MIN_BUYER_SECURITY_DEPOSIT and SELLER_SECURITY_DEPOSIT values to 0.0003 BTC after activation date of 1.3.2025
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
The persistingBlockInProgress field is read by the block parsing thread.
However, the block parsing thread and user thread write to the
persistingBlockInProgress field. The block parsing thread might see the
update too late and trigger another snapshot before the previous was
done.
The filter provided nodes were added to a read-only List and this lead
to crashes at start-up. We didn't catch the bug before because the lists
in the tests are mutable. Now the FederatedBtcNodeProvider.getNodes
method operates on Streams.
The getoffers api doesn't return any offers until the user has created
his payment accounts. Afterward the api will only return offers that the
user can take. This behavior is confusing and frustrating for new
developers. The new behavior is to show all offers for a given market
(direction, currency).
At the moment, some tests are sharing the same BSQ wallets. This change
creates a separate wallet for indenpendent tests to improve the tests's
reliability.
The fundWallet method sends the given amount to the BitcoinJ wallet from
the Bitcoin Core miner wallet, mines one block, and waits until the
BitcoinJ wallet updates its wallet balance.
The FederatedBtcNodeProvider compared the list of banned nodes with each
BtcNode's hostname instead of checking a BtcNode's hostname, ip address,
and onion address.
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.
