search

hirosystems / ordhook

Build indexers, standards and protocols on top of Ordinals and Inscriptions (BRC20, etc).
Apache License 2.0
190 stars 56 forks source link

cursed inscription numbers do not match ordinals.com #129

Closed rafaelcr closed 10 months ago

rafaelcr commented 1 year ago

when I view the Dimension ordinals, I see two things that are off. The cursed numbers do not match Ordinals.com. For example, if I look at this one, it is -54,314. But in the wallet, it's in the -73,000s range. Also, the inscription ID is incorrect. https://ordinals.com/inscription/5c4cd4e1409ad051ff7768f54d37bee2fd5d27f140fff4ffe458c732214a8d3bi0

The inscription ID ends with i0 not i1

rafaelcr commented 1 year ago

Addressing both points here for additional discussion:

The cursed numbers do not match Ordinals.com

Cursed inscriptions are by definition unstable and unpredictable, see this issue for the original discussion and specifically the phrase

Negative inscription numbers would always be perma-unstable

This is because new cursed inscription types may pop up in the future and indexers which start recognizing those will be forced to readjust the negative numbers to accomodate for old cursed + new cursed inscriptions.

Right now, ordhook recognizes more cursed inscriptions than ordinals.com which makes the Dimension ordinals get different numbers.

The inscription ID ends with i0 not i1

This is also a very similar problem (only with cursed inscriptions). The original definition of an inscription ID that says 

Inscription IDs are of the form TXIDiN, where TXID is the transaction ID of the reveal transaction, and N is the index of the inscription in the reveal transaction.

does NOT apply to cursed inscriptions. Why? Cursed inscriptions is all about future proof-ness.

Let’s consider the following transaction 0x0000…0001:

Let's say than in a few months, we’re realizing that there was a bug in the parser, or the author of that transaction was a visionary working on a curse that was not supported back then. We have to recognize input 2 as a cursed inscription, we’re doomed and we will have to mutate the inscription ids, to insert input 2 as the new 0x0000…0001i1. Also, consider the comment here for more context on the challenges of re-inscriptions.

We have brought up this issue for a couple of weeks now with the core ord team and as I mentioned before, a determination is still being made about how to mark inscription IDs for cursed inscriptions. For now, IDs should also be treated as unstable and subject to change.

roadbuilder commented 1 year ago

If there is a "visionary" that finds a new curse and it is only about 5 total inscriptions that are affected by this new curse, I think the visionary should just quit and do something else for a living; the initial cursed inscriptions totalled over 80,000 but this new set of curses added like 5, AND they screwed up the regular numbers as well (the un-cursed) at least those in 0.6.2 no longer match the regular numbers for 0.8.3 .. the first one I see this happening is https://ordinals.com/inscription/207322afdcca902cb36aeb674214dc5f80f9593f12c1de57830ad33adae46a0ai0 On version 0.6.2 this was #12649108 .. now it is cursed at #-55791 (negative) .. there are 4 more like this.

They should have just left the protocol as it was, if people's got screwed up, so be it, because having to keep updating code for people that couldn't follow the spec or at least verify how most people were inscribing, is costing everyone time and money. At the end of the day, the protocol is just all made up non-sense anyway.. just pick some non-sense and stick to it, don't have us make a career out of it.

lgalabru commented 10 months ago

Addressed in v2.0.0!