The Jubilee

[casey]

Currently, inscriptions that would not have been recognized by the first version of ord are cursed, meaning that they are assigned negative inscription numbers.

In the future, we would like to make new inscriptions that would have been cursed blessed, and assign them positive inscription numbers.

Since this requires coordination, we should pick a future block height at which this will take place. This can be called "The Jubilee", after years in which debts and sins are forgiven.

Are we ready to do this? Are there any sources of cursed inscriptions that we may want to allow and bless?

What block height should we choose?

I think we are ready to do this. There are a few types unrecognized inscriptions, but I don't think they should be recognized:

• Inscriptions in P2WSH and P2SH scripts. Don't provide much utility, make implementation more complex.
• Inscriptions using minimal opcodes instead of data pushes. Make inscriptions slightly smaller, but make the implementation more complex.

As for block height, I think we should give a significant amount of time, perhaps two full difficulty adjustments, and do it on the first block of a difficulty adjustment, so at least 28 days of notice.

This python script calculates an activation height when current_height is set to the current block height:

import math

current_height = 810528
next_adjustment = math.ceil(current_height / 2016)
activation_adjustment = next_adjustment + 2
activation_height = activation_adjustment * 2016
print(activation_height)

[casey]

One thing we might want to do is only recognize inscriptions in P2TR outputs. Although we do use Witness::tapscript, this does not check if the witness is actually for a taproot output, so I think it could be confused in the case of P2WSH spends, although I haven't checked.

[cbspears]

Any specific reasoning or significance to the activation height?

[casey]

No particular significance. I removed the specific activation height in the above issue, since it was just the output of running that python script with what was the current height when the issue was created.

[cbspears]

For activation height, I would say before the end of the year. Probably before the holiday season end of December.

I would actually recommend waiting to propose a block height or date until after the Inscribe Amsterdam conference, as I believe that could be a formative social event and perhaps increase the likelihood of these conversations resulting in "Pareto Improvements"

[elocremarc]

Would we be able to bless prior cursed inscriptions? All current parent children inscribed with ord are cursed. It sort of is unfortunate having a released feature but are cursed. We can just give all prior cursed a positive number right before the activation.

[casey]

I agree it's unfortunate. We could bless prior cursed inscriptions by giving them positive inscription numbers after the the last positive inscription after the activation height. However, I'm not sure it's worth it.

[elocremarc]

However, I'm not sure it's worth it.

I would say that it could be. We released our markdown article with a parent author inscription that was cursed as a result other explorers that do not support cursed like ord.io have very hard discoverability and routing because the children are cursed. However that is not a big deal and we have held off on doing any more of the family tree until they are.

Also if we ever do a recursive endpoint off inscription number having a stable positive inscription number for prior cursed numbers to reference via recursion would be nice.

Your issue here #2539 would we not want to keep having cursed unstable numbers? What happens when we find even more cursed inscriptions at a later date and need to do jubilee 2? If the cursed remain unstable but eventually get a stable positive number they could have a path to roll into the inscription numbers and be used in recursion if that endpoint is added.

[lifofifoX]

If negative inscription numbers are staying, could the numbers be fixed and never change after the jubilee? That'd make them special and desirable. And if in the future, new category of inscriptions are found, they could be given a new terminology (doomed, hexed, jinxed, etc.) and numbering to solidfy the significance of The Jubilee.

[casey]

I'm hesitant to promise that negative inscription numbers will never change. If we promise that, then if we ever need to recognize new inscriptions which happen to be in sequence with old cursed inscription numbers, the code will be pretty heinous. However, it's very unlikely that cursed inscription numbers will change after the jubilee.

[lifofifoX]

if we ever need to recognize new inscriptions which happen to be in sequence with old cursed inscription numbers

That's why I proposed calling them something else and not cursed. Say we call these newly discovered inscriptions doomed, then the numbering would start from doomed #1, doomed #2 and so on, without affecting cursed #1, cursed #2 etc. It would, however, change the internal sequence numbers.

[casey]

What they're called doesn't really make it easier. It would still be a special case in the code.

[elocremarc]

For activation height, I would say before the end of the year. Probably before the holiday season end of December.

This needs to get resolved relatively quickly if we are not gonna bless prior cursed. Because we have released features like parent child and reinscriptions that are effectively unsupported. I would say this is probably the most important thing that needs to happen in this repo. Because pretty much everyone I talk to has not been able to inscribe anything because we are all waiting on parent child not being cursed. Either we patch parent child to not be cursed or we move ahead with a activation height close into the future during the next release.

[cbspears]

This needs to get resolved relatively quickly if we are not gonna bless prior cursed. Because we have released features like parent child and reinscriptions that are effectively unsupported. I would say this is probably the most important thing that needs to happen in this repo. Because pretty much everyone I talk to has not been able to inscribe anything because we are all waiting on parent child not being cursed. Either we patch parent child to not be cursed or we move ahead with a activation height close into the future during the next release.

Lately, I'm inclined to encourage delaying the jubilee longer. Recently @casey has said he would like to avoid having to do a second Jubilee if more edge cases are discovered.

But since this issue in just under a month we have discovered 2 more edge cases as well as discovered inscription ID incongruity. I also believe we have found yet another edge case that we're looking at making an issue for.

So far none of these edge cases, new curses, "ghost" or "missing" inscriptions have caused much debate but since the ord reference client has committed to keeping numbers stable by "eating glass" I think some of that glass consumption may be in the form of agonizingly long evaluation & discovery periods for otherwise simple proposals like a Jubilee.

[lifofifoX]

I'm hesitant to promise that negative inscription numbers will never change

