For very low volume offers, it can happen that the minimum buyer security
deposit by coin value is bigger than the maximum security deposit by
percentage of trade amount.
This caused the security deposit validity check in the offer editor to fail,
making it impossible to edit these offers.
This commit fixes the problem by setting the default percentage value to
the model instead of the calculated one in this specific case.
Implements the "possible fix" described in issue #2840 by appending the directive `java.net.preferIPv4Stack=true` to the JVM options.
Tested successfully on Debian 9 and Tails 3.14, using platform Tor and onion-grater.
After restoring from seed, the text shown under DAO /
BSQ Wallet / Transactions displays an incorrect progress - the numbers
are swapped. For example:
"Awaiting blocks... Verified 575,868 blocks out of 554,857"
Normally we get the latest block height from BitcoinJ as the
target height, and we request BSQ blocks from seed nodes up to latest
block.
But when restoring from seed, we receive the latest block height
from the seed nodes while BitcoinJ has not received all blocks yet and
is still syncing.
Fixes https://github.com/bisq-network/bisq/issues/2825
It can be that one user opened a dispute but in the meantime the other
peer sent or received the funds. Atm after a dispute has been opened the
user cannot confirm anymore. This restriction forces all cases to be
resolved in arbitration. If we relax that restriction to allow users
to still confirm after they opened a dispute we might reduce work load
for arbitrators as the payout can be done by the users if both have
confirmed. The arbitrator still need to close the case to that the
open support cases get closed, but the payout tx was already created
by the users.
Arbitrators reported that there are some cases where the confirm
payment or receipt buttons are disabled and they cannot confirm it.
Another issue is that sometimes the confirm msg does not arrive and
after button click its disabled so the message cannot be resent but
clicking the button again.
The software should handle such case and there is some automatic resend
but it seems it does not cover all cases. By keeping the button active
the user can click again and there is higher chance that such cases
get resolved by itself.
I am aware that this is not a good solution but to find out what
exactly caused the issue and to build a more resilient resend
functionality requires much more work and this seems to be a easy fix
which might avoid many disputes.
