[...]

b) Tiered pricing based upon the long description cannot be performed as the protocol is agnostic to the description.

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.



Client visualization
     
Client visualization alternative - reflects the reality that there is only 2 levels

We at BitcoinTangibleTrust vouch for led_lcd he supported us with our initial launch and has shown that he is willing to help Counterparty applications and features succeed.

We look forward to supporting this experiment because he not only supported our launch, but he is ridiculously smart and is a Counterparty member to watch carefully.

Go led_lcd!
Make it rain GIGAHASHES!

So the above says that trading a user defined and user issued asset involves counter party risk (the issuer not keeping his promise to redeem the asset if desired) but the counterparty website claims: "Trade, BTC, XCP and user-created assets with no counterparty risk"  

Is that the biggest dex order yet ? Man thats promising.

I feel like that is narrowminded.

What possible benefit does it have other than security?

Oh dearie my! Will you look at that!

For anyone who is interested in making such a peg, I have come up with a few examples which would show how you do it.

It's still a good service! And indeed I think that if a trusted exchange (or even a trusted community member) were to implement something like this on Counterparty, it would gain adoption.

You cannot eliminate counterparty risk from an asset-backed currency peg, as there is no mechanism at the protocol level to stop the issuer (i.e. the user with the private key of the address with the XCP backing) from withdrawing funds. I still think though that is a really good use-case.

A currency peg that actually requires no trust is making a CFD on the price of an asset to which you would like to peg your holdings in XCP. The effectiveness of the peg, however, depends on one's leverage, which in turn increases one's risk. For anyone who is interested in making such a peg, I have come up with a few examples which would show how you do it.

Does any sort of collateralization requirement denominated in XCP limit the total amount of assets that can be traded on the exchange to the market cap of XCP? How do you work out the margin requirement? Or is the idea that any asset in one's possession can be used as collateral, but represented as an XCP equivalent?

There is nothing to stop people from issuing LTC (or whatever) trading derivatives, similar to how XBTC has been created on Counterparty as essentially a proxy for BTC. We encourage folks in the community to come up with and enact these kinds of use-cases (in a thoughtful, responsible manner, not unlike how XBTC was created and is operated).

What about requiring the issuer to put collateral (xcp) into the system. For example: I issue LTC within Counterparty and have to put up xcp worth the amount of LTC that is bought from me. This would make the system more safe/reliable and boost the demand for xcp. 

@LED_LCD, @CityGlut @Community

Video Update: Things are going well!

FWIW, if there are any developers interested in keeping Counterparty going once multisig abuse filters are in place, there is no reason the recommended plan cannot work with a fork of Counterparty instead of the original developers.

On a sidenote, the counterparty video is coming along ! Get excited ! Trailer is coming tomorrow or Tuesday