CH12: style: s/BIP-/BIP/

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 <<extra_nonce>>), 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:[<span
 class="keep-together"><code>/P2SH/</code></span>], 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 <<bip9states>>.
 
 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