We show the ARS blue rate popup whenever the user creates a payment
method and ARS is selected. Therefore, it makes sense to always show the
ARS blue rate popup.
At the moment, we show the ARS Blue Rate popup when the user saves a
single currency payment account (PR #7122). This misses many payment
accounts that support ARS. The new behaviour is to show the ARS Blue
Rate popup when ARS is selected during account generation (either
pre-selected or later selected by the user).
Payment accounts supporting ARS:
- CashByMail
- CashDeposit
- F2F
- MoneyGram
- National bank
- OKPayAccount (deprecated)
- Same bank
- Specific bank
- Transferwise
- Uphold
- Western Union
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.
Currently, it requires about 5.2G of space.
Therefore, increase it to allow for future growth.
However, hopefully this becomes irrelevant soon
with the changes in bisq-network/mempool#13.
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.
