Add internal hyperlinks to BIPs for improved readability

donatik27 commented at 6:19 am on July 11, 2025: none

This pull request updates several BIP documents to include internal hyperlinks to other referenced BIPs using mediawiki format. These changes improve cross-referencing, readability, and navigation within the documentation. The following updates were made: Replaced plain-text BIP references (e.g., “BIP 34”) with mediawiki-style hyperlinks (e.g., [[bip-0034.mediawiki|BIP34]]). Applied changes across multiple BIP files, including bip-0008.mediawiki, bip-0017.mediawiki, and others. No content logic was modified — only formatting and link enhancements were applied.

Update bip-0008.mediawiki 110efa8cdb

Update bip-0009.mediawiki 0b6c8287ed

Update bip-0017.mediawiki 831538700f

in bip-0008.mediawiki:25 in 831538700f

21@@ -22,11 +22,11 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
22 
23 ==Motivation==
24 
25-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 optional flag day activation after a reasonable time, as well as for accelerated activation by majority of hash rate before the flag date.
26+[[bip-0009.mediawiki|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 optional flag day activation after a reasonable time, as well as for accelerated activation by majority of hash rate before the flag date.

murchandamus commented at 6:50 pm on July 11, 2025:

BIP 9 is already linked in line 17. It is sufficient to link to related proposals in the first instance, linking to them at every single mention just creates visual clutter.

in bip-0009.mediawiki:24 in 831538700f

20@@ -21,7 +21,7 @@ This document specifies a proposed change to the semantics of the 'version' fiel
21 
22 [[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.
23 
24-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-0066.mediawiki|BIP 66]] and [[bip-0065.mediawiki|BIP 65]], which further removed nVersions 2 and 3 as valid options. As will be shown further, this is unnecessary.
25+In addition, [[bip-0034.mediawiki|BIP34]] 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-0066.mediawiki|BIP 66]] and [[bip-0065.mediawiki|BIP 65]], which further removed nVersions 2 and 3 as valid options. As will be shown further, this is unnecessary.

murchandamus commented at 6:51 pm on July 11, 2025:

BIP 34 is already linked in line 22.

in bip-0009.mediawiki:64 in 831538700f

60@@ -61,7 +61,7 @@ The nVersion block header field is to be interpreted as a 32-bit little-endian i
61 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
62 001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive.
63 
64-Due to the constraints set by BIP 34, BIP 66 and BIP 65, we only have 0x7FFFFFFB possible nVersion values available.
65+Due to the constraints set by [[bip-0034.mediawiki|BIP34]], [[bip-0034.mediawiki|BIP34]] and [[bip-0065.mediawiki|BIP65]], we only have 0x7FFFFFFB possible nVersion values available.

murchandamus commented at 6:55 pm on July 11, 2025:

This links to BIP 34 twice instead of BIP 66, and all three BIPs have been linked in line 24 already.

in bip-0017.mediawiki:68 in 831538700f

61@@ -62,9 +62,10 @@ For example, the scriptPubKey and corresponding scriptSig for a one-signature-re
62 
63 ==Rationale==
64 
65-This BIP replaces BIP 12 and BIP 16, which propose evaluating a Script from the stack after verifying its hash.
66+This BIP replaces [[bip-0012.mediawiki|BIP 12]] and [[bip-0016.mediawiki|BIP 16]], which propose evaluating a Script from the stack after verifying its hash.
67+This BIP replaces  and [[bip-0016.mediawiki|BIP 16]], which propose evaluating a Script from the stack after verifying its hash.
68 
69-The Motivation for this BIP (and BIP 13, the pay-to-script-hash address type) is somewhat controversial; several people feel that it is unnecessary, and complex/multisignature transaction types should be supported by simply giving the sender the complete {serialized script}. The author believes that this BIP will minimize the changes needed to all of the supporting infrastructure that has already been created to send funds to a base58-encoded-20-byte bitcoin addresses, allowing merchants and exchanges and other software to start supporting multisignature transactions sooner.
70+The Motivation for this BIP (and [[bip-0016.mediawiki|BIP 16]], the pay-to-script-hash address type) is somewhat controversial; several people feel that it is unnecessary, and complex/multisignature transaction types should be supported by simply giving the sender the complete {serialized script}. The author believes that this BIP will minimize the changes needed to all of the supporting infrastructure that has already been created to send funds to a base58-encoded-20-byte bitcoin addresses, allowing merchants and exchanges and other software to start supporting multisignature transactions sooner.

murchandamus commented at 6:56 pm on July 11, 2025:

This incorrectly replaces BIP 13 with BIP 16.

murchandamus commented at 7:01 pm on July 11, 2025: contributor

These changes are sloppily put together and mostly repeat prior links in the same documents. The proposed changes do not amount to a substantial improvement. Please refrain from creating busywork for other contributors.

murchandamus closed this on Jul 11, 2025

Add internal hyperlinks to BIPs for improved readability #1894