`null` asset description and DB bloat

[Jpja]

New behavior in 9.61 is that a special null asset description set in the CNTRPRTY message makes Counterparty duplicate the previous asset description. This is a concern as the BTC fee of updating an asset is no longer proportional to the DB impact.

Solutions were offered in the dev telegram chat.

1. Limit asset length.
2. XCP fee on updating asset.
3. Normalize the DB; separate table for descriptions.
4. Store null as the description and modify the API to perceive the last non-null description as the current one.

[reinamora137]

Any of these ware actually acceptable in my view if the xcp are only for all asset RE-issuances not the initial issuance. It encourages well thought through art and asset quantities before squatting on a name.

Although it sounds like there are reasonable proposals for the long asset descriptions being pulled from btc or even addrindexrs which would need some testing. A hard limit on description length overall is detrimental however.

Perhaps a fee and a new technique of storage to promote usage of xcp

[keyuno]

XCP is specifically designed to tackle the issue of spam and is recommended for implementation in any scenario where spam poses a concern.

The potential consequences of altering asset structure remain uncertain, including the possible narratives that could emerge and their impact on the value of assets before and after such changes.

For instance, certain marketers have set a precedent by constructing a narrative emphasizing asset hierarchy, which involves distorting the true nature of the prunable feature of OP_RETURN concerning immutability. This misrepresentation is frequently aimed at individuals with limited technological understanding, seeking to secure support for their project.

The implementation of XCP for spam prevention stands out as an elegant solution to these challenges.

[keyuno]

Solutions were offered in the dev telegram chat.
Store null as the description and modify the API to perceive the last non-null description as the current one.

Why hasn't this proposal been discussed on GitHub, where it can be properly addressed and documented?

[Jpja]

Why hasn't this proposal been discussed on GitHub, where it can be properly addressed and documented?

This is an issue from March : https://github.com/CounterpartyXCP/counterparty-lib/issues/1224
Fix announced on Oct 27 and issue closed.
I was made aware of it on Nov 22 and warned that this will open up a spam vector. But too late to prevent it from being added to 9.61.

Normalize the DB; separate table for descriptions.

Here : CounterpartyXCP/Forum#109 (comment)

[jdogresorg]

Why hasn't this proposal been discussed on GitHub,

Cuz not everything happens on github... there are actual telegram channels where the community members can talk about their use of CP, and what features they want... there is also a dev channel of over 150+ devs who discuss dev options, etc..... quite often, real-time communication is much more efficient and a more collaborative/friendly tone.. vs github, which seems to have devolved in recent times into more of a tense tone with lots of criticizing ideas and "we should just do X".... but very few actual CIPS and ideas pushed forward.

If you guys dont like how things are done in CP... your free to suggest your own CIPs and push them forward... easy to criticize other peoples ideas, tougher to write up your own CIPs and push them forward (side-note: still need to check out your bitcoin-agent PR... looks promising)

TLDR... Agree on a path forward, write up a CIP, make the changes you guys want to see, submit a pull requests and wait for other devs feedback..

[jotapea]

FYI, another space where concerns about this were brought up: https://github.com/CounterpartyXCP/counterparty-lib/pull/1262#issuecomment-1823022095

And I’ll continue repeating this: GitHub must be the main place to have formal discussions about changes to the protocol code. Chats are informal, and variable. Not everyone is in the same “one” chat.