Subasset max length - Should it be 250 chars?

The Subasset CIP about to be implemented will allow names up to 250 chars. On Slack there have been voiced concerns that 250 chars is too much.

It will make subassets
1- non-displayable in wallets
2- non-memorizable
3- non-distinguishable

For #1 I think the solution will be to have the wallet show the first X characters, followed by …, and then the full name on hoover. Don’t know if this will work on phones though?

For #2 and #3 there are all sorts of potential problems with deception and fraud, e.g. trading the wrong asset on the DEX. However, this is very limited problem since only the owner of the parent asset can issue subassets. Say PIZZA issues PIZZA.PEPPERONI. It can never happen that some random fraudster tries to sell PIZZA.PEPPER0NI. The only one who can do this is the owner of PIZZA who would then attack his own sub-asset space.

My personal recommendation is a max length of 40 chars. It will make the subasset space cleaner, less confusing for users, and easier to implement for developers/designers, yet provide sufficient length for issuers.

With 40 chars the owner of PIZZA can issue

I was about to go into a “we already decided this a while ago when discussing the CIP rant…” but…

I agree this is worth discussing again. What can a wallet do with a 250 character asset name?

It is an easy change now before the subassets code goes live. It would be a harder change later.

You can extend the asset name length in the future. But if we allow 250 characters now, and someone manages to issue a 250 character asset (which is difficult!), we can never remove it from the database.

Asset names are 12 characters now. So 40 characters would allow for another 27 characters worth of subassets.

I’m in favor of shortening this to 40 characters. I can’t think of a use case for more than 40 characters apart from abuse.

The feedback on slack is split between leaving the length as is and shortening it. There are arguments both ways.

The CIP was discussed publicly when it was introduced. And a bounty was raised for this specific CIP. We should not change it now.

1 Like

Not changing something now simply because “a bounty was raised for this specific CIP” is not a valid argument.

People donated XCP specifically for this CIP to be implemented. If the Counterparty Foundation takes that bounty and implements something else, that breaks a social contract.

This is an arguably minor change and therefore a minor infraction. But I think we should have a very good reason to make any change at this stage of the process. I haven’t heard any arguments compelling enough to make a change now.

1 Like

I tend to agree with Devon that the subassets should be implemented as the CIP states, as that is what the bounty was collected for.

Currently no one will be able to register a subasset name longer than 38 characters anyway. If/when CIP6 is implemented and 250 character asset names are technically possible, then we should implement a change to limit the subasset character length to whatever consensus is.

TL;DR… Roll out the CIP as currently spec’d since funds were collected, change character length limit in future.

I agree with JP.

If there is great demand for a 250 character asset length in the future we can consider expanding it in the future.

There is no way to turn back once we have assets over 40 characters so we should not be hasty when making this type of change to Counterparty.

I made some arguments in slack channel and I don’t want to re-articulate all of it here. But I will simply add that if there is no technical burden to having the 250 character limit and as stated, there is already an inherent technical limit of about 38 characters, then why would there ever be a need to later reduce the character limit from 250? It does not matter whether or not anyone uses up to 250 characters or not (when it becomes feasible to do so). This is a completely ignorable part of the spec, absent of technical burden on CP platform.

Injecting a potentially premature opinion about how the protocol is currently used and how it will be used in the future is an example of developer intrusion and over-reach, which is acceptable for an app design but not so much for a broader protocol level design.

The simplest comparison is the DNS spec for domain name length which is 255 characters. Most domains are much shorter. The spec was not revised to reflect real world usage patterns. Because it does not matter and does not hinder.

I easily conjured up some potential use cases for longer sub-assets with barely any effort. I have no personal interest in the length but I think it has more potential for use than others. But my main point is… it does not matter either way.

All this to say… relax. :slight_smile:


I was the one who unintentional spread misinformation about the 38 character description limit. I was wrong about that.

It is possible to generate a transaction with a 250 character subasset. It is just difficult and expensive. It requires bitcoind 0.13 to relay and/or manually forming a transaction (outside of counterpartyd) and requires several multisig outputs which each require dust and waste bytes in checksums.

I don’t see a compelling use case for 250 character assets. But I think the spam protections in place are adequate to prevent harmful abuse.

What is the argument for limiting again other than it’s hard to change back if abused? why impose an artificial limit? go big or go home :slight_smile:

1 Like

The only clearly articulated argument I’m aware of against 250 character subassets is at the top of this thread.

#2,3 are meh. #1 can be accommodated by the wallet/site. If someone is going to be scammed by a misspelled word, the difference in characters isn’t going to matter much, both options are very long.

I can’t comment on the technicals for I am not worthy, but as for setting a bad precedent, I would stick with the CIP. my $0.02

edit, no idea why all BOLD, lol