Token Trees (sub-tokens)

A protocol improvement allowing for the ability to create token trees or sub-tokens that split off from a parent would be extremely useful for developing platforms around Counterparty.  I’m imagining it would look much like a directory tree allowing for multiple levels of subdirectories (or in this case sub-tokens).  These could all be controlled by the issuing address and various permissions could be applied to each level.

Why do you think that this is important at the protocol level? This could be handled at an application level.

It eliminates the possibility of trying to create an asset that already exists.  Once you own the parent asset, you can create as many child assets as you need.  I’m working on creating a site where each user needs a unique token which is issued for them through the application.  It would be much cleaner if I could create a parent token for the site, then create child tokens for all the users.

Interesting idea actually. It would basically make it so there could be as many duplicate names as you want, just all under different parents (which would show as a prefix or something). Which also gets rid of the problem of having to worry about name squatters when you want things like different voting assets (VOTEONE, VOTETWO) etc.

I knew I read something about this on the Bitcointalk Counterparty thread:

Adam’s opinion - https://bitcointalk.org/index.php?topic=395761.msg5791921#msg5791921

Ahh, nice, makes sense this discussion would have already happened to some extent.  Using the asset description field does allow for much of this, although it doesn’t solve the problem of the limited number of unique asset names.

Limited? “Asset names are strings of uppercase ASCII characters that, when encoded as a
decimal integer, are greater than 26^3 and less than or equal to 256^8.” It’s a huge space and with the 0.5 XCP fee or even if it’s lowered to an XCP satoshi, it is impossible to run out of asset names.

I support OP’s idea - at least a simplified implementation of it.
E.g. there could be two classes of assets: Standard (as all assets are today) and child.

A standard asset can have any number of child assets, but a child asset can not have any children. In all other respects these two classes would be similar.

The advantage is that MYTOKEN could have child assets such as MYTOKEN.VOTEONE, MYTOKEN.FORUMACCESS, etc. and name squatting would not be a concern.