The jubilee

[dubuqingfeng]

ordinals/ord#2495

What is the plan for the Jubilee upgrade?

Need to separate ord and brc20 in the backend?

[samedcildir]

Currently brc20 standard requires following the ord 0.9.0 and the only valid inscriptions are the ones that are not cursed on 0.9.0. That is why if you want to index both brc20 and the other inscriptions, it would be better to separate the indexers.

There are some problematic new inscription types on new versions of ord, for example the newly added delegate function may delay the reveal of content of an inscription which would not work well with brc20. That is why we need to discuss all of the new types and make sure it won't interfere with the protocol before deciding on an upgrade. Feel free to open the discussion on L1F forum.

Currently we run OPI for metaprotocol indexing and new version of ord for inscription indexing so we've separated the indexing.

[dubuqingfeng]

We have some process and technical complexity when implementing the separation of ordinals and BRC20 indexers, which is no less complex than the Jubilee upgrade. Therefore, I believe that consensus should be reached on indexers, including OKX, unisat, ME, and TRAC_btc parties such as BTC should adopt a unified version instead of causing forks. If they do not upgrade at present, there is no way to upgrade again in the future

[samedcildir]

Firstly I want to clarify something, this "fork" is a fork in git terminology. It has nothing to do with the "fork" in blockchain space since there will not be two separate chains, there will not be different ids, there will not be different orderings. The only difference will be in the numbers.

Secondly, there is not enough time to discuss the implications of jubilee. For example, after the jubilee, some inscription types will be unbound with positive number. Since these are unbound, they are untransferable so they should be discarded by brc20 protocol. There are other edge cases too (another example would be the new delegate function) and this decision should be made by carefully studying every inscription type.

Finally, even if we decide on a new version, it'll still be fixed in order to maintain consensus between indexers and ord will still add new types, functions etc. that brc20 should study and discuss before deciding that they are ok or they will be ignored. We cannot say that the latest version is always ok since indexers are updating their systems in different times.
So even if we say that we're going to do the jubilee, it'll not fix anything, brc-20 indexer will still use a different version than the full indexer. Also it is not a complex task to use different versions since the only difference will be in numbers and they can easily be transferred from the full indexers results.

[t4t5]

I'm confused. I thought the major BRC-20 players had agreed to stay on the 0.9.0 indexing rules for the time being, but it looks like Unisat recently indicated that they're going to honour the jubilee for their BRC-20 indexer? https://twitter.com/unisat_wallet/status/1742002796868808731

If this is the case, people's balances will quickly start to diverge on different platforms and there will be a ton of confusion and anger. What's the plan here?

[samedcildir]

We reached to a decision to move forward using version 0.14.0 ord with vindication flag enabled and vindicated inscriptions are treated as cursed. Also, delegation and content encoding features in 0.14.0 are ignored (as if these fields do not exist). This way we managed to get the exact same state as 0.9.0 using the ord that supports jubilee.

https://x.com/domodata/status/1742960147540922515

We've made two tests to verify the correctness of the new OPI version:

• We set the jubilee height to 0 and used the vindicated flag to catch the cursed inscriptions. The resulting state was exactly the same as 0.9.0 so it showed that the code will work the same after the jubilee.
• We set the jubilee height to normal height (824544) and run the full index with the new version of OPI. The resulting state was also exactly the same as 0.9.0 so it showed that the code works before the jubilee.

We will continue to run OPI v0.1 (with ord 0.9.0) in one of our backup servers and continue to check the validity of the new version.