New inscriptions with unrecognized even tag will be bound after jubilee

[veryordinally]

The current implementation in inscription_updater.rs would cause new inscriptions made with unrecognized even tags bound after the jubilee:

let unbound = current_input_value == 0 || curse == Some(Curse::UnrecognizedEvenField);

This should probably be changed to not test for the curse, but test for the presence of an unrecognized even field.

[casey]

Damn, nice catch!

[lgalabru]

Why is this Curse::UnrecognizedEvenField a particular case?
I don't understand why this curse is being considering as unbound in a first place.
unbound was introduced for handling supertestnet transactions (inputs = outputs = 0), why mixing this states?

[casey]

Treating even fields as special has actually be planned from the beginning, although it wasn't well explained.

The idea is this: We might want to add fields that change the way that inscriptions are created or transferred. However, we want to avoid a situation where un-upgraded versions of ord and upgraded versions of ord disagree about the location or existence of inscriptions. Because, we don't want someone to be able to trick an old version of ord into thinking they have an inscription, when in fact they don't. So, to avoid this, we make inscriptions with unrecognized even fields see those inscriptions as unbound, or not having any location. Odd fields don't affect whether inscriptions exist or how they transfer, so unrecognized odd fields can be ignored by un-upgraded clients.