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.
With the introduction of the javacv library when re-adding the QR code
scanner feature for mobile notification pairing in #7050, the Bisq
binary increased to nearly 1 GB from its previous size of around 300 MB.
When including the javacv-platform dependency, it pulls in binaries
for all platforms. But it is possible to limit this by utilizing
the gradle-javacpp platform plugin which by default will pull in
binaries only for the current platform.
Reference: https://github.com/bytedeco/gradle-javacpp#the-platform-plugin
With this change, the included libs went from ~980 MB down to ~366 MB.
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>
