CHIP-2021-01-Restrict Transaction Versions.md 5.81 KB
Newer Older
Tom Zander's avatar
Tom Zander committed
1
# CHIP 2021-01 Restrict Transaction Version
Tom Zander's avatar
Tom Zander committed
2

Tom Zander's avatar
Tom Zander committed
3
## Summary
Tom Zander's avatar
Tom Zander committed
4

5
This proposal prevents transactions from being accepted and mined if they provide an invalid version number.
Tom Zander's avatar
Tom Zander committed
6

7
> Title: Restrict Transaction Version  
Tom Zander's avatar
Tom Zander committed
8
9
> Date: 2021-01  
> Type: Consensus  
10
11
12
> Version: 0.9  
> Last edit: 2022-01-14  
> Owner: Tom Zander, Jonathan Silverblood  
Tom Zander's avatar
Tom Zander committed
13
> History: https://gitlab.com/bitcoin.cash/chips  
14
> Discussion: [bitcoincashresearch](https://bitcoincashresearch.org/t/173)
Tom Zander's avatar
Tom Zander committed
15
16

## Motivation and Benefits
Tom Zander's avatar
Tom Zander committed
17

18
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.
Tom Zander's avatar
Tom Zander committed
19

20
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.
Tom Zander's avatar
Tom Zander committed
21

22
23
24
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.
Tom Zander's avatar
Tom Zander committed
25
26


Tom Zander's avatar
Tom Zander committed
27
## Impact / Costs and Risks
Tom Zander's avatar
Tom Zander committed
28

29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
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:
Tom Zander's avatar
Tom Zander committed
49

50
51
52
53
54
55
56
57
blockheight|hash|version
|---|---|---|
256818|637dd1a3418386a418ceeac7bb58633a904dbf127fa47bbea9cc8f86fef7413f|-2107285824
256818|c659729a7fea5071361c2c1a68551ca2bf77679b27086cc415adeeb03852e369|-1703168784
257644|35e79ee733fad376e76d16d1f10088273c2f4c2eaba1374a837378a88e530005|-2130706433
311495|64147d3d27268778c9d27aa434e8f270f96b2be859658950accde95a2f0ce79d|0
370002|110da331fd5336038316c4709404aea5855afed21f054f5bba01bfef099d5da1|3
407042|6ae17e22dba03522126f9268de58de5a440ccdb334e137861f90766901e806fd|4
Tom Zander's avatar
Tom Zander committed
58
59


60
## Technical Specification
Tom Zander's avatar
Tom Zander committed
61

62
All transactions must begin with a 4 byte unsigned integer in little-endian version number corresponding to a consensus-enforced transaction format.
Tom Zander's avatar
Tom Zander committed
63

64
Transactions that reference a version number that is not enforced by consensus rules on the network shall be rejected as invalid.
Tom Zander's avatar
Tom Zander committed
65

66
Blocks that include transactions that violate this rule shall also be rejected as invalid.
Tom Zander's avatar
Tom Zander committed
67

68
69
70
71
72
73
74
75
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.


# 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.
Tom Zander's avatar
Tom Zander committed
76

Tom Zander's avatar
Tom Zander committed
77
78
## Statements

Tom Zander's avatar
Tom Zander committed
79
**BigBlockIfTrue, BCHN developer.**  
Tom Zander's avatar
Tom Zander committed
80
> 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)
Tom Zander's avatar
Tom Zander committed
81

Tom Zander's avatar
Tom Zander committed
82
**Freetrader, BCHN release manager.**  
Tom Zander's avatar
Tom Zander committed
83
> Likewise [source](https://bitcoincashresearch.org/t/173/10)
Tom Zander's avatar
Tom Zander committed
84

Tom Zander's avatar
Tom Zander committed
85
**Andrew Stone, developer Bitcoin Unlimited**  
Tom Zander's avatar
Tom Zander committed
86
> I support this change, so BU does so unless a BUIP is explicitly raised against it. ([source](https://bitcoincashresearch.org/t/173/11))
Tom Zander's avatar
Tom Zander committed
87

Fernando Pelliccioni's avatar
Fernando Pelliccioni committed
88
89
90
**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)

91
92
93
94
95
96
97
**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**
98
> We support restricting the transaction version field so that the consensus rules are consistent with current network rules.
99
100
101
102
103
104
105


### 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).


Tom Zander's avatar
Tom Zander committed
106
## Copyright Notice
Tom Zander's avatar
Tom Zander committed
107
108

Copyright (C)  2021 Tom Zander  
109
Copyright (C)  2022 Jonathan Silverblood
Tom Zander's avatar
Tom Zander committed
110
111
112
113
114
115

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.