It should be only needed in case we get the historical data from resources,
but as I have seen multiple times that some nodes have duplicated entries
in the live data I think its more safe to clean up always. If no entries are
removed the call is very cheap. Even with 60k entries to be pruned it takes
only about 20 ms.
As we might have same keys in multiple maps and merge those to 1 map we
cannot use an immutable map when merging the maps. Instead we copy our merged map
at the end into a immutable map.
Fix issue with immutable maps.
As we might have same keys in multiple maps and merge those to 1 map we
cannot use an immutable map when merging the maps. Instead we copy our merged map
at the end into a immutable map.
* Both axes use autoRange, which results in better
rounded values for the tick mark labels numbers.
* Filter-out data outside the factor limits.
* New constant chartDataFactor for factor limits.
* Formatted tick label currency numbers:
- Fiat: display with grouping separators
- Cryptos: remove trailing zeros in fractional parts
* Add CSS class axisy for y-axis formatting.
Correct wording of transaction confirmation popup to use 'mining fee'
instead of 'transaction fee' to make it consistent with wording of
the BTC confirmation popup.
* Both axes use autoRange, which results in better
rounded values for the tick mark labels numbers.
* Filter-out data outside the factor limits.
* New constant chartDataFactor for factor limits.
* Formatted tick label currency numbers:
- Fiat: display with grouping separators
- Cryptos: remove trailing zeros in fractional parts
* Add CSS class axisy for y-axis formatting.
Adds a check that chain height is within 3 blocks of the reported
height from bitcoin peers -> if not the user cannot take an offer
or have an existing offer taken. It shows a message informing the
user that Bisq is not currently synced, advising them to do an
SPV resync if necessary.
Additionally under Settings/Network a field has been added
to show the chain height of Bisq vs the Peer group.
Added after discussion with chimp1984:
- Correct initialization of chainHeight property
- Rename "Latest BTC block height" display field for clarity
- Enforce chain sync rule for Take Offer scenario
- Enforce chain synch rule for Check offer availability scenario
- change method name to be clearer
Recently, some Monero traders were complaining the XMR/BTC price on the
Bisq Price Index was off from most exchanges. Indeed, it seems HitBTC is
trading at a -10% divergence for some reason, I guess they have low
liquidity or some other reason, but after taking a look we are currently
using HitBTC for the following assets:
* AEON - only 2 trades ever, last traded March 2019
* EMC - never traded
* GRIN - looks like only fake trades, last traded Jan 2019
* PART - only 7 trades ever, last traded August 2020
* XRC - last traded December 2019
* XMR - obviously very important for Bisq
So I feel it's worth it to drop HitBTC as a data provider from Bisq to
make the Monero traders happy and make the Monero price more accurate.
The display of fee rate on the startup screen is misleading because
at startup a fee has not been received from the mempool fee service
and instead the default value of 50 sats is shown.
This change causes the fee rate not to be displayed until a response
has been received from the service.
Fixes#4765