Update chip to move it forward

• Updates language to be more formal in many places,
• added further clarification on risk and costs,
• included reference to repurposing by external actor if we do not enforce it.
• included historical information on usage,
• added a stakeholder section,
• added additional statements,
• updated the proposal details (unsure about quality, please review),
• set myself as co-owner (not sure if this is the right way, please review)

and probably a handful of more things I might've forgot.

CHIP-2021-01-Restrict Transaction Versions.md

@@ -2,44 +2,77 @@
 
 ## Summary
 
-This proposal forbids transactions to be mined if they lie about their version number.
+This proposal prevents transactions from being accepted and mined if they provide an invalid version number.
 
-> Title: Restrict Transaction Version
+> Title: Restrict Transaction Version  
 > Date: 2021-01  
 > Type: Consensus  
-> Status: Draft  
-> Version: 0.3  
-> Last edit: 2021-03-11  
-> Owner: Tom Zander  
+> Version: 0.9  
+> Last edit: 2022-01-13  
+> Owner: Tom Zander, Jonathan Silverblood  
 > History: https://gitlab.com/bitcoin.cash/chips  
+> Discussion: [bitcoincashresearch](https://bitcoincashresearch.org/t/173)
 
 ## Motivation and Benefits
 
-The transaction-version field in the transaction object has at this time no consensus rule on its correctness.
+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.
 
-The transaction version has mostly been kept unused and the version of an incoming transaction has not had much of an effect on selection of code-paths.
+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.
 
-Should in the future we decide to introduce a new transaction format, deciding how to parse in incoming transaction will best be done based on the transaction version. At such a time it then would be required to reject transactions that are advertising the wrong transaction number.
+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.
 
-To allow for less complex software during such a transition it will be highly beneficial to ensure correct transaction versioning earlier.
 
 ## Impact / Costs and Risks
 
-The new rule does not restrict transactions that currently comply with the standardness rules. As a result the only change would be in full nodes and specifically the block-validation technology.
+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.
+
+All other participants in the ecosystem are unaffected by this change.
+
+Failure to implement this update could result in external actors repurposing the version field for their own uses, making future upgrades more complex.
+
+### Developers
+
+Developers of software that validates blocks will need to implement a minor change to reject transactions and blocks containing invalid version numbers.
+
+### Node operators, etc.
+
+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:
+
+blockheight|hash|version
+|---|---|---|
+256818|637dd1a3418386a418ceeac7bb58633a904dbf127fa47bbea9cc8f86fef7413f|-2107285824
+256818|c659729a7fea5071361c2c1a68551ca2bf77679b27086cc415adeeb03852e369|-1703168784
+257644|35e79ee733fad376e76d16d1f10088273c2f4c2eaba1374a837378a88e530005|-2130706433
+311495|64147d3d27268778c9d27aa434e8f270f96b2be859658950accde95a2f0ce79d|0
+370002|110da331fd5336038316c4709404aea5855afed21f054f5bba01bfef099d5da1|3
+407042|6ae17e22dba03522126f9268de58de5a440ccdb334e137861f90766901e806fd|4
 
-The impact on the rest of the ecosystem is expected to be zero.
 
-This is a tightening of allowed transactions in a block and therefore can be a soft-fork. Author(s) recommend this to be scheduled for a future protocol upgrade.
+## Technical Specification
 
-## Proposal Description
+All transactions must begin with a 4 byte unsigned integer in little-endian version number corresponding to a consensus-enforced transaction format.
 
-Transactions choose their version based on capabilties and, in future, on how the transaction is structured. Transactions shall state in the version field the correct version for that choice. At the time of writing this CHIP that limits the allowed version numbers to 1 or 2.
+Transactions that reference a version number that is not enforced by consensus rules on the network should be rejected as invalid.
 
-Blocks that have transactions which violate this rule shall be deemed invalid.
+Blocks that include transactions that violate this rule shall also be rejected as invalid.
 
-# References:
+Currently there are only two such transaction formats, version 1 and 2, both of which already includes the transaction version fields in their formats.
 
-Discussion on [bitcoincashresearch](https://bitcoincashresearch.org/t/173)
+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.
+
+
+# Stakeholders
+
+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.
 
 ## Statements
 
@@ -47,15 +80,33 @@ Discussion on [bitcoincashresearch](https://bitcoincashresearch.org/t/173)
 > 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)
 
 **Freetrader, BCHN release manager.**  
-Quoting the supporting statement from BigBlockIfTrue:  
 > Likewise [source](https://bitcoincashresearch.org/t/173/10)
 
 **Andrew Stone, developer Bitcoin Unlimited**  
 > I support this change, so BU does so unless a BUIP is explicitly raised against it. ([source](https://bitcoincashresearch.org/t/173/11))
 
+**Calin Culianu, BCHN Developer**
+> 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.
+
+**Josh Green, Bitcoin Verde**
+> Haha, I support it.
+
+**Fernando Pelliccioni, BCHN developer, Knuth lead dev.**  
+> I support this change as a BCHN developer and Knuth lead dev. [source](https://bitcoincashresearch.org/t/173/31)
+
+
+### Additional support
+
+**Bitcoin Unlimited** have also voted for this change in [BUIP170](https://forum.bitcoinunlimited.info/t/buip170-implement-chip-2021-01-restrict-transaction-version/79).
+
+
 ## Copyright Notice
 
 Copyright (C)  2021 Tom Zander  
+Copyright (C)  2022 Jonathan Silverblood
 
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.3