Currency: distinguish crypto vs. fiat?

[KiaraGrouwstra]

Currently, crypto/fiat currencies are not distinguished in Currency, though in practice they have some relevant differences -- some functions such as requestDepositAddress are naturally expected to fail for fiat currencies, for example. For such cases, having e.g. crypto/fiat sub-classes might help catch some such issues at compile-time as well. Would you be open to a PR in this direction?

[ghost]

In my opinion, there are no ways to distinct exactly what is fiat and what is crypto. The data source - marketplaces - does not separate them, all of these are just currency. Described details makes requested distinguishes not reliable enough. As soon that this implementation way (via sub-classes) is applied to all users and can produce errors - I don't think that this is a good idea.

[KiaraGrouwstra]

I guess it's much more likely for new currencies to fall in the crypto category than we'd actually get new fiat currencies. From that perspective, one way to deal with this might be to explicitly mark the fiat currencies, and consider anything else crypto. I see your point on backward compatibility though. With that in mind, I'll mark this as closed unless others here feel differently about it.

[KiaraGrouwstra]

I'm curious: is there anything preventing different currencies from choosing codes that overlap with existing currencies? I could theoretically see some room for mix-ups since there is no one authority on the codes, especially when coming from different exchanges.

[timmolter]

It's theoretically possible for sure. You just have to know what symbols each exchange is using to represent each currency and make sure to use the correct symbols for each exchange.

[KiaraGrouwstra]

Thinking a bit about preventing that, as manually confirming all symbol meanings per exchange gets impractical to scale. Thoughts on sanity checks on whether the currency actually matches:

• if prices between two exchanges differ too much, this may be a red flag.
• withdrawal addresses at both exchanges will follow similar formats, presumably at least matching in length, but potentially there might also be something like address format regexes per coin.
• if you try moving money and you never get it, the currency might not have matched. impractical.

Now, normally coins would probably pick new names, but this may become more relevant with hard forks, just like bitcoin itself is expected to get soon. Like, might one exchange accept the forked version under the old symbol, while another exchange would stick with the original? For BTC itself this impacts so many trade pairs I'd rather just make sure of this manually. And probably no-one cares to hard-fork no-name coins. For those in between though, I could see this happening in such a way it might be harder to notice...

[KiaraGrouwstra]

Heh, I thought confusing currency codes were a theoretical issue, but I now noticed that BitFinex actually trades Dash (DASH) under the code DSH, which apparently is normally supposed to refer to DashCoin. Ouch.

Is there already any sort of way to overwrite codes implemented such that this could just be filed as a bug for the BitFinex implementation in XChange?

I also pinged their Twitter hoping they're willing to have it conform standards, but yeah.

Edit: sorry, just realized this had already been considered in the code-base currently. In that event, I might have run into a bug. I ran getExchangeSymbol there and got back pairs with DSH, although it appears symbol replacement should already get triggered there. I'm on version 4.2.0.