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.
Now that we've recently optimized the "medium" fee estimation algorithm
in mempool/mempool@15bb5a96, we can move Bisq back to "medium", since
always using "high" will be a bit wasteful on the weekends when the
mempool is empty.
Bisq currently uses the mempool.space API for fee estimation, selecting
the "medium" priority fee, which generally works very well. However, if
your timing is bad, sometimes the mempool can quickly fill up and your
TX can get stuck for several hours or even days, which degrades the UX
of Bisq.
This PR changes the Pricenode code to always use "high" priority fees,
which would at the time of writing use 99 sat/vB instead of 85 sat/vB,
and hopefully prevent the above-mentioned issue from occuring. Of
course if the mempool is empty the minimum fees would still be used, as
this only changes the "priority" from medium to high.
Fee estimates: https://mempool.space/
API endpoint: https://mempool.space/api/v1/fees/recommended
Based on user feedback, these exchanges are too illiquid and do not
accurately reflect the true price of the market. After research, I found
the user's feedback to be correct and this PR removes both exchanges.
Use Java 11 to run the pricenode service, since v11 includes by
default some root certificates needed when establishing SSH connections
to some of the new API endpoints.
Disable BitcoinAverage provider. Keep it registered as a provider to
ensure that the data structure returned by the pricenode to the Bisq
clients contain the hardcoded "btcAverageTs" key.
Correctly interpret the alt conversion rate reported by the API. For
alts, Bisq needs the Alt/BTC rate, whereas the API returns the BTC/Alt
one. Calculate the inverse of the reported values before storing them as
Bisq internal datastructures (ExchangeRates).
Retrieve the exchange rates in bulk, when possible. This reduces
the number of calls the pricenode makes to the exchange API from N =
"number of exchange rates to retrieve" to N = 1.
The replaced approach, which made a separate call to the exchange API
for each exchange rate, was sometimes failing due to reaching API rate
limits.
Give a more accurate name to the abstract test class
which contains common methods used by all
ExchangeRateProvider tests, like BinanceTest or KrakenTest.
Mark this test class as abstract, to indicate that it
should not be run as a standalone test.
Remove Order annotation from rate providers, which was
used in the case that multiple providers would retrieve
rates for the same currency.
The ExchangeRateService now handles such scenarios, thus
eliminating the need for deciding provider precedence via
the Order annotation.
Add support for a few exchanges to demonstrate and test the pricenode
aggregate rates.
The chose exchanges were selected because they each provide a varied
list of fiat and altcoins, with a substantial overlap between them. This
provides a robust initial set of datapoints and scenarios for aggregate
rates.
Add support for aggregate rates in the ExchangeRateService. If multiple
ExchangeRateProviders contain rates for the same currency, then these
rates will be automatically aggregated (averaged) into one.
This allows the service to transparently scale to multiple providers for
any specific currency.
The clients index the rates received from the pricenode by currency
code, which means they expect at most a single rate per currency. By
aggregating rates from multiple providers into one per currency, the
ExchangeRateService provides more accurate price data. At the same time,
the service API data structure remains intact, thus preserving backward
compatibility with all clients.
Update sanity check methods to allow for deeper and more comprehensive
validations of the input data. Accept full ExchangeRateProviders in the
method signatures, instead of just the provider prefix, to allow for
more complex sanity checks within those validation methods.
