Currency codes should allow more than 3 characters

[lilyball]

Currency codes are limited right now to 3 characters. This matches the conventions for talking about real-world currencies, but it seems like an unnecessary and arbitrary limitation when talking about stellar currencies. The restriction should be lifted.

It makes sense to put some limitations on the currency code. I'd suggest something like [a-zA-Z_][a-zA-Z0-9_./-]*. That is, allow alphabetic characters + _ as the first letter, then add in digits, ., /, and - for all remaining letters. I picked ., /, and - merely because they seem like the most likely punctuation someone might want to use when e.g. building some sort of hierarchical currency code. Other punctuation should be avoided unless someone comes up with a good reason to support it.

I'd also say that if you need to restrict the length for some reason (e.g. inserting into a database), I'd suggest a 255 character limit. That's more than large enough for any reasonable purpose, while not being absurdly large.

Pros:

• Allows for custom currency codes to be created that are unique without having to worry about any UI issues surrounding disambiguating e.g. IOU credit issued by two different accounts.
• Similarly, allows one account to issue multiple distinct credits that serve the same fundamental purpose (e.g. IOU) while still being distinct (e.g. because they represent different owed assets, or are issued to two different groups of accounts and needs to be prevented from trading between them).
• Custom currencies can be descriptive, making it much easier to talk about them.

Cons:

• This might make it easier for someone to try and embed messages into the ledger, via a series of TrustSet transactions for fake currencies. However, I assume it's already possible to encode messages in e.g. destination tags on micro-payments, or perhaps SetRegularKey transactions (depending on what sort of validation the key is given), or even a sequence of offers that cannot possibly be filled (e.g. between currencies with an issuer that is guaranteed to never issue those currencies). Expanding the currency field would only make it easier (and cheaper due to fewer fees), as opposed to enabling something that is otherwise disallowed.

[lilyball]

Incidentally, according to the Ripple docs on Currency format, it sounds like Ripple had plans to have some sort of registry of custom currencies that are identified by a 160-bit hash. I don't know if there are actually any concrete plans around that, or what the design of the currency nodes are, or if there was any discussion over simply allowing arbitrary strings. Of course, the same docs also talk about a version and scaling factor for national currencies, but I don't know how those are supposed to be represented or if they actually exist in Ripple right now.

[xekoukou]

Using a hash as identification for a currency would be really nice. This will allow the existence of commodity currencies, whose description will be the hashed document.

[jedmccaleb]

this is done now