Cross post from my reply at the official forums
https://forums.counterparty.co/index.php/topic,150.msg1387.html#msg1387 regarding a hierarchy for utility and for controlling asset issuance costs:
When I suggested the hierarchy, I didn't give any thought about implementation. It seems people like the idea and I think there is a utility to this idea so here's an implementation idea which is pretty simple but enables pretty much what people are talking about.
Indeed by itself it would be too much of a code change. The asset names are coded as they are in many different tables and having long asset names would cause problems with the limited space we are working with a Bitcoin transaction.
So here is what I suggest to be a simple solution which is backwards compatible and forwards compatible with more adaptations to the price for issuing assets:
There are only two levels of assets distinguished at the protocol level. More than the second level is merely a client side visualization.
1) Add an additional column to the 'issuances' table called 'assetLongName'
2) Add an optional parameter to issuance --asset-long-name
3) A 'top level' is an asset which must have the asset name = asset long name (this can default if no asset-long-name is entered)
4) A 'top level' asset must conform to existing naming conventions
5) An 'lower level' asset is an asset which is only readily distinguishable by the asset-long-name. The asset name (ie the value being used now and passed around in the messages in transactions) cannot be user specified. The asset short name is generated at #6
6) When issuing a 'lower level' asset, the issuer cannot specify the asset name. The short asset name is generated from a hash of the asset-long-name (something like this
http://stackoverflow.com/questions/548158/fixed-length-numeric-hash-code-from-variable-length-string-in-c-sharp)
7) When issuing a 'lower level' asset, in the asset-long-name a 'top level' asset name must already exist before the first period '.' in the string (left to right) .
Notes:
* Top level assets are premium priced - for example 5 XCP
* Lower level assets are priced enough to stop spamming of the network - for example 0.1 XCP
* Pricing can be replaced with proof of stake or whatever later
* By default clients can filter top level assets by only getting assets where the short name = long name
* In the long name for lower level assets, after the first period '.' most characters plus a few special characters like GLaDOS mentioned goes. It is up to the clients to fold up the names in a tree structure and organise it nicely. Clients can use lazy loading of tree structures to reduce overhead.
* All internal counterpartyd code continues to stay referencing the existing short name so it will limit recode
* It would then require some rework to allow commands such as 'order' 'send' to be able to reference the asset long name. However, this is not a #1 priority as the short asset name could be used in the interim.
* There is a limited space available for unique (short) asset names so there will be some collisions with the hashing of the long name. If the hash is already taken, too bad you will need to vary the long name a little bit. That's the consequence of buying a lower level asset name
* Including a unique index on the asset-long-name column of the issuances table should be sufficient to maintain performance on this table
EDIT:
Some examples to show what I'm talking about.
Asset Short name Long name
BITT BITT
KEOdAi3q BITT.spanish.dubloon
OIu3waqn BITT.spanish.dubloon#1
RPGGAME RPGGAME
LPJhiowG RPGGAME.ruby.cracked
jrOyehHG RPGGAME.ruby.perfect
BANK BANK
OIJFE7ig BANK.I can type whatever I like
Client visualization
BITT
+-spanish
+-dubloon
+-dubloon#1
RPGGAME
+-ruby
+-cracked
+-perfect
BANK
+-I can type whatever I like
Client visualization alternative - reflects the reality that there is only 2 levels
BITT
+-spanish.dubloon
+-spanish.dubloon#1
RPGGAME
+-ruby.cracked
+-ruby.perfect
BANK
+-I can type whatever I like
