diff --git a/ch10.asciidoc b/ch10.asciidoc index 53e310a9..ece90ffd 100644 --- a/ch10.asciidoc +++ b/ch10.asciidoc @@ -26,7 +26,7 @@ are not yet mature. See the following section for more information. To remove the incentive to lie and strengthen the security of timelocks, a BIP was proposed and activated at the same time as the BIPs for -relative timelocks. This is BIP-113, which defines a new consensus +relative timelocks. This is BIP113, which defines a new consensus measurement of time called _Median-Time-Past_. Median-Time-Past is calculated by taking the timestamps of the last 11 @@ -45,7 +45,7 @@ for it when estimating the desired value to encode in +nLocktime+, +nSequence+, +CLTV+, and +CSV+. Median-Time-Past is specified in -https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki[BIP-113]. +https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki[BIP113]. [[duplicate_transactions]] === Preventing Duplicate Transactions @@ -708,7 +708,7 @@ miners use the coinbase data to include extra nonce values and strings identifying the mining pool. The first few bytes of the coinbase used to be arbitrary, but that is no -longer the case. As per BIP-34, version-2 blocks (blocks with the +longer the case. As per BIP34, version-2 blocks (blocks with the version field set to 2) must contain the block height index as a script "push" operation in the beginning of the coinbase field. @@ -729,17 +729,17 @@ extra _nonce_ (see <>), or random value, used to find a suitable Proof-of-Work solution. ((("bitcoin improvement proposals", "Pay to Script Hash -(BIP-16)")))((("bitcoin improvement proposals", "CHECKHASHVERIFY -(BIP-17)")))((("CHECKHASHVERIFY (CHV)")))((("Pay-to-Script-Hash (P2SH)", +(BIP16)")))((("bitcoin improvement proposals", "CHECKHASHVERIFY +(BIP17)")))((("CHECKHASHVERIFY (CHV)")))((("Pay-to-Script-Hash (P2SH)", "coinbase data")))The final part of the coinbase data (+2f503253482f+) is the ASCII-encoded string pass:[/P2SH/], which indicates that the mining node that mined this block supports the P2SH improvement -defined in BIP-16. The introduction of the P2SH capability required -signaling by miners to endorse either BIP-16 or BIP-17. Those endorsing -the BIP-16 implementation were to include +/P2SH/+ in their coinbase -data. Those endorsing the BIP-17 implementation of P2SH were to include -the string +p2sh/CHV+ in their coinbase data. The BIP-16 was elected as +defined in BIP16. The introduction of the P2SH capability required +signaling by miners to endorse either BIP16 or BIP17. Those endorsing +the BIP16 implementation were to include +/P2SH/+ in their coinbase +data. Those endorsing the BIP17 implementation of P2SH were to include +the string +p2sh/CHV+ in their coinbase data. The BIP16 was elected as the winner, and many miners continued including the string +/P2SH/+ in their coinbase to indicate support for this feature. @@ -2379,7 +2379,7 @@ only under near-unanimous consensus. Already we have seen the emergence of new methodologies to address the risks of hard forks. In the next section, we will look at soft forks, -and the BIP-34 and BIP-9 methods for signaling and activation of +and the BIP34 and BIP9 methods for signaling and activation of consensus modifications. ==== Soft Forks @@ -2420,12 +2420,12 @@ script is interpreted as a null-potent operator, meaning they have no effect. Execution continues after the NOP opcode as if it wasn't there. A soft fork therefore can modify the semantics of a NOP code to give it -new meaning. For example, BIP-65 (+CHECKLOCKTIMEVERIFY+) reinterpreted -the NOP2 opcode. Clients implementing BIP-65 interpret NOP2 as +new meaning. For example, BIP65 (+CHECKLOCKTIMEVERIFY+) reinterpreted +the NOP2 opcode. Clients implementing BIP65 interpret NOP2 as +OP_CHECKLOCKTIMEVERIFY+ and impose an absolute locktime consensus rule on UTXO that contain this opcode in their locking scripts. This change -is a soft fork because a transaction that is valid under BIP-65 is also -valid on any client that is not implementing (ignorant of) BIP-65. To +is a soft fork because a transaction that is valid under BIP65 is also +valid on any client that is not implementing (ignorant of) BIP65. To the old clients, the script contains an NOP code, which is ignored. ===== Other ways to soft fork upgrade @@ -2494,33 +2494,33 @@ readiness: a majority of miners must agree that they are ready and willing to enforce the new consensus rules. To coordinate their actions, there is a signaling mechanism that allows them to show their support for a consensus rule change. This mechanism was introduced with the -activation of BIP-34 in March 2013 and replaced by the activation of -BIP-9 in July 2016. +activation of BIP34 in March 2013 and replaced by the activation of +BIP9 in July 2016. -==== BIP-34 Signaling and Activation +==== BIP34 Signaling and Activation ((("bitcoin improvement proposals", "Block v2, Height in Coinbase -(BIP-34)")))The first implementation, in BIP-34, used the block version +(BIP34)")))The first implementation, in BIP34, used the block version field to allow miners to signal readiness for a specific consensus rule -change. Prior to BIP-34, the block version was set to "1" by +change. Prior to BIP34, the block version was set to "1" by _convention_ not enforced by _consensus_. -BIP-34 defined a consensus rule change that required the coinbase field +BIP34 defined a consensus rule change that required the coinbase field (input) of the coinbase transaction to contain the block height. Prior -to BIP-34, the coinbase could contain any arbitrary data the miners -chose to include. After activation of BIP-34, valid blocks had to +to BIP34, the coinbase could contain any arbitrary data the miners +chose to include. After activation of BIP34, valid blocks had to contain a specific block-height at the beginning of the coinbase and be identified with a version number greater than or equal to "2." -To signal the change and activation of BIP-34, miners set the block +To signal the change and activation of BIP34, miners set the block version to "2," instead of "1." This did not immediately make version "1" blocks invalid. Once activated, version "1" blocks would become invalid and all version "2" blocks would be required to contain the block height in the coinbase to be valid. -BIP-34 defined a two-step activation mechanism, based on a rolling +BIP34 defined a two-step activation mechanism, based on a rolling window of 1000 blocks. A miner would signal his or her individual -readiness for BIP-34 by constructing blocks with "2" as the version +readiness for BIP34 by constructing blocks with "2" as the version number. Strictly speaking, these blocks did not yet have to comply with the new consensus rule of including the block-height in the coinbase transaction because the consensus rule had not yet been activated. The @@ -2539,32 +2539,32 @@ consensus rules activated in two steps: new consensus rules, and all valid blocks must contain block-height in the coinbase transaction. -After successful signaling and activation under the BIP-34 rules, this +After successful signaling and activation under the BIP34 rules, this mechanism was used twice more to activate soft forks: -- https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki[BIP-66] - Strict DER Encoding of Signatures was activated by BIP-34 style +- https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki[BIP66] + Strict DER Encoding of Signatures was activated by BIP34 style signaling with a block version "3" and invalidating version "2" blocks. -- https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki[BIP-65] - +CHECKLOCKTIMEVERIFY+ was activated by BIP-34 style signaling with a +- https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki[BIP65] + +CHECKLOCKTIMEVERIFY+ was activated by BIP34 style signaling with a block version "4" and invalidating version "3" blocks. -After the activation of BIP-65, the signaling and activation mechanism -of BIP-34 was retired and replaced with the BIP-9 signaling mechanism +After the activation of BIP65, the signaling and activation mechanism +of BIP34 was retired and replaced with the BIP9 signaling mechanism described next. The standard is defined in -https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki[BIP-34 +https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki[BIP34 (Block v2, Height in Coinbase)]. -==== BIP-9 Signaling and Activation +==== BIP9 Signaling and Activation ((("bitcoin improvement proposals", "Version bits with timeout and delay -(BIP-9)")))((("bitcoin improvement proposals", "CHECKLOCKTIMEVERIFY -(BIP-65)")))((("bitcoin improvement proposals", "Strict DER signatures -(BIP-66)")))The mechanism used by BIP-34, BIP-66, and BIP-65 was +(BIP9)")))((("bitcoin improvement proposals", "CHECKLOCKTIMEVERIFY +(BIP65)")))((("bitcoin improvement proposals", "Strict DER signatures +(BIP66)")))The mechanism used by BIP34, BIP66, and BIP65 was successful in activating three soft forks. However, it was replaced because it had several limitations: @@ -2581,16 +2581,16 @@ because it had several limitations: - Each new change irrevocably reduced the available block versions for future changes. -BIP-9 was proposed to overcome these challenges and improve the rate and +BIP9 was proposed to overcome these challenges and improve the rate and ease of implementing future changes. -BIP-9 interprets the block version as a bit field instead of an integer. +BIP9 interprets the block version as a bit field instead of an integer. Because the block version was originally used as an integer, versions 1 through 4, only 29 bits remain available to be used as a bit field. This leaves 29 bits that can be used to independently and simultaneously signal readiness on 29 different proposals. -BIP-9 also sets a maximum time for signaling and activation. This way +BIP9 also sets a maximum time for signaling and activation. This way miners don't need to signal forever. If a proposal is not activated within the +TIMEOUT+ period (defined in the proposal), the proposal is considered rejected. The proposal may be resubmitted for signaling with @@ -2605,7 +2605,7 @@ new changes. [NOTE] ==== While signaling bits can be reused or recycled, as long as the voting -period does not overlap, the authors of BIP-9 recommend that bits are +period does not overlap, the authors of BIP9 recommend that bits are reused only when necessary; unexpected behavior could occur due to bugs in older software. In short, we should not expect to see reuse until all 29 bits have been used once. @@ -2627,13 +2627,13 @@ for the proposal. endtime:: The time (based on MTP) after which the change is considered rejected if it has not reached the activation threshold. -Unlike BIP-34, BIP-9 counts activation signaling in whole intervals +Unlike BIP34, BIP9 counts activation signaling in whole intervals based on the difficulty retarget period of 2016 blocks. For every retarget period, if the sum of blocks signaling for a proposal exceeds 95% (1916 of 2016), the proposal will be activated one retarget period later. -BIP-9 offers a proposal state diagram to illustrate the various stages +BIP9 offers a proposal state diagram to illustrate the various stages and transitions for a proposal, as shown in <>. Proposals start in the +DEFINED+ state, once their parameters are known @@ -2648,15 +2648,15 @@ proposal state changes to +FAILED+, indicating a rejected proposal. +FAILED+ proposals remain in that state perpetually. [[bip9states]] -.BIP-9 state transition diagram -image::images/mbc2_1010.png[BIP-9 Proposal State Transition Diagram] +.BIP9 state transition diagram +image::images/mbc2_1010.png[BIP9 Proposal State Transition Diagram] -BIP-9 was first implemented for the activation of +CHECKSEQUENCEVERIFY+ +BIP9 was first implemented for the activation of +CHECKSEQUENCEVERIFY+ and associated BIPs (68, 112, 113). The proposal named "csv" was activated successfully in July of 2016.((("", startref="forks10a"))) The standard is defined in -https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki[BIP-9 +https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki[BIP9 (Version bits with timeout and delay)]. === Consensus Software Development