The Debate Around “Cursed” Ordinal Inscriptions

Please fol­low and like us:

After only four months since the pro­to­col was launched, ord has its first con­tentious debate about what are known as “cursed” inscriptions.

The sim­plest def­i­n­i­tion of a cursed inscrip­tion is any inscrip­tion that does not cur­rent­ly get indexed and iden­ti­fied by ord. This term came about as a catchall when some peo­ple incor­rect­ly used or pur­pose­ful­ly mis­used opcodes to cre­ate inscrip­tions that were not able to be indexed by ord and would there­fore be unrec­og­nized and not giv­en an inscrip­tion number. 

This issue was first men­tioned on April 25 in the ord github and the inter­im fix pro­posed by then lead devel­op­er Casey Rodar­mor was to, “Mod­i­fy ord to rec­og­nize the above cur­rent­ly invalid inscrip­tions, includ­ing retroac­tive­ly in old blocks, but con­sid­er these new inscrip­tions ‘cursed’ and assign them neg­a­tive inscrip­tion numbers.”

Fun­ni­ly enough, the exam­ple inscrip­tion code on the Ordi­nals docs web­site would have been a cursed inscription.

Link to embed­ded Tweet.

There are many ways cursed inscrip­tions can be cre­at­ed. Any inscrip­tion with mul­ti­ple inputs/outputs would be con­sid­ered cursed. As shown above, cer­tain mis­use of opcodes such as OP_1 can lead to cursed inscrip­tions. Alter­na­tive­ly, the intro­duc­tion of OP_66 using a val­ue of “cursed” inten­tion­al­ly made these types of inscrip­tions by hav­ing an even num­bered opcode which is not indexed by ord. Unless already defined in the spec, even num­bered opcodes are not rec­og­nized because they are reserved for future pro­to­col devel­op­ment. The full list of ways to cre­ate cursed inscrip­tions from issue #2045 is as follows:

• Mul­ti­ple inscrip­tions per trans­ac­tion, for effi­cient batching.
• Inscrip­tions on inputs after the first, which is use­ful for collections.
• Mul­ti­ple inscrip­tions on the same sat, so that the entire his­to­ry of a sat doesn’t need to be checked to deter­mine if a new inscrip­tion is valid.
• Inscrip­tions with unrec­og­nized even head­ers, so that new even head­ers don’t cause upgrad­ed clients to dis­agree about inscrip­tion numbers.

There are a cou­ple spe­cif­ic debates around cursed inscrip­tions. One of the dis­putes comes from the way that these inscrip­tions are cur­rent­ly num­bered. Cursed inscrip­tions are num­bered neg­a­tive­ly in the order of their cre­ation. Because of this num­ber­ing sys­tem and nam­ing con­ven­tion, some peo­ple pur­pose­ful­ly chose to cre­ate inscrip­tions and col­lec­tions that appear “cursed” whether by flip­ping the image of a pos­i­tive­ly num­bered inscrip­tion or using a more sin­is­ter image theme when inscrib­ing. The ques­tion is: Should these be append­ed to the index of pos­i­tive­ly num­bered inscrip­tions or should they keep their neg­a­tive inscrip­tion num­ber when the code is updated?

Addi­tion­al­ly, anoth­er con­tentious con­ver­sa­tion is what to do about the cer­tain type of cursed inscrip­tions that used the OP_66 opcode in their cre­ation. Because this opcode is not rec­og­nized by ord and even num­bered opcodes are inten­tion­al­ly left out for future devel­op­ment use, it is debat­able whether inscrip­tions using this opcode should be includ­ed in the cursed set or if they should be rejected.

At the present time, the issue around the even num­ber opcode is list­ed in the ord github. There are many com­ments in sup­port of includ­ing these inscrip­tions in the index, but the lead main­tain­ers of the pro­to­col seem to be against it. As of now, the cur­rent stance by the devel­op­ers is that these inscrip­tions would be unbound, mean­ing that they would not be assigned to a spe­cif­ic satoshi.

Remem­ber, ordi­nal the­o­ry works based on a first in, first out track­ing sys­tem for satoshis. Each inscrip­tion is assigned to the first satoshi in the gen­e­sis trans­ac­tion when the inscrip­tion is cre­at­ed. This type of lens for look­ing at bit­coin allows images, files, text, etc. to be tracked and trans­ferred. If a cursed inscrip­tion is unbound, it would not be asso­ci­at­ed with a spe­cif­ic satoshi and there­fore would be unable to be trans­ferred to anoth­er address. Many peo­ple who are inscrib­ing are hop­ing to be able to sell or trans­fer their inscrip­tion to anoth­er per­son. While the inscrip­tions using this opcode will live for­ev­er on the Bit­coin blockchain, if these inscrip­tions are clas­si­fied as unbound and unas­signed to a spe­cif­ic satoshi, users who mint­ed cursed inscrip­tions using this opcode would be unable to sell or trans­fer them.

Here­in lies one of the big­ger con­cerns for peo­ple who are spend­ing mon­ey on trans­ac­tion fees to cre­ate cursed inscrip­tions. If they are unable to sell them in the future, sig­nif­i­cant funds would have been wast­ed on fees. Many users have respond­ed to the github issue, express­ing sup­port for includ­ing these inscrip­tions, but the code’s main­tain­ers are not in favor of rec­og­niz­ing cursed inscrip­tions using the OP_66 even num­bered opcode.

On May 30, the new lead main­tain­er of ord, Raph­japh, wrote, “As the pro­to­col cur­rent­ly stands inscrip­tions are not valid if they use an unrec­og­nized even tag, so this change already makes a con­ces­sion by rec­og­niz­ing them. For now they are unbound but we might recon­sid­er this and bind them in the future if there are strong reasons.”

This response is not what many inscribers were hop­ing to hear. Sim­i­lar to Bit­coin, ord is open-source soft­ware so users can fork the code if they wish to rec­og­nize these spe­cif­ic types of cursed inscrip­tions. This con­tentious debate is ongo­ing and the path for­ward for ord remains to be seen. Users who spent sig­nif­i­cant sums on trans­ac­tion fees may be will­ing to switch to a new ver­sion of ord that will rec­og­nize their cursed inscrip­tions, but this is only a the­o­ret­i­cal path for­ward at this time.

Regard­less, Ordi­nals are a new tech­nol­o­gy being built on Bit­coin. Whether inscrip­tions are a flash in the pan or if they have last­ing pow­er may depend on how this issue gets resolved.

Source link

Please fol­low and like us: