Minor: linking BIPs in BIP9

Author: fresheneesz

bip-0009.mediawiki

@@ -19,9 +19,9 @@ This document specifies a proposed change to the semantics of the 'version' fiel
 
 ==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.
+[https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki 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.
+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 [https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP 66] and [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65], which further removed nVersions 2 and 3 as valid options. As will be shown further, this is unnecessary.
 
 ==Specification==
 
@@ -195,7 +195,7 @@ If versionbits is being used, "version" MUST be within the versionbits range of
 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.
+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 [https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki 16], [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki 65], [https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki 66], [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki 68], [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki 112], and [https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki 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.