The Great Inscription Renumbering Debate: The Code & The Culture

Please fol­low and like us:

These days we often wax elo­quent about the “ear­ly days of Bit­coin” and the great vision­ar­ies who par­tic­i­pat­ed in the dis­cus­sions on pro­to­col devel­op­ment. How­ev­er we often for­get that the cypher­punks of olde were human too — that ear­ly over­sights & unre­solved dis­agree­ments result­ed in cum­ber­some idio­syn­crasies 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 dis­cus­sion in Ordi­nals land. We’re speedrun­ning Bit­coin Consensus.

What is the debate about?

Ordi­nal The­o­ry describes how to seri­al­ize & track satoshis. These satoshis, when seri­al­ized, are called “ordi­nals”. We can asso­ciate chunks of data that we call “inscrip­tions” to these ordi­nals, thus cre­at­ing a form of NFT on Bit­coin. It’s a sim­ple con­cept, but the imple­men­ta­tion of the client that runs ordi­nals is quite com­plex. Ordi­nals began as a pas­sion project but explod­ed into pop­u­lar­i­ty in a mat­ter of a few weeks. Because of the rise in hype and com­plex­i­ty of the client, a lot of “bugs” in the client imple­men­ta­tion were dis­cov­ered. Due to the arcane nature of how the imple­men­ta­tion actu­al­ly works, a lot of these bugs & idio­syn­crasies became the sub­ject of mar­ket speculation.

The most notable of these idio­syn­crasies has arguably become a fea­ture, not a bug. On the OG Ordi­nals explor­er site, ordinals.com, Inscrip­tions were dis­played with a num­ber when­ev­er they were “inscribed”. These num­bers were a fun and easy way to track how many Inscrip­tions there were and imme­di­ate­ly became a focus for collectors.

A few weeks ago, the cre­ator of Ordi­nals pub­lished a blog post about how these Inscrip­tion num­bers have cre­at­ed unde­sir­able con­se­quences and how main­tain­ing these num­bers ham­strings fur­ther pro­to­col devel­op­ment. Recent­ly, I tweet­ed my opin­ion on the mat­ter and it kicked off the first major debate in Ordi­nals land.

Nar­row­ly, this is a dis­cus­sion over main­tain­ing or chang­ing the cur­rent num­ber­ing of Inscrip­tions. More broad­ly, this is one of the first real com­mu­ni­ty dis­cus­sions over how pro­to­col deci­sions are made. Broad­er still, this is a ques­tion of “what is the pro­to­col, how do we define an ‘Inscrip­tion’”.

💡 Impor­tant Clarifications

• Ordi­nal — a seri­al­ized satoshi
• Ordi­nal num­ber — the num­ber giv­en to an ordinal
• Inscrip­tion ID — the ID giv­en to an Inscrip­tion, derived from the trans­ac­tion it’s cre­at­ed in
• Inscrip­tion num­ber — the num­ber giv­en to an Inscrip­tion based upon its order of recog­ni­zance by the ord client ← this is what the debate is over
• This is a rapid­ly devel­op­ing top­ic. I don’t address the refac­tor inscrip­tion pars­ing or sequence num­ber­ing PRs in this piece.

How did we get here?

On Jan­u­ary 20, 2023, Casey Rodar­mor announced that his ord client was “ready for main­net”. Casey had been incu­bat­ing Ordi­nal The­o­ry for years and work­shop­ping the client with friends. Ord also enabled inscrib­ing, iden­ti­fy­ing, and read­ing Inscrip­tions. Casey & the gang would spend their time casu­al­ly cod­ing and dis­cussing Bit­coin here­sies such as “art on oth­er blockchains is actu­al­ly kind of cool”.

When Ordi­nals & Inscrip­tions went viral in ear­ly Feb­ru­ary, this once per­son­al project spawned an entire vibrant ecosys­tem overnight. As hype grew we saw the gen­e­sis of 2 nar­ra­tives: a tale of the Code and a tale of the Cul­ture. At times they are inter­linked but they could also be entire­ly dis­tinct, much like a lot of Bit­coin today.

The Code

The ord client exist­ed entire­ly on Casey’s per­son­al github repo through­out the past spring. Hun­dreds of issues piled up as the entire NFT user­base piled into a hand­ful of dis­cord servers. Casey’s code and Bit­coin itself were stress test­ed.

