- We return true at isCryptoCurrency in those cases:
- The code is BTC
- The code is found in assetRegistry
- If not found we check if we have a fiat currency for that code,
if not we treat it as crypto (case of a removed asset)
- cross check the isCryptoCurrency method if the symbol matches any
fiat currency and of both not match consider it still a CC. In case of
a removed asset it was returning false before which caused an issue in
the trade currency pair showing both sides as BTC.
- Show N/A for name in case the asset is not available.
The code mostly operates with the ticker symbol which gets stored in
the offer, so even an asset is removed traders who have that asset in
their account list can trade without problems.
Tested create offer, take offer and executing a trade.
This change avoids the as-yet unexplained resolution errors we've been
seeing out of JCenter today, which look like the following:
Could not resolve all files for configuration ':monitor:compileClass
> Could not resolve net.gpedro.integrations.slack:slack-webhook:1.1.
Required by:
project :monitor
> Could not resolve net.gpedro.integrations.slack:slack-webhook:1
> Could not get resource 'http://jcenter.bintray.com/net/gpedr
> Could not HEAD 'http://jcenter.bintray.com/net/gpedro/int
> sun.security.validator.ValidatorException: PKIX path b
For full context, see the Travis CI build failure at
https://travis-ci.org/bisq-network/bisq/builds/451786384#L678-L679.
It is assumed this is an issue on the JCenter side, e.g. something to do
with the interaction of JCenter servers and their SSL implementation
when accessed under OpenJDK 10 and its TrustStore implementation. This
specific failure does not occur under Oracle JDK 11, but other
dependencies do fail in a similar but non-deterministic fashion. In any
case, resolving project dependencies from Maven Central solves the
problem in the meantime.
See also https://github.com/gradle/gradle/issues/6630.
