Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread - page 308. (Read 1276817 times)

I think that we agreed that such a scheme would be better handled at the UI level.

Despite being so innovative, XCP has become victim to pump and dump

Despite being so innovative, XCP has become victim to pump and dump

Did this great idea ever gain traction?

I seem to remember it was suggested around the time that the OP_RETURN saga kicked off.

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

Mine from your Counterparty wallet
For immediate sale is the asset GIGAHASH. Each GIGAHASH is backed with at least 100% of the value of each GIGAHASH. The price of each GIGAHASH is being sold at an initial rate equal to the volume weighted average price for the 14th April 2014 (GMT) on CEX.IO . Furthermore you will receive 10% more GIGAHASH when you pay in XBTC.

Crossposted from https://forums.counterparty.co/index.php?topic=249

I'm proud to announce the immediate launch of the Spolcyc Mining Experiment for Gigahashes (SMEG). SMEG is demonstration of the super awesome-ness of Counterparty and what can be set up over a cup of orange juice. My friends and I had a few spare ASICs lying around. I decided I might as well do something interesting with them and here it is.