Currently, the transaction version field is not enforced as a consensus rule and current full node software does not make a distinction in how transactions are parsed based on the transaction version field.
If in the future we would introduce a new transaction format it would make sense to use the version field for its intended purpose, and use it to determine how to parse transactions.
However, if we do not enforce valid transaction version numbers it would be possible for external actors to repurpose the field for their own usage and a future upgrade to reject invalid version numbers would then break existing usage.
By enforcing valid transaction versions now we can prevent this situation, and reduce complexity for future upgrades to transaction versions.
The overall risks and costs of this proposal are very small, as the change only impact developers who write block validation code and users (mostly node operators) who run such code.
Failure to implement this update could result in external actors repurposing the version field for their own uses, making future upgrades more complex.
Developers of software that validates blocks will need to implement a minor change to reject transactions and blocks containing invalid version numbers.
Users who run block validation software need to update to a supporting version in a timely manner, or they could find themselves out of consensus with the network.
*Note: Since this proposal is intended to activate at future upgrade point, this cost is considered negliable and is shared with all other proposals being activated in the same upgrade.*
### Historical usage
After inspecting the current blockchain we can conclude that in total there has only been six (6) transactions that have presented an invalid version number, the most recent one dating back to 2016:
All transactions must begin with a 4 byte unsigned integer in little-endian version number corresponding to a consensus-enforced transaction format.
Transactions that reference a version number that is not enforced by consensus rules on the network shall be rejected as invalid.
Blocks that include transactions that violate this rule shall also be rejected as invalid.
At the time of writing this CHIP the only valid version numbers are `1` AND `2`, and is already enforced by standardness rules.
Future improvements may introduce new transaction formats with their own unique identifiers, and at such time that they are enforced by consensus they would become valid according to this proposal.
Since standardness policies already require that transaction versions must be either 1 or 2, and on-chain analysis indicates that there are no users of non-valid transaction versions since 2016 the only clearly identifiable stakeholders are miners and developers of transaction and block validating software.
> Reviewed, looks good to me. Recommend activation of this CHIP in the first network upgrade after May 2021. [source](https://bitcoincashresearch.org/t/173/7)
> I strongly support this as a new consensus rule moving forward for any future upgrade [source](https://bitcoincashresearch.org/t/restrict-transaction-version-numbers/173/30)
**bitcoincashautist, contributor**
> This proposal has value in that it would enable context-free transaction parsing, and would come at no cost to anyone. Finally we could use the transaction version field to actually track transaction versions and map them to Bitcoin Cash upgrades.
**Bitcoin Unlimited** have also voted for this change in [BUIP170](https://forum.bitcoinunlimited.info/t/buip170-implement-chip-2021-01-restrict-transaction-version/79).