A cou­ple weeks into the fren­zy, it became clear that some inscrip­tions weren’t being rec­og­nized by ord. These inscrip­tions most­ly had to do with edge cas­es in either how Bit­coin works and how the ord client parsed through inscrip­tions. That led to some “missed inscrip­tions” that went into Bit­coin blocks but weren’t dis­played on the ordinals.com fron­tend, there­fore they didn’t receive an Inscrip­tion num­ber. It wasn’t very clear how many were miss­ing or what we even thought about those inscrip­tions… …were they actu­al­ly “inscrip­tions”? This top­ic was dis­cussed very lit­tle because there was a new kind of Bit­coin cul­ture form­ing, one that brought with it a cacoph­o­ny that drowned out much fur­ther tech­ni­cal dis­cus­sion. For the time being, most of the rules of the pro­to­col had to be intu­it­ed from how ord worked.

The Culture

The entire­ty of inter­est in Ordi­nals came from out­side Bit­coin — from NFT col­lec­tors & degen­er­ates alike. These are large­ly non­tech­ni­cal folks, but also high­ly moti­vat­ed to jump through what­ev­er hoops need­ed in order to buy a jpeg (sync­ing a full Bit­coin node, run­ning ord in com­mand line). These new­ly chris­tened bit­coin­ers imme­di­ate­ly began col­lect­ing, trad­ing and spec­u­lat­ing on the hot new dig­i­tal assets.

As Inscrip­tion activ­i­ty heat­ed up, ordinals.com quick­ly ticked towards Inscrip­tion #10,000. An icon­ic Twit­ter spaces bore wit­ness to cross­ing the his­toric num­ber — that same twit­ter spaces evolved into the de fac­to Schelling Point for Ordi­nals cul­ture & events: The Ordi­nals Show. Casey was inun­dat­ed with requests for inter­views while the lega­cy Bit­coin com­mu­ni­ty crit­i­cized & clutched their pearls at this new beast, slouch­ing towards Bit­coin. It was an incred­i­bly over­whelm­ing peri­od — the best of times and the cursed of times.

The top­ic of miss­ing inscrip­tions was brought up in a cou­ple con­fused github issues and dis­cord threads. In mid-Feb­ru­ary the sub­ject of these miss­ing inscrip­tions came up on a pod­cast Casey was on. He put the issue up for vote to the hosts who vot­ed to keep the Inscrip­tion num­ber­ing as-is, and then Casey tweet­ed this out:

The Curse

So what should we do about these miss­ing inscrip­tions? Some projects began inten­tion­al­ly pro­duc­ing these “miss­ing” inscrip­tions and cre­at­ed a sense of urgency to resolve the issue. In April, Casey put out PR #2307, coin­ing the term “Cursed” for these miss­ing inscrip­tions. The PR pro­posed giv­ing these cursed Inscrip­tions neg­a­tive num­bers, with the plan to at some unde­fined point in the future “bless” the inscrip­tions by rec­og­niz­ing them in the ord client. They would then receive num­bers when­ev­er they were recognized.

Div­ing a lit­tle deep­er, there are mul­ti­ple ways an Inscrip­tion can not be rec­og­nized & parsed by ord. Raph describes 4 types of Curses:

🪄The 4 Curs­es (so far)

• More than 1 inscrip­tion in a transaction
• ord only rec­og­nizes inscrip­tions in the first (reveal) input, so inscrip­tions in oth­er inputs are cursed
• If there are uneven tags (most pop­u­lar­ly OP_66, but can be any OP_evennumber) with­in an inscrip­tion enve­lope the client con­sid­ers the inscrip­tion unbound to a spe­cif­ic satoshi
• More than 1 inscrip­tion on a sat (now called “rein­scrip­tion)

While these are the 4 types of clear­ly iden­ti­fied curs­es, we do not know what oth­er curs­es may be dis­cov­ered in the future. Per­haps these 4 are all that will ever exist (I doubt it), but this is an unknown unknown. Each of these exist­ing & future curs­es would require com­mu­ni­ty coor­di­na­tion to “bless” and such coor­di­na­tion is hard, often con­tro­ver­sial. To com­mit to an unknown amount of future coor­di­na­tion events is gen­er­al­ly bad pro­to­col design espe­cial­ly when it could all be addressed today by not com­mit­ting to pre­serv­ing inscrip­tion #s.

It is worth not­ing that dur­ing the writ­ing of this arti­cle we have dis­cov­ered a new kind of cursed inscrip­tion, empha­siz­ing the point I make above.

Some of us at the time, myself includ­ed, tried to bring up our con­cerns with the approach to main­tain­ing Inscrip­tion num­ber­ing and the chal­lenges it could intro­duce to future devel­op­ment. Ordi­nal­ly, a key devel­op­er on the project, encour­aged con­sen­sus on Inscrip­tion ID and leave num­ber­ing to the market:

The Con­sen­sus

Con­sen­sus in Ordi­nals has pret­ty much respect­ed Casey’s hege­mo­ny & uni­lat­er­al deci­sion mak­ing. The per­son­al repo era, migra­tion to a github org, pro­mot­ing Raph to lead main­tain­er, the var­i­ous PRs & updates — all of these have been cel­e­brat­ed & embraced by most. Updates have been pushed with lit­tle com­mu­ni­ty input and scruti­ny but have large­ly been deemed desir­able. We even changed num­bers before with no com­mu­ni­ty push­back when an inscrip­tion was cre­at­ed but not asso­ci­at­ed with a sat (“unbound”) result­ing in an off-by-one error in inscrip­tion num­ber­ing. A major rea­son why there has been lit­tle com­mu­ni­ty input is because very few peo­ple actu­al­ly under­stand how the client works under the hood.

Today there are var­i­ous forks of ord which pow­er the ecosys­tem: mar­ket­places, wal­lets, aggre­ga­tors, etc. These forks are updat­ed with each iter­a­tion to the ref­er­ence client. Each client gen­er­al­ly seeks to main­tain par­i­ty with ord. We at Ordi­nal­Hub have opt­ed not to fork but instead rebuild the entire client in Golang and call it “gord”. Going through this devel­op­ment process has giv­en us an inti­mate under­stand­ing of how the ord client works and the chal­lenges in address­ing cur­rent & future edge cases.

The Com­mu­ni­ty how­ev­er is large­ly unaware of work on github and the tech­ni­cal state of index­ing. Very few users seem to under­stand how their Inscrip­tion gets iden­ti­fied & pre­sent­ed on a mar­ket­place or in their wal­let. Because of this, the Inscrip­tion num­ber is their iden­ti­ty because it is their pri­ma­ry ref­er­ence point to the asset & ecosystem.

The Case

To sum­ma­rize my case: I wish to con­vince the “Cul­tur­al Lay­er” that it is not worth it to the long term suc­cess of ordi­nals to design the pro­to­col around main­tain­ing inscrip­tion num­ber­ing. I rec­og­nize that these num­bers are spe­cial & cher­ished, but I think it’s more impor­tant to pri­or­i­tize the long term sus­tain­abil­i­ty of ordi­nals. If we con­tin­ue to try to pre­serve lega­cy num­ber­ing going for­wards it com­pli­cates pro­to­col devel­op­ment and reduces its like­li­hood of survival.

Casey recent­ly changed his mind about renum­ber­ing and laid out the rea­sons Cursed Inscrip­tions make devel­op­ment prob­lem­at­ic in his blog:

The log­ic required to iden­ti­fy & track these cursed inscrip­tion types requires cus­tom hard cod­ing of each type and lat­er reorder­ing them back into the series. The process of “bless­ing” the inscrip­tions cre­ates more sur­face area for com­mu­ni­ty debate & poten­tial gov­er­nance dis­agree­ments. It also requires more coor­di­na­tion among ord forks & index­ers, in many cas­es they would have to imple­ment their own cus­tom log­ic as well. From a tech­ni­cal stand­point, this would result in unin­tu­itive order­ing when there exists an extreme­ly intu­itive order­ing: Block Height & txin­dex with­in the block.

Since we do not know the future types of curs­es that may be dis­cov­ered, com­mit­ting to keep­ing the Inscrip­tion num­bers poten­tial­ly brings more sce­nar­ios where we have to cre­ate weird tech­ni­cal solu­tions & require social coor­di­na­tion to solve a prob­lem that does not have to exist.

Think­ing long term — my per­son­al opin­ion is that the pri­ma­ry use-case of Inscrip­tions will not be JPEGS & col­lectibles, but rather things that take advan­tage of Bitcoin’s data lay­er: rollups, state updates, data preser­va­tion & doc­u­men­ta­tion, etc. In such a case we should be design­ing the pro­to­col not for col­lectibles but for diverse func­tion­al­i­ty. Our descen­dants will look back on us and won­der what we were think­ing adding this unnec­es­sary com­plex­i­ty (and then they’ll just go back to Timechain sequencing).

All this said, I think there are very promis­ing com­pro­mis­es & mid­dle-ground solu­tions which reduce his­tor­i­cal num­ber­ing changes while pro­vid­ing a less-encum­bered way for­wards. I hope to sup­port some of these options as they develop.

The Collections

The most painful fric­tion is with col­lec­tors & col­lec­tions. The out­cry against renum­ber­ing has pro­duced “Love Letter[s] to Inscrip­tion num­bers”, polls, and 🧡s to num­ber­ing. Many times, those of us most con­cerned with tech­ni­cal imple­men­ta­tion dis­count the impor­tance of the cul­tur­al lay­er. The Sub1k twit­ter makes a strong appeal:

