Subassets on Numerics

[adamkrellenstein]

https://github.com/mikeinspace/Glyphs/blob/main/README.md

[reinamora137]

Yes please. Will certainly free up usage of the root level namespace with no apparent downside.

[arwyn6969]

Great idea

[mikeinspace]

Definitely in favor of sub-assets on numerics. There's no reason to treat numerics as lesser than named assets in my view.

XCP fee has been clarified to be an anti-squatting mechanism (not an anti-spam mechanism as some have previously claimed) and since you cannot really "squat" a numeric, then all the fee really does is add friction for users.

[b1u3y]

Would subassets for numerics be an integer or a string?

If no XCP was paid for the main asset, should subassets be free too? This decision will greatly affect usage, and adoption. Free subasset mass adoption could lead to assets being tracked in code & db by main asset, instead of UTXO or address.

[mikeinspace]

"If no XCP was paid for the main asset, should subassets be free too"

@b1u3y I think its important to understand the role of XCP within the context of asset registration. It isn't an "anti-spam" mechanism but, instead, an "anti-squat" mechanism. Therefore, I see no distinction between sub-assets on named assets vs numeric assets. You can't "squat yourself".

[arwyn6969]

I for one would love to see named sub assets on numerics. Opens a world of possibilities. I'm talking for me personally But I can image so many users would love this.

[jotapea]

(Would have written here much earlier if I wasn't blocked, but some already know my opinion about this.)

---

I believe this change is detrimental to XCP, as I see clear downsides in the incentives for obtaining and utilizing the XCP token for named asset registration. Which is, as of today, still its main utility.

The tradeoff of being able to issue an asset XCP-free is that your name must be a number. Aside from this, a numeric asset (by itself) is treated exactly the same as any other non-numeric asset. And this is great!

But then, the users that spend/burn XCP to issue an asset, have the privilege of continuing to issue subassets related to their (super)asset. If this privilege is extended by making these subassets XCP-free, then, I believe, the main utility of the XCP token is elevated:

XCP will be burned for the issuance of named super-assets.

So, I am in full agreement with eliminating the fee for subassets. But I'm against this one, because I believe it clearly lowers the utility of the XCP token.

---

https://github.com/mikeinspace/Glyphs/blob/main/README.md

This can be done with named subassets (except being "stamps numbered", which is "their choice", and not Counterparty's responsibility).

[mikeinspace]

My take has always been that the point of burning XCP for asset registration is to act as an anti-squat mechanism, because the size of the usable "named asset" name-space is limited, particularly if you want an english-language word rather than a scramble of random characters. The numeric namespace, by comparison, is vast and doesn't require the same anti-squat mechanism.

Named sub-assets also can't be "squatted" because the same name can exist on any number of subassets. They each exist in their own name-space.

Attempting to "engineer" methods to lower the xcp supply as a means to pump the price is misguided in my view and extremely counter-productive. Adding barriers to entry (friction) only makes it more difficult to onboard new users. The way to "pump" the price of xcp is to grow the user-base by several orders of magnitude. There were 3 assets (in total) registered yesterday. We are so far below any reasonable measure of usage, that the last thing we should be doing is adding friction to the user experience as a means to pump the price of xcp. Onboarding users and use-cases should be the #1 priority. Full stop.

This can be done with named subassets (except being "stamps numbered", which is "their choice", and not Counterparty's responsibility).

I completely agree that accommodating new use-cases and onboarding new users is not "counterparty's responsibility". Counterparty is free to continue catering to its ~1000 users and 3 asset registrations per day. What we're attempting to do with Glyphs is bring back the traffic Counterparty once had with SRC20. Presently seeing 2,000 asset registrations per day.

[davestaxcp]

so the main difference from Named and Numeric is:

• one is named and enables upper and lowercase letters (1-256 w/ lowercase in named subassets)

• the other is Numeric ... so why wouldnt Numeric Subassets also be Numeric?

ex:

BACON.crispy

A15876941647089082000.B15876941647089082000

---

if the original idea was for further customization with named assets, it feels "on the same mindset" to let users create free Numeric Subassets as long as they cannot be named.

---

Since Mike points to this theory and then goes the extra mile with how they could be encoded in a similar way with JPJA's CIP33 I am in favor of this upgrade.

I think the idea is quite cool.

"Relevant meta-data (ticker, supply, etc...) will be added through an onchain JSON envelope using OLGA-encoding. In this way, A5433937813514022010.A5433937813514022010 can be represented by something like JOIN•THE•FLOCK in wallets and explorers."

---

But this feature of turning Assets and Subasset combinations into Rune like tickers with "JOIN•THE•FLOCK" as 'Glyphs'.... why not also do them with Named Assets as well?

• Why specifically use Numerics and Numeric Subassets?

• What would be the advantage or disandvantage to creating Glyphs from the information from Named assets?

• Could 'Glyph Theory' encompass Named Assets in any manner where they might be MORE saught after to create Glyphs from? For some reason, this seems more "on the same mindset" of rewarding more features for Named Asset creators due to the burning of XCP (and symbolically the original Bitcoin burned for that).

---

I understand the example @mikeinspace presented when referencing the named Counterparty asset DOG. He states, "no one else would be able to create a token ticker starting with the word 'DOG' "

• Would this mean that any Numeric Glyph could take the name 'DOG' and any numeric string on a Numeric Glyph could use that name again? Similar to Solana or Ethereum names that can have a different Contract Address?

• Or would it simply be a market initially of new squating of creating Numeric Glyphs and then picking the common names?

---

the last question I would have is if #1843 is needed for the underlying theory of this upgrade?

I think outside of the idea of Glyphs specifically and Fair Minting this would be a great feature on its own.

[jotapea]

This conversation should be limited to the technical aspects of the change. We should not be speaking so much about external "marketing" concepts like "Glyphs" and "OLGA-encoding", which have nothing to do with the core Counterparty protocol.

I still believe this should only be considered after https://github.com/CounterpartyXCP/counterparty-core/issues/1840 is deployed.

[adamkrellenstein]

See https://github.com/CounterpartyXCP/counterparty-core/pull/2195