-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The jubilee #6
Comments
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. |
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 |
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. |
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? |
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 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. |
ordinals/ord#2495
What is the plan for the Jubilee upgrade?
Need to separate ord and brc20 in the backend?
The text was updated successfully, but these errors were encountered: