Symbols

[casey]

Should inscriptions have short, unique names?

Idea:

An inscription can contain a symbol, which is a u64. The u64 is mapped to a string of upper-case characters A-Z using the same algorithm as ordinal names. The first inscription in the chain to declare a symbol gets it. If a later inscription has a duplicate symbol, it behaves as if it has no symbol.

Knowing which inscription has which symbol requires a full node, since you have to see all previous inscriptions, which requires indexing every transaction.

To prevent short symbols being taken quickly, only allow symbols if the ordinal with that name has already been mined. So symbols would have the same supply schedule as ordinals.

Allow linking to inscriptions by name with /NAME

[casey]

Take advantage of the commit/reveal structure to avoid sniping. If the index sees:

• Commit A with name X
• Commit B with name X
• Reveal B with name X
• Reveal A with name X

Without getting too crazy, the name should go to inscription A, because B could be a sniper that saw reveal A in the mempool and tried to get ahead of it.

[tyjvazum]

I understand that perhaps this wasn't the intended usage when this issue was opened, but I see several problems with this functioning as a name system (as it was stated to be used for in issue https://github.com/casey/ord/issues/1657) in any real use cases where people might want to use names.

First, it seems that names longer than 11 letters wouldn't ever be allowed, and the entire range of 11 letters wouldn't be valid either (since names start at "nvtdijuwxlp", going from there to "aaaaaaaaaaa" is all valid, but going the other direction to "zzzzzzzzzzz" is all invalid).

Second, 10 letter names wouldn't start to be available until the end of this year (starting at "zzzzzzzzzz"), and the entire range of 10 letter names wouldn't be available until ~2042 (ending at "aaaaaaaaaa").

Third, with 9 letter names not starting to be available until ~2042 and the entire 9 letter range not being available until ~2061, this system would seem to be effectively limited to some 11 and 10 letter names for the foreseeable future, and maybe some 9 letter names, eventually, if one takes a time horizon of decades.

These limitations all seem particularly detrimental for the use case discussed in issue https://github.com/casey/ord/issues/783, assuming artists don't like being required to choose from a limited set of 11 letter names (without numbers or even the "_" character).

It also feels at odds with the current display of the "name" representation for an ordinal, in a way that's likely confusing, because it would make that be merely something the ordinal is unlocking the ability for anyone to inscribe, not a name that's truly associated with the given ordinal (unlike the "integer", "decimal", "degree", and "percentile" notations).

[RagnarLifthrasir]

Thoughts on this proposed Bitcoin Ordinals DID Method Specification?

[casey]

Thoughts on this proposed Bitcoin Ordinals DID Method Specification?

Unfortunately I'm pretty bandwidth constrained just thinking about and trying to get back working on the core inscription protocol, so I don't really have the time to look at things like this.

[casey]

@tyjvazum These are all good points. I think the ideal solution would be to allow names of any length, with the restriction that names less than the more recently mined sat name are not allowed.

[casey]

I think I'm inclined not to do this, for a number of reasons:

• Miners can take desirable new symbols, even if users bid a high fee for them.
• Redundant with sat names.
• Introduces a race condition with other inscriptions trying to get the same symbol.
• Different implementations that see different inscriptions may disagree on which inscription has which symbol.