Normally, for currencies that have a market price feed, Bisq provents
the user from entering offers that are more than 50% away from spot.
It recently came to light via a mediation case that this fat finger
protection in Bisq has a flaw.
A certain sequence of focus operations in the enter offer screen
causes fat finger protection to turn off, and then the user is no
longer protected from making offers that are significantly out of
the market.
To reproduce the issue:
Go to BUY (or SELL) BTC for an market priced asset, e.g. ETH
Click Create New Offer
Click the up/down arrow icon to make sure the % from market price
edit box is selected at the top.
Close the dialog, this saves the selected price format.
Click Create New Offer
Enter 0.25 BTC
Tab to the next field.
Click the up/down arrow icon to make sure the fixed price edit box
is selected at the top. The price and deviation gets auto-populated
to market price and 0% deviation.
Enter a fixed price that is 10x higher than market value.
Click "Next" and the fat finger protection warning DOES NOT pop up.
This is because the deviation still shows 0%.
Even if the app is maximized it does not show the full text of the
action button if the text is long. Switching Bisq to German and
maximizing the window reveals the problem.
Fixes#5862
Change the type of the 'difficulty' field in the Filter & ProofOfWork
proto objects from int32/bytes to double and make it use a linear scale,
in place of the original logarithmic scale which counts the (effective)
number of required zeros.
This allows fine-grained difficulty control for Equihash, though for
Hashcash it simply rounds up to the nearest power of 2 internally.
NOTE: This is a breaking change to PoW & filter serialisation (unlike
the earlier PR commits), as the proto field version nums aren't updated.
Add a numeric version field to the 'ProofOfWork' protobuf object, along
with a list of allowed version numbers, 'enabled_pow_versions', to the
filter. The versions are taken to be in order of preference from most to
least preferred when creating a PoW, with an empty list signifying use
of the default algorithm only (that is, version 0: Hashcash).
An explicit list is used instead of an upper & lower version bound, in
case a new PoW algorithm (or changed algorithm params) turns out to
provide worse resistance than an earlier version.
(The fields are unused for now, to be enabled in a later commit.)
Change the type of the 'difficulty' field in the Filter & ProofOfWork
proto objects from int32/bytes to double and make it use a linear scale,
in place of the original logarithmic scale which counts the (effective)
number of required zeros.
This allows fine-grained difficulty control for Equihash, though for
Hashcash it simply rounds up to the nearest power of 2 internally.
NOTE: This is a breaking change to PoW & filter serialisation (unlike
the earlier PR commits), as the proto field version nums aren't updated.
Add a numeric version field to the 'ProofOfWork' protobuf object, along
with a list of allowed version numbers, 'enabled_pow_versions', to the
filter. The versions are taken to be in order of preference from most to
least preferred when creating a PoW, with an empty list signifying use
of the default algorithm only (that is, version 0: Hashcash).
An explicit list is used instead of an upper & lower version bound, in
case a new PoW algorithm (or changed algorithm params) turns out to
provide worse resistance than an earlier version.
(The fields are unused for now, to be enabled in a later commit.)
The API uses reflection to figure out how to build a payment acct json
form, and the tradeCurrencies field needs to be set after reflection
API's onstructor.newInstance() is called.
