For anyone that doesn’t follow the #spec-proposals slack channel, I’ve implemented subassets in the XCP Wallet repo based on my proposal.
Subasset Proposal - Counterparty Subasset Proposal · GitHub
XCP Wallet repo - GitHub - loon3/XCP-Wallet: Counterparty Chrome Wallet reboot
You can create subasset issuance txs via Chrome-Extension/test/register_subasset.html
This is still under development so I recommend using a new passphrase for testing.
Here is my Counterparty Improvement Proposal (CIP) for subassets
Great initiative, J-Dog!
Subassets are scheduled to go live - http://counterparty.io/news/development-update-enlarging-the-team-and-laying-out-our-roadmap/
It’s important to set all parameters right. Once released, it is difficult to change them, and I wonder:
What is the optimum max length?
Which characters should be allowed?
How much should the issuance fee be?
Should a child asset be allowed to issue its own child asset?
My opinion:
-1. It should be possible to display an asset name on one line on a mobile device. It should also be easy to memorize a name and differentiate an asset from any other asset. Otherwise the important uniqueness property is violated. I think the sweetspot for max length is somewhere around 30-40 characters.
-2…For the reasons mentioned above, I vote for [A-Z0-9.-]. A dot must follow immediately after the issuing asset’s name and must be followed by [A-Z0-9], i.e. not another dot or a hyphen. A hyphen cannot be next to another hyphen or a dot.
-3. Is a fee necessary? Unlike for regular assets, a subasset namespace is not a public resource (no first come, first served - the asset owner has the sole right to issue subassets). However, if a fee is needed to protect Counterparty servers from overloading, then an apt fee should be set for this.
-4. Currently I think it makes most sense if XXXX can issue XXXX.Y but only XXXX.Y can issue XXXX.Y.Z. Another option is that XXXX can issue both XXXX.Y and XXXX.Y.Z while XXXX.Y cannot issue any subassets. However, I am eager to hear arguments for and against. May change my mind on this.
I merged CIP 4 in Draft status.
Accepting a CIP is no guarantee that the CIP will be adopted or code will be merged to support it. Another author might submit a competing CIP that solves the problem of subassets.
After a CIP is merged in draft status, it will be accepted or rejected at some point in the future. For a Standards Track CIP to move from draft to active status, it must have code that implements it.
@jdogresorg - Do you have any plan to submit an implementation for CIP 4? Or do you know anyone would be interested in writing and testing the Python implementation?
@deweller - I do not code in python, so I will not be submitting an implementation for CIP 4. I believe @robby_dermody recently said that either himself or @rubensayshi would probably be writing the implementation in the coming months if no one else does.
yeah, ruben or I…it’s on our list (if it’s me, it’s something I’m looking to start after this build script revamp work I’m doing not to move to Docker)
jdog, we need to get you on the python bandwagon! 
Although the CIP is ready, it won’t hurt to hear what new community members have to say. I started a new thread where the CIP can be discussed
