Restrict transaction version numbers

There are many ideas under consideration about introducing new transaction formats. For keeping things clean it is best if the new transaction format can use a never-before-seen transaction version number. Since the transaction version number is the first four bytes of a transaction, this means that a transaction parser can trivially branch between ‘legacy format’ and ‘new format’ based on the first four bytes, without needing any context.

Currently there is only a policy-level rule that transactions shall be version 1 or 2. (OP_CSV and BIP68 are only active for tx version >2, hence why version 2 is allowed). However any transaction version is permitted by consensus.

Thus there is a problem: right now if we (say) propose that a new transaction format will use version=123456 (never used as of today), then a disruptive person can mine a block that includes examples of legacy transactions with version=123456, prior to the proper activation of the new format. Then, the new transaction format will be reusing a prior-seen transaction version, and this creates a technical nightmare for nodes and wallets that now cannot parse transactions without having context of which block those transactions have appeared in or will appear in. Context-free parsing is very valuable and worth keeping.

Hence, a proposal:

An upgrade shall be made that restricts transaction version numbers to be 1 or 2, at consensus layer.

Estimated negative impacts:

  • Miners: No harm, since miners generally use transaction version=1 for the coinbase. Unlike the block header version, there is no advantage / meaning assigned to the coinbase tx version.
  • Wallets/ecosystem: No harm for wallets which are already constrained by the version=1,2 rule when generating new transactions.
  • Full node development burden: This would be a routine upgrade with no weird side effects and can be easily included as a MTP-activated rule in ContextualCheckTransaction (or equivalent for other codebases).
  • Future development: This change is purely meant to simplify future development of hard forks, but at the same time it hampers the options available to future soft forks. If it is anticipated that BCH will ossify and convert to a soft-fork-only network like BTC, then the proposed version restriction should have a predetermined sunset date.
  • The actual introduction of a new tx format will require a great deal of work from all ecosystem players. Thus if the entire concept of a new tx format is opposed, then this version restriction may also be opposed as it increases the likelihood of a new tx format being introduced.

Sounds like a good idea.

I tested this idea when I worked on FlexTrans (it was a heavy handed alternative to SegWit) and realized that testnet3 was full of transactions that used random version numbers. This should not be an issue at all, just a good idea to make activation based on a time/and-or/height and activation only on BCH branches of testnets.

I doubt very many people oppose a new tx format per se, people just all have different ideas what the new format looks like.

On topic: An attacker might attempt to consume all the lower version numbers before activation, but I guess consuming all 4 billion possible versions is quite hard - so concept ack.

1 Like

Since you bring it up: it is relevant to point out that this kind of effort (and I know, I went through a lot of steps previously) is absolutely massive strain on the system where 100% of the infrastructure, wallets, etc all need to get the new code which is not trivial to test and such an effort can’t have a 3 months notice. More like an 18 month notice.

This is then a really good point: if you need to convince an entire ecosystem to upgrade all of their software, the bar lies really high for the requirements of this format. It really has to be worth the effort for everyone. Not just a minority that wants some non-money feature.

1 Like

Hey all, I agree that new transaction versions need a lot of time for review and implementation, so I’d like to get the conversation started on enabling contract-validated token systems for BCH. I think it’s possible without raising any current VM limits or requiring miners to track any new type of data: we just need the ability to create fixed-size inductive proofs and some way to read/manipulate the currently-incompatible integers in transaction serializations.

This change might also be a good time to begin restricting version numbers.

I’m proposing May 2022 as the deployment date. I’d appreciate any questions, comments, or feedback you have. Thanks!

A CHIP: 2021-01-Restrict Transaction