Discussion on versioning and hardforks

[stringhandler]

Background

We have some changes coming up that potentially change the rules around simplicity. This issue is to discuss various options and caveats.

Problem

When new jets are added to simplicity, elements/liquid must be updated to execute them. This would produce a hard fork since older versions will explicitly fail on unknown jets.

Possible Solutions

1. No tapleaf changes, elements updated.

This is certainly the simplest, however it is a hard fork. Upgraded nodes will allow the transaction, older nodes will reject it.

2. Update tapleaf version

Currently the simplicity version is stored in the leaf as 0xbe. There are restrictions on valid versions, so potentially 0xc2 or 0xc4. I'm not sure that doing this will prevent a hardfork. New transactions using this leaf should be rejected on old nodes regardless. This would be a soft fork.

One downside though, is that if a new version is updated, the tapleaf_version() -> u8 jet will change it's result for some transactions. This is mostly fine, but a covenant that started on 0xbe would most likely be stuck on 0xbe. Mixing utxos with different versions may break contracts, although this is probably unlikely.

Are there other solutions? IMO it seems like we just need to hardfork (option 1). Perhaps there is a use case for changing the version byte in future? I would suggest that we reserve changing the version byte for cases where the simplicity program encoding changes.

[delta1]

I'm not sure that doing this will prevent a hardfork. New transactions using this leaf should be rejected on old nodes regardless.

New tapleaf versions are soft forks, they are consensus valid but "non-standard" - so they will be accepted in blocks but not relayed in the mempools of unupgraded nodes

[stringhandler]

As suggested by @Arvolear, we might want to add another byte for versioning somewhere so that we don't burn through tapleaf versions or overlap with another protocol that possibly emerges in future.

Maybe we can increase the tapleaf version once to 0xc2 (or 0xbc) and then change the encoding of the simplicity program in the witness to add a single byte versioning in front. This would change the data stored in the control block, and we'd need to change some Simplicity programs that calculate covenants. Perhaps we need a new Simplicity binary encoding that natively adds a node for the minimum supported simplicity version.