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.)
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.
in parallel and once both are done we call asyncUpdateChartData (not yet refactored).
Clear all data at deactivate
This cause a bit of costs when we activate again but as we delegate
now all work to threads it should be OK. It decreases the memory usage
if we do not keep those data in the fields. The View classes are cached
in the view loader so all data in fields stays in memory once it was
activated once and not manually cleared in deactivate.
Move getTradeStatisticsForCurrency to ChartCalculations
Rename buildUsdPricesPerTickUnit to getUsdAveragePriceMapsPerTickUnit
Rename selectedTradeStatistics to tradeStatisticsByCurrency
Make itemsPerInterval final
Remove modelReady
Add deactivateCalled flag
The creation of TradeStatistics3ListItem is rather fast but the
applying to the list is due sorting pretty slow (300 ms) as
its > 100k items. We do the applying on the callback thread.
Seems JavaFx permits that. So we can keep the UI thread unblocked.
Remove modelReadyListener
Renamed model.selectedTradeStatistics to model.tradeStatisticsByCurrency
Make buildUsdPricesPerTickUnit static and pass params
Rename usdPriceMapsPerTickUnit to usdAveragePriceMapsPerTickUnit
Rename local variable map to usdAveragePriceMap
Move method calls syncPriceFeedCurrency() and
setMarketPriceFeedCurrency() before other calls (those will become async later)
