ISO 4217 states support for both alphabetic and numeric codes. rippled adheres to the ISO 4217 as stated in the Currency_Format on the wiki (https://ripple.com/wiki/Currency_Format) and there are trustlines out there with numeric currency codes.
The three-digit numeric code is useful when currency codes need to be understood in countries that do not use Latin scripts and for computerised systems. Where possible the 3 digit numeric code is the same as the numeric country code.
* Add full json ledger dumps of ledgers 38129 and 40000 to test/fixtures
* Use `Ledger` to calculate account and transaction hashes and verify
against dumps
This includes supporting files that can sign arbitrary data
with a signature that enables public key recovery. It also
includes the PublicKeyValidator class that can verify whether
a given public key is active for an account by looking in its
AccountRoot.
Amount#parse_quality is made currency-aware. This allows it to adjust for XRP as
the base currency, as well as for interest-bearing or demurring base currencies.
Currency#to_json should output a format that can be successfully converted back
to a Currency object via from_json. So for demurrage currencies it should output
the full hex currency code.
Currency#to_human on the other hand should always print something a human will
understand. For demurrage currencies we'll print the three-letter code for now.
This patch might regress the performance of the Currency class and by extension
the Amount class. Since Amount is on a lot of hot paths in the client we should
make sure this isn't a major problem.
As for compatibility, this patch is a major change, but it should maintain the
public interface very well, which the exception of some strange edge cases (e.g.
Currency.from_json(1337)), which weren't well-defined before anyway. Any code
that accesses _value directly (shame on you!) will need to be fixed. There
aren't any such references in ripple-client or the rippled test suite, so I
think we're looking pretty good.