Ini­tial esti­ma­tion sug­gests renum­ber­ing would have min­i­mal change to ear­li­er inscrip­tion num­bers, but I don’t think that’s a very strong point as the out­cry is against any change. I do think there are ways to accom­mo­date for a change in num­ber­ing for many col­lec­tions, by hon­or­ing “lega­cy” num­ber­ing or by expand­ing the col­lec­tions (is it wrong to have ~100,092 in sub100k?). Sad­ly, there isn’t a solu­tion for hav­ing a spe­cif­ic num­ber like a birth­day or a lucky number.

I also love the num­bers and I want to keep num­ber­ing inscrip­tions. I just hope to con­vince you that going for­wards it is not worth it to the longevi­ty of the pro­to­col to com­mit to keep­ing num­bers sta­ble. As I men­tioned before, there are com­pro­mise pro­pos­als out there that pre­serve his­tor­i­cal num­ber­ing while reduc­ing empha­sis on sta­ble num­ber­ing going for­wards. I think those may be rea­son­able solutions.

Metaprotocols

One crit­i­cism about chang­ing Inscrip­tion num­ber­ing is its effect on metapro­to­cols uti­liz­ing inscrip­tion order­ing. Regard­less of my per­son­al crit­i­cisms on design or fea­si­bil­i­ty of these metapro­to­cols — should a nascent, pre‑1.0 pro­to­col like ord, make poor design deci­sions in order to pre­vent con­fu­sion for metapro­to­cols built on top of it? I emphat­i­cal­ly say no.

That said, I think there are an abun­dance of solu­tions these metapro­to­cols have at their dis­pos­al. In the case of BRC-20 the abil­i­ty to rebuild cur­rent token bal­ance state would be bro­ken — “cursed” BRC-20 deploy/mint/transfer func­tions would dis­tort entire token bal­ances. How­ev­er this can be addressed by coor­di­nat­ing block heights to update inscrip­tion recog­ni­zance to par­i­ty with ord, “freeze” with a ver­sion of ord, and/or “snap­shot” bal­ance state. Domo, the cre­ator of BRC-20, has pro­posed sim­i­lar ideas.

The same tech­niques could be uti­lized by all oth­er metapro­to­cols such as Bitmap, Sat­snames, etc. Some have pushed back on these ideas say­ing that “coor­di­na­tion is quite dif­fi­cult”. To that I say no shit, that is why we can’t com­mit to it at the base pro­to­col level.

Going forwards

This is real­ly a dis­cus­sion on pro­to­col def­i­n­i­tion and governance.

Com­par­a­tive­ly, this is the most care­ful & thought out pro­pos­al to ord since its ini­tial release in Jan­u­ary. This is the first blog post Casey has writ­ten in a year and the most pub­lic dis­cus­sion he has par­tic­i­pat­ed in since Feb­ru­ary. While it may seem that deci­sions are rapid & sweep­ing, this is by far the most we as a com­mu­ni­ty have dis­cussed any changes to the ord ref­er­ence implementation.

It’s an open source pro­to­col so the com­mu­ni­ty is free to fork from ord par­i­ty. You can choose not to update or imple­ment a client you dis­agree with. How­ev­er this is the absolute worst out­come and I would rather do noth­ing than have a sig­nif­i­cant com­mu­ni­ty fork and I doubt ord would make a deci­sion that cre­ates such a split.

There have been var­i­ous pro­pos­als for an Ordi­nals Improve­ment Process (”OIPS”). It’s clear the com­mu­ni­ty wants to dis­cuss gov­er­nance now and I wel­come this conversation.

As for def­i­n­i­tions & doc­u­men­ta­tion, my view is that we should have con­sen­sus around the fol­low­ing: core parts of Ordi­nal The­o­ry (sat orig­i­na­tion, track­ing, & inscrip­tion asso­ci­a­tion), inscrip­tion IDs, and valid ord enve­lope def­i­n­i­tion. From there we can dis­cuss how the pro­to­col might evolve and how the ref­er­ence client may be built. Per­son­al­ly, I believe that a “valid ord enve­lope” should be as per­mis­sive as possible.

Over­all, I think the com­mu­ni­ty has han­dled this pret­ty well. There have been some unnec­es­sary spats but it’s quite min­i­mal com­pared to the scorched earth at the height of the Block­size War. Ordi­nal The­o­ry is Casey’s love let­ter to Bit­coin. He & those close to the project have devot­ed a sig­nif­i­cant amount of their lives to this idea and we all wish to car­ry on in this hap­py shared delu­sion. I am con­fi­dent there are pro­duc­tive paths forward.

I would write way more on this, but this piece is already way over my word lim­it so I’ll see you on Twitter.

This is a guest post by Char­lie Spears. Opin­ions expressed are entire­ly their own and do not nec­es­sar­i­ly reflect those of BTC Inc or Bit­coin Magazine.

Source link

Please fol­low and like us: