1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
<pre>
BIP: 9
Title: Version bits with timeout and delay
Author: Pieter Wuille <pieter.wuille@gmail.com>
Peter Todd <pete@petertodd.org>
Greg Maxwell <greg@xiph.org>
Rusty Russell <rusty@rustcorp.com.au>
Status: Draft
Type: Informational
Created: 2015-10-04
</pre>
==Abstract==
This document specifies a proposed change to the semantics of the 'version' field in Bitcoin blocks, allowing multiple backward-compatible changes (further called "soft forks") to be deployed in parallel. It relies on interpreting the version field as a bit vector, where each bit can be used to track an independent change. These are tallied each retarget period. Once the consensus change succeeds or times out, there is a "fallow" pause after which the bit can be reused for later changes.
==Motivation==
BIP 34 introduced a mechanism for doing soft-forking changes without a predefined flag timestamp (or flag block height), instead relying on measuring miner support indicated by a higher version number in block headers. As it relies on comparing version numbers as integers however, it only supports one single change being rolled out at once, requiring coordination between proposals, and does not allow for permanent rejection: as long as one soft fork is not fully rolled out, no future one can be scheduled.
In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule after its 95% threshold was reached, removing 2<sup>31</sup>+2 values from the set of valid version numbers (all negative numbers, as nVersion is interpreted as a signed integer, as well as 0 and 1). This indicates another downside this approach: every upgrade permanently restricts the set of allowed nVersion field values. This approach was later reused in BIP 66 and BIP 65, which further removed nVersions 2 and 3 as valid options. As will be shown further, this is unnecessary.
==Specification==
Each soft fork deployment is specified by the following per-chain parameters (further elaborated below):
# The '''bit''' determines which bit in the nVersion field of the block is to be used to signal the soft fork lock-in and activation. It is chosen from the set {0,1,2,...,28}.
# The '''threshold''' specifies how many blocks within a single retarget period (2016 blocks) must have the bit set before we lock in the deployment. The recommended value is 1916 (95%) for mainnet and 1512 (75%) for testnets.
# The '''starttime''' specifies a minimum median time past of a block at which the bit gains its meaning.
# The '''timeout''' specifies a time at which the deployment is considered failed. If the median time past of a block >= timeout and the soft fork has not yet locked in (including this block's bit state), the deployment is considered failed on all descendants of the block.
No two deployments may use the same bit if they have overlapping starttime-timeout periods.
The starttime should be set to some date in the future, coordinates with software release date. This is to prevent
triggers as a result of parties running pre-release software. The timeout should be set a reasonable time after the
starttime. Setting it to 3 years after the starttime would allow around 9 deployments to be initiated every year.
====States====
With each block and soft fork, we associate a deployment state. The possible states are:
# '''DEFINED''' is the first state that each soft fork starts out as. The genesis block is by definition in this state for each deployment.
# '''STARTED''' for blocks past the starttime.
# '''LOCKED_IN''' for one retarget period after the first retarget period with STARTED blocks of which at least threshold have the associated bit set in nVersion.
# '''ACTIVE''' for all blocks after the LOCKED_IN retarget period.
# '''FAILED''' for one retarget period past the timeout time, if LOCKED_IN was not reached.
# '''ABANDONED''' for all blocks after the FAILED retarget period.
====Bit flags====
Blocks in the STARTED state get an nVersion whose bit position bit is set to 1. The top 3 bits of such blocks must be
001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive. This leaves two future
upgrades for different mechanisms (top bits 010 and 011), while complying to the constraints set by BIP 34 and others.
Having more than 29 available bits for parallel soft forks does not add anything anyway, as the (nVersion >= 3)
requirement already makes that impossible. When a block nVersion does not have top bits 001, it is treated as if all
bits are 0 for the purposes of deployments in the context of this BIP. Miners should continue setting the bit in
LOCKED_IN phase, so uptake is visible
====New consensus rules====
The new consensus rules for each soft fork are enforced for each block that has ACTIVE state.
====State transitions====
<img src="bip-0009/states.png" align="middle"></img>
The genesis block has state DEFINED for each deployment, by definition.
State GetStateForBlock(block) {
if (block.height == 0) {
return DEFINED;
}
All blocks within a retarget period have the same state. This means that if
floor(block1.height / 2016) = floor(block2.height / 2016), they are guaranteed to have the same state for every
deployment.
if ((block.height % 2016) != 0) {
return GetStateForBlock(GetParent(block));
}
Otherwise, the next state depends on the previous state:
switch (GetStateForBlock(GetAncestorAtHeight(block, block.height - 2016))) {
We remain in the initial state until either we pass the start time or the timeout. GetMedianTimePast in the code below
refers to the median nTime of the 11 blocks preceeding a given block.
case DEFINED:
if (GetMedianTimePast(block) >= timeout) {
return FAILED;
}
if (GetMedianTimePast(block) >= starttime) {
return STARTED;
}
return DEFINED;
When in STARTED state, we tally the bits set, and can transition to LOCKED_IN if we pass the threshold. Alternatively,
the timeout can trigger. Note that a block's state never depends on its own nVersion; only on that of its ancestors.
case STARTED: {
int count = 0;
walk = block;
for (i = 0; i < 2016; i++) {
walk = walk.parent;
if (walk.nVersion & 0xE0000000 == 0x2000000 && (walk.nVersion >> bit) & 1 == 1) {
count++;
}
}
if (count >= threshold) {
return LOCKED_IN;
}
if (GetMedianTimePast(block) >= timeout) {
return FAILED;
}
}
After a retarget period of LOCKED_IN or FAILED, we automatically transition to ACTIVE and ABANDONED, respectively.
case LOCKED_IN:
return ACTIVE;
case FAILED:
return ABANDONED;
And ACTIVE and ABANDONED are terminal states, which a deployment stays in once they're reached.
case ACTIVE:
return ACTIVE;
case ABANDONED:
return ABANDONED;
}
}
'''Forks'''
It should be noted that the states are maintained along block chain
branches, but may need recomputation when a reorganization happens.
'''Implementation'''
Given that the state for a specific block/deployment combination is completely determined by its ancestry before the
current retarget period (i.e. up to and including its ancestor with height block.height - 1 - (block.height % 2016)),
it is possible to implement the mechanism above efficiently by caching the resulting state of every multiple-of-2016
block, indexed by its parent.
====Warning mechanism====
To support upgrade warnings, an extra "unknown upgrade" is tracked, using the "implicit bit" mask = (block.nVersion & ~expectedVersion) != 0. Mask will be non-zero whenever an unexpected bit is set in nVersion. Whenever LOCKED_IN for the unknown upgrade is detected, the software should warn loudly about the upcoming soft fork. It should warn even more loudly after the next retarget period (when the unknown upgrade is in the ACTIVE state).
==Support for future changes==
The mechanism described above is very generic, and variations are possible for future soft forks. Here are some ideas that can be taken into account.
'''Modified thresholds'''
The 95% threshold (based on in BIP 34) does not have to be maintained for eternity, but changes should take the effect on the warning system into account. In particular, having a lock-in threshold that is incompatible with the one used for the warning system may have long-term effects, as the warning system cannot rely on a permanently detectable condition anymore.
'''Conflicting soft forks'''
At some point, two mutually exclusive soft forks may be proposed. The naive way to deal with this is to never create software that implements both, but that is making a bet that at least one side is guaranteed to lose. Better would be to encode "soft fork X cannot be locked-in" as consensus rule for the conflicting soft fork - allowing software that supports both, but can never trigger conflicting changes.
'''Multi-stage soft forks'''
Soft forks right now are typically treated as booleans: they go from an inactive to an active state in blocks. Perhaps at some point there is demand for a change that has a larger number of stages, with additional validation rules that get enabled one by one. The above mechanism can be adapted to support this, by interpreting a combination of bits as an integer, rather than as isolated bits. The warning system is compatible with this, as (nVersion & ~nExpectedVersion) will always be non-zero for increasing integers.
== Rationale ==
The failure timeout allows eventual reuse of bits even if a soft fork was
never activated, so it's clear that the new use of the bit refers to a
new BIP. It's deliberately very course grained, to take into account
reasonable development and deployment delays. There are unlikely to be
enough failed proposals to cause a bit shortage.
The fallow period at the conclusion of a soft fork attempt allows some
detection of buggy clients, and allows time for warnings and software
upgrades for successful soft forks.
==Copyright==
This document is placed in the public domain.
|
