bitcoinmagazine.com
These days we often wax eloquent about the “early days of Bitcoin” and the great visionaries who participated in the discussions on protocol development. However we often forget that the cypherpunks of olde were human too — that early oversights & unresolved disagreements resulted in cumbersome idiosyncrasies that define our sacred blockchain today.
If you weren’t around in 2009 and want to get a taste of what it was like back then, come join the discussion in Ordinals land. We’re speedrunning Bitcoin Consensus.
What is the debate about?
Ordinal Theory describes how to serialize & track satoshis. These satoshis, when serialized, are called “ordinals”. We can associate chunks of data that we call “inscriptions” to these ordinals, thus creating a form of NFT on Bitcoin. It’s a simple concept, but the implementation of the client that runs ordinals is quite complex. Ordinals began as a passion project but exploded into popularity in a matter of a few weeks. Because of the rise in hype and complexity of the client, a lot of “bugs” in the client implementation were discovered. Due to the arcane nature of how the implementation actually works, a lot of these bugs & idiosyncrasies became the subject of market speculation.
The most notable of these idiosyncrasies has arguably become a feature, not a bug. On the OG Ordinals explorer site, ordinals.com, Inscriptions were displayed with a number whenever they were “inscribed”. These numbers were a fun and easy way to track how many Inscriptions there were and immediately became a focus for collectors.
A few weeks ago, the creator of Ordinals published a blog post about how these Inscription numbers have created undesirable consequences and how maintaining these numbers hamstrings further protocol development. Recently, I tweeted my opinion on the matter and it kicked off the first major debate in Ordinals land.
Narrowly, this is a discussion over maintaining or changing the current numbering of Inscriptions. More broadly, this is one of the first real community discussions over how protocol decisions are made. Broader still, this is a question of “what is the protocol, how do we define an ‘Inscription’”.
💡 Important Clarifications
- Ordinal — a serialized satoshi
- Ordinal number — the number given to an ordinal
- Inscription ID — the ID given to an Inscription, derived from the transaction it’s created in
- Inscription number — the number given to an Inscription based upon its order of recognizance by the ord client ← this is what the debate is over
- This is a rapidly developing topic. I don’t address the refactor inscription parsing or sequence numbering PRs in this piece.
How did we get here?
When Ordinals & Inscriptions went viral in early February, this once personal project spawned an entire vibrant ecosystem overnight. As hype grew we saw the genesis of 2 narratives: a tale of the Code and a tale of the Culture. At times they are interlinked but they could also be entirely distinct, much like a lot of Bitcoin today.
The Code
The ord client existed entirely on Casey’s personal github repo throughout the past spring. Hundreds of issues piled up as the entire NFT userbase piled into a handful of discord servers. Casey’s code and Bitcoin itself were stress tested.
A couple weeks into the frenzy, it became clear that some inscriptions weren’t being recognized by ord. These inscriptions mostly had to do with edge cases in either how Bitcoin works and how the ord client parsed through inscriptions. That led to some “missed inscriptions” that went into Bitcoin blocks but weren’t displayed on the ordinals.com frontend, therefore they didn’t receive an Inscription number. It wasn’t very clear how many were missing or what we even thought about those inscriptions… …were they actually “inscriptions”? This topic was discussed very little because there was a new kind of Bitcoin culture forming, one that brought with it a cacophony that drowned out much further technical discussion. For the time being, most of the rules of the protocol had to be intuited from how ord worked.
The Culture
The entirety of interest in Ordinals came from outside Bitcoin — from NFT collectors & degenerates alike. These are largely nontechnical folks, but also highly motivated to jump through whatever hoops needed in order to buy a jpeg (syncing a full Bitcoin node, running ord in command line). These newly christened bitcoiners immediately began collecting, trading and speculating on the hot new digital assets.
As Inscription activity heated up, ordinals.com quickly ticked towards Inscription #10,000. An iconic Twitter spaces bore witness to crossing the historic number — that same twitter spaces evolved into the de facto Schelling Point for Ordinals culture & events: The Ordinals Show. Casey was inundated with requests for interviews while the legacy Bitcoin community criticized & clutched their pearls at this new beast, slouching towards Bitcoin. It was an incredibly overwhelming period — the best of times and the cursed of times.
The topic of missing inscriptions was brought up in a couple confused github issues and discord threads. In mid-February the subject of these missing inscriptions came up on a podcast Casey was on. He put the issue up for vote to the hosts who voted to keep the Inscription numbering as-is, and then Casey tweeted this out:
The Curse
So what should we do about these missing inscriptions? Some projects began intentionally producing these “missing” inscriptions and created a sense of urgency to resolve the issue. In April, Casey put out PR #2307, coining the term “Cursed” for these missing inscriptions. The PR proposed giving these cursed Inscriptions negative numbers, with the plan to at some undefined point in the future “bless” the inscriptions by recognizing them in the ord client. They would then receive numbers whenever they were recognized.
Diving a little deeper, there are multiple ways an Inscription can not be recognized & parsed by ord. Raph describes 4 types of Curses:
🪄The 4 Curses (so far)
- More than 1 inscription in a transaction
- ord only recognizes inscriptions in the first (reveal) input, so inscriptions in other inputs are cursed
- If there are uneven tags (most popularly OP_66, but can be any OP_evennumber) within an inscription envelope the client considers the inscription unbound to a specific satoshi
- More than 1 inscription on a sat (now called “reinscription)
While these are the 4 types of clearly identified curses, we do not know what other curses may be discovered in the future. Perhaps these 4 are all that will ever exist (I doubt it), but this is an unknown unknown. Each of these existing & future curses would require community coordination to “bless” and such coordination is hard, often controversial. To commit to an unknown amount of future coordination events is generally bad protocol design especially when it could all be addressed today by not committing to preserving inscription #s.
It is worth noting that during the writing of this article we have discovered a new kind of cursed inscription, emphasizing the point I make above.
Some of us at the time, myself included, tried to bring up our concerns with the approach to maintaining Inscription numbering and the challenges it could introduce to future development. Ordinally, a key developer on the project, encouraged consensus on Inscription ID and leave numbering to the market:
The Consensus
Consensus in Ordinals has pretty much respected Casey’s hegemony & unilateral decision making. The personal repo era, migration to a github org, promoting Raph to lead maintainer, the various PRs & updates — all of these have been celebrated & embraced by most. Updates have been pushed with little community input and scrutiny but have largely been deemed desirable. We even changed numbers before with no community pushback when an inscription was created but not associated with a sat (“unbound”) resulting in an off-by-one error in inscription numbering. A major reason why there has been little community input is because very few people actually understand how the client works under the hood.
Today there are various forks of ord which power the ecosystem: marketplaces, wallets, aggregators, etc. These forks are updated with each iteration to the reference client. Each client generally seeks to maintain parity with ord. We at OrdinalHub have opted not to fork but instead rebuild the entire client in Golang and call it “gord”. Going through this development process has given us an intimate understanding of how the ord client works and the challenges in addressing current & future edge cases.
The Community however is largely unaware of work on github and the technical state of indexing. Very few users seem to understand how their Inscription gets identified & presented on a marketplace or in their wallet. Because of this, the Inscription number is their identity because it is their primary reference point to the asset & ecosystem.
The Case
To summarize my case: I wish to convince the “Cultural Layer” that it is not worth it to the long term success of ordinals to design the protocol around maintaining inscription numbering. I recognize that these numbers are special & cherished, but I think it’s more important to prioritize the long term sustainability of ordinals. If we continue to try to preserve legacy numbering going forwards it complicates protocol development and reduces its likelihood of survival.
Casey recently changed his mind about renumbering and laid out the reasons Cursed Inscriptions make development problematic in his blog:
The logic required to identify & track these cursed inscription types requires custom hard coding of each type and later reordering them back into the series. The process of “blessing” the inscriptions creates more surface area for community debate & potential governance disagreements. It also requires more coordination among ord forks & indexers, in many cases they would have to implement their own custom logic as well. From a technical standpoint, this would result in unintuitive ordering when there exists an extremely intuitive ordering: Block Height & txindex within the block.
Since we do not know the future types of curses that may be discovered, committing to keeping the Inscription numbers potentially brings more scenarios where we have to create weird technical solutions & require social coordination to solve a problem that does not have to exist.
Thinking long term — my personal opinion is that the primary use-case of Inscriptions will not be JPEGS & collectibles, but rather things that take advantage of Bitcoin’s data layer: rollups, state updates, data preservation & documentation, etc. In such a case we should be designing the protocol not for collectibles but for diverse functionality. Our descendants will look back on us and wonder what we were thinking adding this unnecessary complexity (and then they’ll just go back to Timechain sequencing).
All this said, I think there are very promising compromises & middle-ground solutions which reduce historical numbering changes while providing a less-encumbered way forwards. I hope to support some of these options as they develop.
The Collections
The most painful friction is with collectors & collections. The outcry against renumbering has produced “Love Letter[s] to Inscription numbers”, polls, and 🧡s to numbering. Many times, those of us most concerned with technical implementation discount the importance of the cultural layer. The Sub1k twitter makes a strong appeal:
Initial estimation suggests renumbering would have minimal change to earlier inscription numbers, but I don’t think that’s a very strong point as the outcry is against any change. I do think there are ways to accommodate for a change in numbering for many collections, by honoring “legacy” numbering or by expanding the collections (is it wrong to have ~100,092 in sub100k?). Sadly, there isn’t a solution for having a specific number like a birthday or a lucky number.
I also love the numbers and I want to keep numbering inscriptions. I just hope to convince you that going forwards it is not worth it to the longevity of the protocol to commit to keeping numbers stable. As I mentioned before, there are compromise proposals out there that preserve historical numbering while reducing emphasis on stable numbering going forwards. I think those may be reasonable solutions.
Metaprotocols
One criticism about changing Inscription numbering is its effect on metaprotocols utilizing inscription ordering. Regardless of my personal criticisms on design or feasibility of these metaprotocols — should a nascent, pre-1.0 protocol like ord, make poor design decisions in order to prevent confusion for metaprotocols built on top of it? I emphatically say no.
That said, I think there are an abundance of solutions these metaprotocols have at their disposal. In the case of BRC-20 the ability to rebuild current token balance state would be broken — “cursed” BRC-20 deploy/mint/transfer functions would distort entire token balances. However this can be addressed by coordinating block heights to update inscription recognizance to parity with ord, “freeze” with a version of ord, and/or “snapshot” balance state. Domo, the creator of BRC-20, has proposed similar ideas.
The same techniques could be utilized by all other metaprotocols such as Bitmap, Satsnames, etc. Some have pushed back on these ideas saying that “coordination is quite difficult”. To that I say no shit, that is why we can’t commit to it at the base protocol level.
Going forwards
This is really a discussion on protocol definition and governance.
Comparatively, this is the most careful & thought out proposal to ord since its initial release in January. This is the first blog post Casey has written in a year and the most public discussion he has participated in since February. While it may seem that decisions are rapid & sweeping, this is by far the most we as a community have discussed any changes to the ord reference implementation.
It’s an open source protocol so the community is free to fork from ord parity. You can choose not to update or implement a client you disagree with. However this is the absolute worst outcome and I would rather do nothing than have a significant community fork and I doubt ord would make a decision that creates such a split.
There have been various proposals for an Ordinals Improvement Process (”OIPS”). It’s clear the community wants to discuss governance now and I welcome this conversation.
As for definitions & documentation, my view is that we should have consensus around the following: core parts of Ordinal Theory (sat origination, tracking, & inscription association), inscription IDs, and valid ord envelope definition. From there we can discuss how the protocol might evolve and how the reference client may be built. Personally, I believe that a “valid ord envelope” should be as permissive as possible.
Overall, I think the community has handled this pretty well. There have been some unnecessary spats but it’s quite minimal compared to the scorched earth at the height of the Blocksize War. Ordinal Theory is Casey’s love letter to Bitcoin. He & those close to the project have devoted a significant amount of their lives to this idea and we all wish to carry on in this happy shared delusion. I am confident there are productive paths forward.
I would write way more on this, but this piece is already way over my word limit so I’ll see you on Twitter.
This is a guest post by Charlie Spears. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.