From 9ee97173106dfb0886e335a00df1359f6d4279c7 Mon Sep 17 00:00:00 2001 From: Tobin Harding Date: Wed, 9 Jun 2021 10:15:53 +1000 Subject: [PATCH 1/2] Use hyperlinks when mentioning bips When mentioning a bip we use a hyperlink to the bip file to assist readers. There are two mentions of bips in BIP-0009 that do not use links, probably because links where provided above in the text, however, its a bit easier on the reader if we provide links again to save scrolling through the document. Use hyperlinks when mentioning BIP 34 and 141 in isolation. --- bip-0009.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index c9fcd6fd..ad116782 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -197,7 +197,7 @@ Miners MAY clear or set bits in the block version WITHOUT any special "mutable" 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 [[bip-0016.mediawiki|16]], [[bip-0065.mediawiki|65]], [[bip-0066.mediawiki|66]], [[bip-0068.mediawiki|68]], [[bip-0112.mediawiki|112]], and [[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). +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-0034.mediawiki|BIP 34]] (because it modifies coinbase construction) and [[bip-0141.mediawiki|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. ==Support for future changes== From f59b209b913b2b45c99436ac3bce7cd86d623000 Mon Sep 17 00:00:00 2001 From: Tobin Harding Date: Wed, 9 Jun 2021 10:33:59 +1000 Subject: [PATCH 2/2] Fix typo, remove 'in' Phrase 'based on in BIP 43' should probably read 'based on BIP 34'. --- bip-0009.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index ad116782..f7fbad1c 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -205,7 +205,7 @@ A client that does not understand a rule prefixed by '!' must not attempt to pro The mechanism described above is very generic, and variations are possible for future soft forks. Here are some ideas that can be taken into account. '''Modified thresholds''' -The 1916 threshold (based on in BIP 34's 95%) does not have to be maintained for eternity, but changes should take the effect on the warning system into account. In particular, having a lock-in threshold that is incompatible with the one used for the warning system may have long-term effects, as the warning system cannot rely on a permanently detectable condition anymore. +The 1916 threshold (based on BIP 34's 95%) does not have to be maintained for eternity, but changes should take the effect on the warning system into account. In particular, having a lock-in threshold that is incompatible with the one used for the warning system may have long-term effects, as the warning system cannot rely on a permanently detectable condition anymore. '''Conflicting soft forks''' At some point, two mutually exclusive soft forks may be proposed. The naive way to deal with this is to never create software that implements both, but that is making a bet that at least one side is guaranteed to lose. Better would be to encode "soft fork X cannot be locked-in" as consensus rule for the conflicting soft fork - allowing software that supports both, but can never trigger conflicting changes.