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
[quote author=Global_trade_repo link=topic=150.msg1387#msg1387 date=1395236512]
…
…
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) .
…
[/quote]
Are you saying that we fold the long asset names into shorter ones? This could work if we really do have 256^8 = 18446744073709551616 names according to PhantomPhreak.
Let’s see if I get this from the user’s view with an example:
1. User issues asset CAKE.
This steps works normally by creating the top level asset CAKE.
2. User issues asset CAKE.CHOCOLATE
a. Since this is not a top level asset (it has the dot), the client software will hash CAKE.CHOCOLATE and fold it into range using hash256(CAKE.CHOCOLATE) % 18446744073709551616 = 14342628182955096483. Now it will encode the ASSET_ID of 14342628182955096483 into base26 to get a valid asset name of FUHSJLMRZXYYVR.
b. Client checks that I own CAKE. If so, it sets the protocol to issue FUHSJLMRZXYYVR setting the long name to CAKE.CHOCOLATE
3. User issues asset CAKE.STRAWBERRY
a. Again, the client wil hash CAKE.STRAWBERRY using hash256(‘CAKE.STRAWBERRY’) % 18446744073709551616 = 12954728149517977030 resulting in this asset name: FFTOTODXVAJETA
b. Client checks that the user owns CAKE before issuing FFTOTODXVAJETA with the long name=CAKE%2ESTRAWBERRY
4. User issues asset CAKE.DOUBLEFUDGECREAMYVANILLAWITHCHOCOLATECHIP
a. Client hashes hash256(‘CAKE.DOUBLEFUDGECREAMYVANILLAWITHCHOCOLATECHIP’) % 18446744073709551616 = 14967343411115770189 or GAVXSUXGXBLXSV
b. Client checks that user owns CAKE. Unfortunately, a squatter knew that the user would be issuing this delicious cake and squatted the asset name GAVXSUXGXBLXSV. It just means that the CAKE owner has change the long asset name a bit to avoid this collision. Because the squatter does not own CAKE, the long asset name for GAVXSUXGXBLXSV could not be CAKE.DOUBLEFUDGECREAMYVANILLAWITHCHOCOLATECHIP.
5. When we buy/sell CAKE.CHOCOLATE and CAKE.STRAWBERRY, we will actually be exchanging FUHSJLMRZXYYVR and FFTOTODXVAJETA through the Counterparty protocol. Our clients/blockscan will show the long asset names.
As far as I can tell, this suggested implementation should work and be compatible with the existing protocol.
This is actually another great suggestion the more I think about it now. It reminds me of the 8.3 short/long filename. It should be okay to allow lowercase characters, numbers, and symbols for the long asset name since it will be hashed and encoded into base 26 anyway.
Since Global_trade_repo’s proposed implementation seems so elegant, I checked the code to estimate how much change would be needed. It’s not that bad.
Summary of Proposed Changes
===========================
1. Add asset_long_name column to issuances table
2. Asset Issuance with pseudo python code in issuance.py file: <br /> if '.' in asset:<br /> asset_long_name <= asset<br /> asset = asset_long_name.split('.')[0] # top level asset name before the dot<br /><br /> fetch asset last_issuance to check that top level asset exists/same source<br /> if issuances:<br /> if last_issuance['issuer'] != source:<br /> error('top level asset not issued by this address')<br /> else:<br /> error('top level asset does not exist')<br /><br /> # fold asset_long_name back into asset<br /> asset_long_hash = hashlib.sha256(asset_long_name)<br /> asset_long_id = int(asset_long_hash.hexdigest(), base=16) % 18446744073709551616 <br /> asset = get_asset_name(asset_long_id) # remember to check id valid range<br /> <br /> fetch asset last_issuance # could be normal or folded asset here<br /> continue validating as before plus composing/parsing the new field <br />
The asset_long_name column will work basically like a non-updateable description column. It does not look like the description is updateable yet. But if it’s meant to be updateable later, it’s best to leave it out during issuance to make room for the asset_long_name.
3. Instead of a new asset_long_name column, an alternative proposed on the other forum is to use special markers ~ in the description. Just prevent updates to the equivalent asset_long_name embedded between the markers in the description field. Or prevent description updates if there are special markers for folded assets. I think it’s much simpler to just add another column now.
[quote author=Global_trade_repo link=topic=150.msg1387#msg1387 date=1395236512]
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.
[/quote]
Please give some thought to make this generic and work better in other blockchains that are move friendly to these protocols. Several altcoins have 140 character ‘message’ options. If you only think about what’s politically feasible in the bitcoin blockchain, other alternatives will end up gaining market share for real trading.
What’s the actual amount of data realistically needed to have a hierarchy of asset issuance? Come up with a rational justification for that first instead of just “oh this fits in Bitcoin”