BIP9 introduced a mechanism for doing parallel soft forking deployments based on repurposing the block nVersion field. Activation is dependent on near unanimous hashrate signalling which may be impractical and is also subject to veto by a small minority of non-signalling hashrate.
Due to using timestamps rather than block heights, it was found to be a risk that a sudden loss of siginificant hashrate could interfere with a late activation.
This specification provides a way to optionally guarantee lock-in at the end of the [[bip-0009.mediawiki|BIP9]] timeout, and therefore activation, while still allowing a hashrate super majority to trigger activation earlier.
# The '''name''' specifies a very brief description of the soft fork, reasonable for use as an identifier. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number.
# 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 '''start''' specifies the height of the first block at which the bit gains its meaning.
# The '''timeout''' specifies a block height at which the miner signalling ends. Once this height has been reached, if the soft fork has not yet locked in (excluding this block's bit state), the deployment is either considered failed on all descendants of the block, or, if '''lockinontimeout'' is true, transitions to the '''LOCKED_IN''' state.
# The '''lockinontimeout''' boolean if set to true, will transition state to '''LOCKED_IN''' at timeout if not already '''LOCKED_IN''' or '''ACTIVE'''.
===Selection guidelines===
The following guidelines are suggested for selecting these parameters for a soft fork:
# '''name''' should be selected such that no two softforks, concurrent or otherwise, ever use the same name.
# '''bit''' should be selected such that no two concurrent softforks use the same bit.
# '''start''' should be set to some block height in the future, approximately one month after a software release date including the soft fork. This allows for some release delays, while preventing triggers as a result of parties running pre-release software, and ensures a reasonable number of full nodes have upgraded prior to activation. It should be rounded up to the next height which begins a retarget period.
# '''timeout''' should be approximately 1 year after start, and on a block which begins a retarget period. Therefore, '''start''' plus 52416.
# '''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, or for one retarget period after the timeout when '''lockinontimeout''' is true.
# '''ACTIVE''' for all blocks after the LOCKED_IN retarget period.
The nVersion block header field is to be interpreted as a 32-bit little-endian integer (as present), and bits are selected within this integer as values (1 << N) where N is the bit number.
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.
Due to the constraints set by BIP 34, BIP 66 and BIP 65, we only have 0x7FFFFFFB possible nVersion values available.
This restricts us to at most 30 independent deployments. By restricting the top 3 bits to 001 we get 29 out of those
for the purposes of this proposal, and support two future upgrades for different mechanisms (top bits 010 and 011).
When a block nVersion does not have top bits 001, it is treated as if all
After a retarget period of LOCKED_IN, we automatically transition to ACTIVE.
case LOCKED_IN:
return ACTIVE;
And ACTIVE and FAILED are terminal states, which a deployment stays in once they're reached.
case ACTIVE:
return ACTIVE;
case FAILED:
return FAILED;
}
}
'''Implementation'''
It should be noted that the states are maintained along block chain
branches, but may need recomputation when a reorganization happens.
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 and safely 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).
===getblocktemplate changes===
BIP 8 is compatible with and reuses the GBT changes from BIP 9.
BIP8 and BIP9 deployments should not share concurrent active deployment bits. Nodes that only implement BIP9 will not activate a BIP8 soft fork if hashpower threshold is not reached by '''timeout''', however, those nodes will still accept the blocks generated by activated nodes.
