diff options
Diffstat (limited to 'bip-0008.mediawiki')
| -rw-r--r-- | bip-0008.mediawiki | 78 |
1 files changed, 58 insertions, 20 deletions
diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki index 26e8572..a9299f7 100644 --- a/bip-0008.mediawiki +++ b/bip-0008.mediawiki @@ -1,11 +1,11 @@ <pre> BIP: 8 - Title: Version bits 2017 + Title: Version bits with lock-in by height Author: Shaolin Fry <shaolinfry@protonmail.ch> Luke Dashjr <luke+bip@dashjr.org> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0008 - Status: Draft + Status: Rejected Type: Informational Created: 2017-02-01 License: BSD-3-Clause @@ -18,23 +18,27 @@ This document specifies an alternative to [[bip-0009.mediawiki|BIP9]] that corre Block heights are used for start and timeout rather than POSIX timestamps. It additionally introduces an additional activation parameter to guarantee activation of backward-compatible changes (further called "soft forks"). +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. + ==Motivation== -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. +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 result in veto by a small minority of non-signalling hashrate. Super majority hashrate based activation triggers allow for accelerated activation where the majority hash power enforces the new rules in lieu of full nodes upgrading. Since all consensus rules are ultimately enforced by full nodes, eventually any new soft fork will be enforced by the economy. This proposal combines these two aspects to provide eventual flag day activation after a reasonable time (recommended a year), as well as for accelerated activation by majority of hash rate before the flag date. 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. +Block time is somewhat unreliable and may be intentionally or unintentionally inaccurate, so thresholds based on block time are not ideal. Secondly, BIP9 specified triggers based on the first retarget after a given time, which is non-intuitive. Since each new block must increase the height by one, thresholds based on block height are much more reliable and intuitive and can be calculated exactly for difficulty retarget. ==Specification== +===Parameters=== + Each soft fork deployment is specified by the following per-chain parameters (further elaborated below): # 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 (but see the exception during '''FAILING''' state), 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'''. +# The '''startheight''' specifies the height of the first block at which the bit gains its meaning. +# The '''timeoutheight''' 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 (but see the exception during '''FAILING''' state), 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 timeoutheight if not already '''LOCKED_IN''' or '''ACTIVE'''. ===Selection guidelines=== @@ -42,19 +46,19 @@ The following guidelines are suggested for selecting these parameters for a soft # '''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. +# '''startheight''' should be set to some block height in the future, approximately 30 days (or 4320 blocks) 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 for simplicity. +# '''timeoutheight''' should be 1 year, or 52416 blocks (26 retarget intervals) after '''startheight'''. # '''lockinontimeout''' should be set to true for any softfork that is expected or found to have political opposition from a non-negligable percent of miners. (It can be set after the initial deployment, but cannot be cleared once set.) -A later deployment using the same bit is possible as long as the start is after the previous one's -timeout or activation, but it is discouraged until necessary, and even then recommended to have a pause in between to detect buggy software. +A later deployment using the same bit is possible as long as the startheight is after the previous one's +timeoutheight or activation, but it is discouraged until necessary, and even then recommended to have a pause in between to detect buggy software. ===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 at or beyond the start height. +# '''STARTED''' for blocks at or beyond the startheight. # '''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. # '''FAILING''' for one retarget period after the timeout, if LOCKED_IN was not reached and '''lockinontimeout''' is false. @@ -85,6 +89,8 @@ The new consensus rules for each soft fork are enforced for each block that has <img src="bip-0008/states.png" align="middle"></img> +During the STARTED state if the '''lockinontimeout''' is set to true, the state will transition to LOCKED_IN when '''timeoutheight''' is reached. + The genesis block has state DEFINED for each deployment, by definition. State GetStateForBlock(block) { @@ -104,13 +110,13 @@ 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 height or the timeout. +We remain in the initial state until either we pass the start block height or the timeout height. case DEFINED: - if (block.height >= timeout) { + if (block.height >= timeoutheight) { return (lockinontimeout == true) ? LOCKED_IN : FAILING; } - if (block.height >= start) { + if (block.height >= startheight) { return STARTED; } return DEFINED; @@ -125,9 +131,9 @@ other one simultaneously transitions to STARTED, which would mean both would dem Note that a block's state never depends on its own nVersion; only on that of its ancestors. case STARTED: - if (block.height >= timeout) { + if (block.height >= timeoutheight) { return (lockinontimeout == true) ? LOCKED_IN : FAILING; - } + int count = 0; walk = block; for (i = 0; i < 2016; i++) { @@ -184,11 +190,43 @@ To support upgrade warnings, an extra "unknown upgrade" is tracked, using the "i ===getblocktemplate changes=== -BIP 8 is compatible with and reuses the GBT changes from BIP 9. +The template request Object is extended to include a new item: + +{| class="wikitable" +!colspan=4| template request +|- +! Key !! Required !! Type !! Description +|- +| rules || No || Array of Strings || list of supported softfork deployments, by name +|} + +The template Object is also extended: + +{| class="wikitable" +!colspan=4| template +|- +! Key !! Required !! Type !! Description +|- +| rules || Yes || Array of Strings || list of softfork deployments, by name, that are active state +|- +| vbavailable || Yes || Object || set of pending, supported softfork deployments; each uses the softfork name as the key, and the softfork bit as its value +|- +| vbrequired || No || Number || bit mask of softfork deployment version bits the server requires enabled in submissions +|} + +The "version" key of the template is retained, and used to indicate the server's preference of deployments. +If versionbits is being used, "version" MUST be within the versionbits range of [0x20000000...0x3FFFFFFF]. +Miners MAY clear or set bits in the block version WITHOUT any special "mutable" key, provided they are listed among the template's "vbavailable" and (when clearing is desired) NOT included as a bit in "vbrequired". + +Softfork deployment names listed in "rules" or as keys in "vbavailable" may be prefixed by a '!' character. +Without this prefix, GBT clients may assume the rule will not impact usage of the template as-is; typical examples of this would be when previously valid transactions cease to be valid, such as BIPs 16, 65, 66, 68, 112, and 113. +If a client does not understand a rule without the prefix, it may use it unmodified for mining. +On the other hand, when this prefix is used, it indicates a more subtle change to the block structure or generation transaction; examples of this would be BIP 34 (because it modifies coinbase construction) and 141 (since it modifies the txid hashing and adds a commitment to the generation transaction). +A client that does not understand a rule prefixed by '!' must not attempt to process the template, and must not attempt to use it for mining even unmodified. === Reference implementation === -https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip-uaversionbits +https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip8-height ==Contrasted with BIP 9== @@ -198,7 +236,7 @@ https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip-uaversionbits ==Backwards compatibility== -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. +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 '''timeoutheight''', however, those nodes will still accept the blocks generated by activated nodes. ==Deployments== |