Cursed inscription edge case - single inscription not on input 0

[dozer-eth]

Copying this question from #2145 (comment) to get clarity:

I think there is an edge case not covered:

if there is just one inscription in a tx but not in input 0, it is cursed but treated like a "collection" and the new satpoint calculations are applied, which leads them to be unbound under certain circumstances. Imho they should generally get offset = 0 and be bound.

You can cross-test this with ord 0.5.1, modify it to inscribe for example from input index 1. It will treat it as it should, while ord 0.6.0 completely differs.

Example:
https://ordinals.com/inscription/ae33ed51d17c45e5de2ef8c7ce130f5860c69079ab4d2f51b6634537ba9db5f8i0
https://mempool.space/tx/ae33ed51d17c45e5de2ef8c7ce130f5860c69079ab4d2f51b6634537ba9db5f8

This inscription should be bound to bc1pkuksl7kwvcsv065w75fupjwhsnpuy9xamhcj0jgymjduug58fh3q7q4weq, but the explorer UI says it is bound to bc1qxhmdufsvnuaaaer4ynz88fspdsxq2h9e9cetdj (not sure where that address is coming from?)

[casey]

It looks like this inscription is now at address 3H7FrRN6TCfUEbWgL2xdLsMLuCuj3JwDGW. Can you confirm whether or not that's correct, and if not, what the correct location should be and why?

[dozer-eth]

I haven't moved that inscription (and haven't touched the wallet since inscribing, so afaik it wasn't accidentally spent on fees or anything), so I expect it to still be bound to bc1pkuksl7kwvcsv065w75fupjwhsnpuy9xamhcj0jgymjduug58fh3q7q4weq (the output of the initial inscription txn).

[casey]

I finally got to the bottom of this! Sorry it took so long.

The envelope for this inscription is on the 2nd input. Versions of ord before 0.6.0 didn't parse the 2nd input or later, so in ord 0.5.2, this inscription didn't exist. In version 0.6.0, this inscription is recognized, but because it's in the 2nd input, it is assigned to the first sat of the input on which it is made, which is the 11246th sat in the output. (Because the 1st input has value 11246 sats.) This sat went to fees, which is why it isn't showing up on the output.

How was this inscription made? Afaik, in ord 0.5.2 and earlier, this wouldn't have been possible with vanilla ord.

[dozer-eth]

Ah, thanks so much for looking into that!!

The inscription was created using a fork/tool made by https://github.com/BennyTheDev. I haven't seen the source, he might be able to elaborate on the impl. But this is what he said initially (at the time i think the address was unbound?):

I think there is an edge case not covered:

if there is just one inscription in a tx but not in input 0, it is cursed but treated like a "collection" and the new satpoint calculations are applied, which leads them to be unbound under certain circumstances. Imho they should generally get offset = 0 and be bound.

You can cross-test this with ord 0.5.1, modify it to inscribe for example from input index 1. It will treat it as it should, while ord 0.6.0 completely differs.

[BennyTheDev]

I was basically screwing up the inputs in terms of postage that night. Was quite intense, because there were services trying to grab like 200 usd per cursed mint from people and I was asked to come up with something cheaper. 1000s of people literally.

However, intention has been to emulate inscriptions on input index 1 instead of OP_66. I fixed that later, but your find is basically the result of that event. Not sure if you want to include those or not, but that's the background.

ord 0.5.1 had them cursed and bound I believe, but not 100% sure, has been a while since then.

I finally got to the bottom of this! Sorry it took so long.

The envelope for this inscription is on the 2nd input. Versions of ord before 0.6.0 didn't parse the 2nd input or later, so in ord 0.5.2, this inscription didn't exist. In version 0.6.0, this inscription is recognized, but because it's in the 2nd input, it is assigned to the first sat of the input on which it is made, which is the 11246th sat in the output. (Because the 1st input has value 11246 sats.) This sat went to fees, which is why it isn't showing up on the output.

How was this inscription made? Afaik, in ord 0.5.2 and earlier, this wouldn't have been possible with vanilla ord.

[casey]

I just checked, and it looks like 0.5.1 also doesn't recognize them. I think this makes sense, since 0.6.0 was the first to recognize inscriptions on multiple inputs.

[BennyTheDev]

ah, now I remember: I actually hacked the ord wallet to recognize 2nd inputs, but it would have those bound. That's what 0.6.0 wouldn't do.

I just checked, and it looks like 0.5.1 also doesn't recognize them. I think this makes sense, since 0.6.0 was the first to recognize inscriptions on multiple inputs.

[dozer-eth]

Thanks for clarifying. So the inscriptions created this way are basically all owned by miners now?

[casey]

Yah, unfortunately. It looks like they're all sitting in a giant utxo with a ton of inscriptions.