ordinally

> Hey @raphjaph, @veryordinally! I just saw that `v0.6.0` was released, pretty shortly after merging #2145, which a big PR where many things could have been broken. What is the...

> @lgalabru I agree... this seems like it was rushed while the devs continue to hide from the fact that users are upset about the lack of discourse on #2109......

> @veryordinally I'm not referring to re-inscribing cursed sats, I'm referring to the patch that @casey implemented for fixing the supertestnet issue. I think this patch is incorrect and breaking...

We encountered this issue when implementing #2145 - this is a tracking issue to document the solution we implemented to maintain backwards compatibility.

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

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...

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) ```

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...

> 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....

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.