Add version number to inscriptions

[casey]

This would be a relatively simple way to do upgrades. Not sure if a good idea though.

[rot13maxi]

I don't think I've ever regretted having a version number.

I think having a version number is an important mechanism for iterating without breaking existing inscriptions (#963)

[casey]

I think I agree. I was hoping to avoid having explicit version numbers, but I think it's a good idea. I would feel a lot better about going to mainnet if we had a really good plan for making future upgrades as smooth as possible.

Here's what I'm thinking:

Introduce an "it's okay to be odd" rule in the inscription parser. This is borrowed from Lightning. If a client sees a tag that it doesn't understand that's odd, it ignores that tag but processes the rest of the inscription. If it sees an even tag it doesn't understand, it refuses to parse the inscription entirely and returns an error

This allows us to introduce odd tags that old clients can ignore, for example a license field, and tags that clients can't ignore, like a tag that changes how the inscription is assigned to the outputs of the inscribe transaction, or changes how the inscription transfers.

Then, later, we introduce a version field with an even tag. Old clients will see an even tag that they don't understand and ignore inscriptions with a version field.

New clients will parse the version field, and then, if the value of the version field is higher than the version they understand, they will ignore the inscription entirely.

This would avoid breaking existing signet and mainnet inscriptions, and give us a few different upgrade paths:

1. Individual features that can be ignored (odd tag)
2. Individual features that cannot be ignored (even tag)
3. Drastic changes that make it impossible for old clients to understand the inscription (version bump)

What do you think?

[rot13maxi]

I like it