VINDICATION

[casey]

This PR adds a ❤️‍🔥 charm, named "vindicated". The intent is to demonstrate that, with only a small change to ord, we can support BRC-20 indexers that wish to update to a new version of ord at a later date, by letting them skip inscriptions with the vindicated charm until then.

This needs tests before being merged. We should also consider whether or not we want to make this charm visible to end users. Users may prefer not to have an additional charm on their inscriptions.

[raphjaph]

Why not call it blessed and then use 😇 or 💸 or ✨or 🕍 for the emoji?

[casey]

Why not call it blessed and then use 😇 or 💸 or ✨or 🕍 for the emoji?

I dunno, vindication is pretty lindy.

[DrJingLee]

💸

💸 looks cooool lol

[raphjaph]

I dunno, vindication is pretty lindy.

You can't beat the lindyness of a blessing

[arik-so]

I might be wrong, but I think the vindication charm might be getting applied too liberally.

I was just testing minimal op codes inside the content section (OP_9 in this case), and noticed that the vindication charm got applied to the transaction even though all the keys are byte pushes.

Here's the inscription: https://ordinals.com/inscription/c2678d8daa078bfe1b51595a04873a8631ebb5b51774ef8415a33adc743696e9i0

And here's the tx: https://mempool.space/tx/c2678d8daa078bfe1b51595a04873a8631ebb5b51774ef8415a33adc743696e9

I will test in regtest later whether using minimal opcodes just inside the content body used to result in a curse. I could have sworn that even the original ord version would have been able to recognize such an inscription.

EDIT: I think I am indeed wrong. Looks like the original implementation used

while !self.accept(&Instruction::Op(opcodes::all::OP_ENDIF))? {
    body.extend_from_slice(self.expect_push()?);
}

and expect_push() rejected op codes.

[casey]

Yup, that's correct, minimal op codes weren't accepted by the first version of ord (which lead to much confusion), and were cursed when supported.