This is a good point. I think it'd be great if the team can commit to not retroactively bless the cursed inscriptions though. Personally, I'd rather have sub 1M cursed inscriptions when there can be no more cursed inscriptions, over a positive number that's 36M+.

[casey]

I think with cursed inscriptions, there are no guarantees. I think it's highly unlikely that we would bless cursed inscriptions, but the entire point of cursed inscriptions was for them to be unstable, so I want to keep that flexibility, and not get myself into trouble again by promising stability 😅

[elocremarc]

So that means that this link is unstable then because if there is ever a -1 inscription found prior then it would no longer reference this inscription? Explains why ord io doesn't route cursed numbers and uses the Id. Was it a mistake as far as web2 links to make the endpoint work for cursed?
https://ordinals.com/inscription/-1

[lifofifoX]

not get myself into trouble again by promising stability

I was asking to commit to keeping them unstable 😅 But I hear you!

[raphjaph]

So that means that this link is unstable then because if there is ever a -1 inscription found prior then it would no longer reference this inscription? Explains why ord io doesn't route cursed numbers and uses the Id. Was it a mistake as far as web2 links to make the endpoint work for cursed? https://ordinals.com/inscription/-1

we've only committed to keeping postive inscription numbers stable. We'd prefer if everyone would use inscription id everywhere but this is what the market wanted. Negative ones will always be unstable, they're a chaotic catch-all.

[casey]

I'm personally comfortable with doing this now. We did add a couple more edge cases, but one of them, minimal op codes, was already known, and the incomplete field and duplicate field curses where a pretty straightforward result of the new inscription parser, and not long-lurking edge cases.

[casey]

I opened #2656 a proposed activation height of 820512. This is two full difficulty adjustments into the future. Signet and Testnet have their jubilees scheduled for one full difficulty adjustment in the future.

[cbspears]

I think this is too soon and we will almost certainly discover new edge cases after this. I think the best way to Jubilee is after 1.0 where we can test functionality for the non-cursed types for considerable time beforehand. I also think it would be prudent to have increased spec documentation prior to Jubilee.

[leonidasord]

I think no matter what there will probably always be edge cases that are found in the future but they won't be important and probably can just stay cursed. There is lots of functionality that people want that currently results in cursed inscriptions that the Jubilee will unlock. I'm in support of the Jubilee at 820512.

[cbspears]

There is lots of functionality that people want that currently results in cursed inscriptions that the Jubilee will unlock.

To clarify, we don't need to Jubilee in order to start uncursing inscriptions/recognizing them in ord. The Refactor inscription parsing (#2461) is an example of this, where those edge cases no longer result in cursed inscriptions. The Jubilee isn't about enabling functionality, it's about setting a precedent for protocol development & governance.

[casey]

We need the Jubilee in order to start uncursing those inscriptions, that's really the only thing that the Jubilee does. It would be nice to have better specs, but accurate specs are incredibly time consuming to create, and ultimately, the specs will always be non-normative. That is to say, if there is a bug in ord, it might be "fixed" by rewriting the specs to match the behavior of ord, if fixing the bug in ord would be disruptive.

[sanjfomojis]

Stoked for this to happen, but definitely agree we want to do everything we can beforehand to hopefully find any possible edge cases so we don’t need to deal with them in the future.

This might be a stupid idea, and we might not want to incentivise people trying to break ORD haha

But is it worth having some sort of bug bounty for people to try and find any possible edge cases before the jubilee?

I know most of them are accidentally found because it’s something we don’t predict, but there’s also a lot of people that don’t follow along because there’s no need so maybe a little incentive might get them thinking.

Again if it’s not a good idea then no stress at all, but thought i’d throw it out there just in case.

I’d be happy to chip in and I’m sure a lot of other project founders and just people in Ordinals in general would be happy to chip in with sats or inscriptions for the good of the protocol.

[dozer-eth]

Haven't been following too closely, but looks like the bound address is still wrong on this one? #2165

Maybe it's easy to fix issues like this post-jubilee (i.e. a wrong bound address vs recognizing entirely new classes of cursed inscriptions), but flagging just in case!

[DrJingLee]

The Jubilee is comming ~~
I strongly recommend the height of 820520 ,which 520 means i love you.
512 remind me the Wenchuan earthquake in 2008

[bolasblack]

Hi @casey , just want to confirm, I've seen these contents from your post:

There are a few types unrecognized inscriptions, but I don't think they should be recognized:

• Inscriptions in P2WSH and P2SH scripts. Don't provide much utility, make implementation more complex.
• Inscriptions using minimal opcodes instead of data pushes. Make inscriptions slightly smaller, but make the implementation more complex.

Does it mean that ordinals on P2WSH/P2SH addresses won't (or no longer supposed to) be recognized once the jubilee update is applied? (although I didn't find the related code updates on PR #2656, but still want to confirm)

[casey]

Correct, P2WSH and P2SH inscriptions were never recognized, and that isn't changing.

[bolasblack]

@casey thanks a lot! But currently a lot of indexers (UniSet, BestInSlot, etc...) support index inscriptions for P2WSH/P2SH addresses, is this behaviour not standard?

[casey]

This behavior is non-standard, and will not be supported by ord.

Can you provide links to P2WSH and P2SH inscriptions? I'm curious to check them out.

[bolasblack]

@casey Ah, sorry, my previous comment was incorrect, I was referring to P2WPKH and P2SH-P2WPKH address

I mean, will ord only support the taproot address? Or it will still support the P2WPKH and P2SH-P2WPKH addresses?

Sorry for the confusion

[casey]

No worries! All address types are supported for all operations except for inscription reveal transactions, which reveal the inscription contents in a taproot script-path spend, which is why they're taproot only.

[bolasblack]

@casey thanks a lot for the answer!