[Inscriptions off by one] Unbound inscription - false positive

[lgalabru]

It looks like the latest version of ord is introducing a regression, when handling unbound inscriptions:
https://ordinals.com/inscription/207322afdcca902cb36aeb674214dc5f80f9593f12c1de57830ad33adae46a0ai0
seems perfectly fine, and yet is being marked as unbound.
What went wrong there?

[lgalabru]

I meant, the transaction is not perfectly fine, but the resulting inscription should have been marked as cursed, not unbound.

[veryordinally]

May be a sat that has been reinscribed more than once.

[lgalabru]

A reinscription would lead to a cursed inscription, not an unbound inscription.

[veryordinally]

In ord 0.6.x so far reinscriptions are unbound and cursed. Unless the inscription in question would previously (0.5.x) not have been a reinscription - then it is not cursed. This was to address #2149

[gmart7t2]

This is the inscription that causes 0.5.x and 0.6.x to disagree on inscription numbers:

{
  "number": 12649108,
  "height": 794970,
  "timestamp": 1687130997,
  "inscription": "207322afdcca902cb36aeb674214dc5f80f9593f12c1de57830ad33adae46a0ai0",
  "location": "0000000000000000000000000000000000000000000000000000000000000000:0:906",
  "content_type": "text/plain;charset=utf-8"
}

0.5.x doesn't accept it and 0.6.x does.

[veryordinally]

Confirmed reinscription with logging code from https://github.com/veryordinally/ord/tree/issue-2202

Jun 20 21:56:25 ordinals-dev ord[1249]: [2023-06-20T19:56:25Z INFO  ord::index::
updater::inscription_updater] unbound inscription 207322afdcca902cb36aeb674214dc
5f80f9593f12c1de57830ad33adae46a0ai0 on offset 546 (true, 0, 4334)

[lgalabru]

The concept of unbound inscription was introduced to handle transactions where inputs = outputs = 0, I don't understand why this specific transactions would fall in the unbound bucket.
Wether it's a bug or a desired feature, 0.6 is breaking backward compatibility.
What is the path forward?

1. Is ord being fixed and ordinals.com reindexed, or
2. are community members asked to update their nodes and other indexers to imitate this bug?

[veryordinally]

So as suspected the issue is that this is caused by the code to address #2149 - this inscription is supposed to be recognized, but needs to be assigned a negative number.

[veryordinally]

The concept of unbound inscription was introduced to handle transactions where inputs = outputs = 0, I don't understand why this specific transactions would fall in the unbound bucket.

ord 0.6.0 recognizes reinscriptions (as cursed), but makes them unbound. Except for the special case #2149 where they are assigned a positive number. That logic triggers here wrongly, and causes the bug. I would say this is clearly a bug in ord, and we should fix it quickly, and reindex ordinals.com

Wether it's a bug or a desired feature, 0.6 is breaking backward compatibility. What is the path forward?

1. Is ord being fixed and ordinals.com reindexed, or
2. are community members asked to update their nodes and other indexers to imitate this bug?

I would strongly vote for 1. in this instance. @raphjaph thoughts?

[lgalabru]

Also note that the behavior implemented and observed is not what is being described in #2149.
The proposal in #2149 was to 1) index a re-inscription if the previous inscriptions were cursed and 2) ignore otherwise. 1) seems correctly implemented, but 2) is indexing re-inscriptions as unbound inscriptions.

[veryordinally]

Plan is for @raphjaph and me to work on a fix tomorrow morning, and make a new release, and rebuild the ordinals.com index from the affected inscription number 12,649,108 upwards.

[veryordinally]

Confirmed reinscription with logging code from https://github.com/veryordinally/ord/tree/issue-2202

Jun 20 21:56:25 ordinals-dev ord[1249]: [2023-06-20T19:56:25Z INFO  ord::index::
updater::inscription_updater] unbound inscription 207322afdcca902cb36aeb674214dc
5f80f9593f12c1de57830ad33adae46a0ai0 on offset 546 (true, 0, 4334)

Sat output is not quite right:

Jun 21 10:23:17 ordinals-dev ord[302607]: [2023-06-21T08:23:17Z INFO  ord::index::updater::inscription_updater] unbound inscription 207322afdcca902cb36aeb674214dc5f80f9593f12c1de57830ad33adae46a0ai0 on sat 655649449541807 at offset 546 in range (655649449541261, 655649449543261)

[veryordinally]

Results from indexing: 207322afdcca902cb36aeb674214dc5f80f9593f12c1de57830ad33adae46a0ai0 is a reinscription of sat 655649449543261 (previously inscribed with https://ordinals.com/inscription/cdb4a37b187e6342483756eee63e15e324295f0342eda5efa3feb48534e95815i0

[DrJingLee]

So if every re-inscribed inscription is unbounded and cursed .Every re-inscribe will cause a re-index right ?

Don't know if my understanding is correct

And Curious how this can be maintained more easily ...

Imagine someone re inscribe something everyday 🧿🧿🧿

[veryordinally]

So if every re-inscribed inscription is unbounded and cursed .Every re-inscribe will cause a re-index right ?

Don't know if my understanding is correct

And Curious how this can be maintained more easily ...

Imagine someone re inscribe something everyday 🧿🧿🧿

Sorry for cryptic updates - we're still in the midst of debugging, but I think I have it now. Will write up a detailed explanation here once confirmed. Reinscriptions will not cause re-indexes! We just had a really curious combination of edge cases here.

[DrJingLee]

So if every re-inscribed inscription is unbounded and cursed .Every re-inscribe will cause a re-index right ?

Don't know if my understanding is correct

And Curious how this can be maintained more easily ...

Imagine someone re inscribe something everyday 🧿🧿🧿

Sorry for cryptic updates - we're still in the midst of debugging, but I think I have it now. Will write up a detailed explanation here once confirmed. Reinscriptions will not cause re-indexes! We just had a really curious combination of edge cases here.

Wow realy love to learn more on the coming updates 🧿

[fiftyeightandeight]

I am seeing quite some divergences in inscription number among indexers:

13273849: https://bestinslot.xyz/ordinals/inscription/1372e603f06aaeb88bc3069fdf0a135647d79aa347156973b227511f69689731i0
13273850: https://ordinals.com/inscription/1372e603f06aaeb88bc3069fdf0a135647d79aa347156973b227511f69689731i0
13273199: https://ordinals.hiro.so/inscription/1372e603f06aaeb88bc3069fdf0a135647d79aa347156973b227511f69689731i0

Any chance this relates to the upgrade/fix?

[veryordinally]

Indexing comparison file at http://ordinals.tel:8181/inscription_number_to_id-0.6.3-rc.tsv.gz