bitcoin · kanzure · Nov 9, 2024 · Nov 11, 2024
diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki
@@ -28,11 +28,11 @@ There are three kinds of BIP:
 
 ==BIP Work Flow==
 
-The BIP process begins with a new idea for Bitcoin. Each potential BIP must have a champion -- someone who writes the BIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The BIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is BIP-able. Posting to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev@lists.linuxfoundation.org] mailing list (and maybe the [https://bitcointalk.org/index.php?board=6.0 Development & Technical Discussion] forum) is the best way to go about this.
+The BIP process begins with a new idea for Bitcoin. Each potential BIP must have a champion -- someone who writes the BIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The BIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is BIP-able. Posting to the [https://groups.google.com/g/bitcoindev bitcoin-dev] mailing list (and maybe the [https://bitcointalk.org/index.php?board=6.0 Development & Technical Discussion] forum) is the best way to go about this.
 
 Vetting an idea publicly before going as far as writing a BIP is meant to save both the potential author and the wider community time. Many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons. Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used. Small enhancements or patches often don't need standardisation between multiple projects; these don't need a BIP and should be injected into the relevant Bitcoin development work flow with a patch submission to the applicable Bitcoin issue tracker.
 
-Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev] mailing list. This gives the author a chance to flesh out the draft BIP to make it properly formatted, of high quality, and to address additional concerns about the proposal. Following a discussion, the proposal should be sent to the bitcoin-dev list and the BIP editor with the draft BIP. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed.
+Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the [https://groups.google.com/g/bitcoindev bitcoin-dev]. This gives the author a chance to flesh out the draft BIP to make it properly formatted, of high quality, and to address additional concerns about the proposal. Following a discussion, the proposal should be sent to the bitcoin-dev list and the BIP editor with the draft BIP. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed.
 
 BIP authors are responsible for collecting community feedback on both the initial idea and the BIP before submitting it for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the BIP author accept private comments in the early design phases, setting up a wiki page or git repository, etc. BIP authors should use their discretion here.
 

diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki
@@ -272,7 +272,7 @@ A living list of deployment proposals can be found [[bip-0008/assignments.mediaw
 
 [[bip-0009.mediawiki|BIP9]]
 
-[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013643.html Mailing list discussion]
+[https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013643.html Mailing list discussion]
 
 ==Copyright==
 

diff --git a/bip-0046.mediawiki b/bip-0046.mediawiki
@@ -9,7 +9,7 @@
   Type: Standards Track
   Created: 2022-04-01
   License: CC0-1.0
-  Post-History: 2022-05-01: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020389.html
+  Post-History: 2022-05-01: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020389.html
 </pre>
 
 == Abstract ==

diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki
@@ -384,4 +384,4 @@ Alice's wallet should spend the notification change output at the next appropria
 * [[https://github.com/petertodd/dust-b-gone|dust-b-gone]]
 * [[https://en.bitcoin.it/wiki/Base58Check_encoding|Base58Check encoding]]
 * [[https://bitmessage.org/bitmessage.pdf|Bitmessage]]
-* [[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-April/007812.html|Mailing list discussion]]
+* [[https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-April/007812.html|Mailing list discussion]]
diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki
@@ -318,7 +318,7 @@ PayPub
 
 Jeremy Spilman Payment Channels
 
-* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html
+* https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html
 
 
 ==Implementations==

diff --git a/bip-0066.mediawiki b/bip-0066.mediawiki
@@ -144,4 +144,4 @@ This document is extracted from the previous BIP62 proposal, which had input fro
 
 ==Disclosures==
 
-* Subsequent to the network-wide adoption and enforcement of this BIP, the author [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009697.html disclosed] that strict DER signatures provided an indirect solution to a consensus bug he had previously discovered.
+* Subsequent to the network-wide adoption and enforcement of this BIP, the author [https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009697.html disclosed] that strict DER signatures provided an indirect solution to a consensus bug he had previously discovered.
diff --git a/bip-0069.mediawiki b/bip-0069.mediawiki
@@ -141,8 +141,8 @@ Outputs:
 
 ==Discussion==
 
-* [[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008484.html|<nowiki>[Bitcoin-development]</nowiki> Lexicographical Indexing of Transaction Inputs and Outputs]]
-* [[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008487.html|<nowiki>[Bitcoin-development] [RFC]</nowiki> Canonical input and output ordering in transactions]]
+* [[https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008484.html|<nowiki>[Bitcoin-development]</nowiki> Lexicographical Indexing of Transaction Inputs and Outputs]]
+* [[https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008487.html|<nowiki>[Bitcoin-development] [RFC]</nowiki> Canonical input and output ordering in transactions]]
 
 ==References==
 

diff --git a/bip-0087.mediawiki b/bip-0087.mediawiki
@@ -263,7 +263,7 @@ Special thanks to SomberNight, Craig Raw, David Harding, Jochen Hoenicke, Sjors
 
 ==References==
 
-Original mailing list thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018630.html
+Original mailing list thread: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018630.html
 
 * [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-0032 (Hierarchical Deterministic Wallets)]
 * [https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki BIP-0043 (Purpose Field for Deterministic Wallets)]

diff --git a/bip-0091.mediawiki b/bip-0091.mediawiki
@@ -100,7 +100,7 @@ By orphaning non-signalling blocks during the BIP9 bit 1 "segwit" deployment, th
 
 ==References==
 
-*[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013714.html Mailing list discussion]
+*[https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013714.html Mailing list discussion]
 *[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283 P2SH flag day activation]
 *[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]]
 *[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]

diff --git a/bip-0093.mediawiki b/bip-0093.mediawiki
@@ -9,7 +9,7 @@
   Type: Informational
   Created: 2023-02-13
   License: BSD-3-Clause
-  Post-History: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021469.html
+  Post-History: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021469.html
 </pre>
 
 ==Introduction==

diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki
@@ -8,7 +8,7 @@
   Type: Informational
   Created: 2015-06-20
   License: PD
-  Post-History: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html
+  Post-History: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html
 </pre>
 
 ==Abstract==

diff --git a/bip-0101.mediawiki b/bip-0101.mediawiki
@@ -87,7 +87,7 @@ The limits proposed by this BIP are designed so that running a fully validating
 
 ===Centralization of mining: big-block attacks===
 
-[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008820.html Simulations show] that with the current peer-to-peer protocol, miners behind high-latency or low-bandwidth links are at a disadvantage compared to miners connected to a majority of hashpower via low-latency, high-bandwidth links. Larger blocks increase the advantage of miners with high-bandwidth connections, although that advantage can be minimized with changes to the way new blocks are announced (e.g. http://bitcoinrelaynetwork.org/ ).
+[https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008820.html Simulations show] that with the current peer-to-peer protocol, miners behind high-latency or low-bandwidth links are at a disadvantage compared to miners connected to a majority of hashpower via low-latency, high-bandwidth links. Larger blocks increase the advantage of miners with high-bandwidth connections, although that advantage can be minimized with changes to the way new blocks are announced (e.g. http://bitcoinrelaynetwork.org/ ).
 
 If latency and bandwidth to other miners were the only variable that affected the profitability of mining, and miners were driven purely by profit, the end result would be one miner running on one machine, where latency was zero and bandwidth was essentially infinite.
 

diff --git a/bip-0106.mediawiki b/bip-0106.mediawiki
@@ -52,7 +52,7 @@ https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&
 
 ==Rationale==
 
-These two proposals have been derived after discussion on [https://bitcointalk.org/index.php?topic=1154536.0 BitcoinTalk] and [http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010285.html bitcoin-dev mailing list]. The original idea and its evolution in the light of various arguments can be found [http://upalc.com/maxblocksize.php here].
+These two proposals have been derived after discussion on [https://bitcointalk.org/index.php?topic=1154536.0 BitcoinTalk] and [https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010285.html bitcoin-dev mailing list]. The original idea and its evolution in the light of various arguments can be found [http://upalc.com/maxblocksize.php here].
 
 ===Proposal 1 : Depending only on previous block size calculation===
 

diff --git a/bip-0111.mediawiki b/bip-0111.mediawiki
@@ -27,7 +27,7 @@ BIP 37 did not specify a service bit for the bloom filter service, thus
 implicitly assuming that all nodes that serve peers data support it.
 However, the connection filtering algorithm proposed in BIP 37, and
 implemented in several clients today, has been shown to provide little
-to no privacy<ref>http://eprint.iacr.org/2014/763</ref>, as well as being a large DoS risk on some nodes<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-July/003044.html] is one example where the issues were found, though others independently discovered issues as well. Sample DoS exploit code available at https://github.com/petertodd/bloom-io-attack.</ref>.
+to no privacy<ref>http://eprint.iacr.org/2014/763</ref>, as well as being a large DoS risk on some nodes<ref>[https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-July/003044.html] is one example where the issues were found, though others independently discovered issues as well. Sample DoS exploit code available at https://github.com/petertodd/bloom-io-attack.</ref>.
 Thus, allowing node operators to disable connection bloom filtering is a
 much-needed feature.
 

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
@@ -378,19 +378,19 @@ Thanks to Eric Lombrozo and Anthony Towns for contributing example use cases.
 
 [https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki BIP 113] Median past block time for time-lock constraints
 
-[http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000021.html HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and revocation hashes]
+[https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000021.html HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and revocation hashes]
 
 [http://lightning.network/lightning-network-paper.pdf Lightning Network]
 
 [https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf Deployable Lightning]
 
 [http://diyhpl.us/diyhpluswiki/transcripts/sf-bitcoin-meetup/2015-02-23-scaling-bitcoin-to-billions-of-transactions-per-day/ Scaling Bitcoin to Billions of Transactions Per Day]
 
-[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010396.html Softfork deployment considerations]
+[https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010396.html Softfork deployment considerations]
 
 [https://web.archive.org/web/20210925124425/https://gist.github.com/sipa/bf69659f43e763540550 Version bits]
 
-[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html Jeremy Spilman Micropayment Channels]
+[https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html Jeremy Spilman Micropayment Channels]
 
 
 ==Copyright==

diff --git a/bip-0113.mediawiki b/bip-0113.mediawiki
@@ -116,7 +116,7 @@ concerns with existing protocols.
 
 [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP112: CHECKSEQUENCEVERIFY]
 
-[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010396.html Softfork deployment considerations]
+[https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010396.html Softfork deployment considerations]
 
 [https://gist.github.com/sipa/bf69659f43e763540550 Version bits]
 

diff --git a/bip-0117.mediawiki b/bip-0117.mediawiki
@@ -189,7 +189,7 @@ The v0 segwit rules prohibit leaving anything on the stack, so for v0 parameters
 
 [3] [https://github.com/bitcoin/bips/blob/master/bip-0116.mediawiki BIP116: MERKLEBRANCHVERIFY]
 
-[4] "[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015028.html An explanation and justification of the tail-call and MBV approach to MAST]", Mark Friedenbach, Bitcoin Development Mailing List, 20 September 2017.
+[4] "[https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015028.html An explanation and justification of the tail-call and MBV approach to MAST]", Mark Friedenbach, Bitcoin Development Mailing List, 20 September 2017.
 
 [5] [https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki BIP114: Merkelized Abstract Syntax Tree]
 

diff --git a/bip-0118.mediawiki b/bip-0118.mediawiki
@@ -42,7 +42,7 @@ As a result, a single signature for a third, even later transaction must be able
 On the other hand, these cases also provide a good reason to have the option to commit to the script: because each transaction has a new script, committing to the script allows you to produce a signature that applies to precisely one of these transactions.
 In the eltoo case, this allows you to have a signature for an update transaction that can be applied to any prior update, and a signature for a settlement transaction that applies only to the corresponding update transaction, while using the same key for both, which in turn allows for a more compact script.
 </ref> and value <ref>'''Why (and why not) commit to the input value?'''
-Committing to the input value may provide additional safety that a signature can't be maliciously reused to claim funds that the signer does not intend to spend, so by default it seems sensible to commit to it. However, doing so prevents being able to use a single signature to consolidate a group of UTXOs with the same spending condition into a single UTXO which may be useful for some protocols, such as the proposal for [https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002448.html layered commitments with eltoo].</ref>).
+Committing to the input value may provide additional safety that a signature can't be maliciously reused to claim funds that the signer does not intend to spend, so by default it seems sensible to commit to it. However, doing so prevents being able to use a single signature to consolidate a group of UTXOs with the same spending condition into a single UTXO which may be useful for some protocols, such as the proposal for [https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002448.html layered commitments with eltoo].</ref>).
 Removing this commitment allows dynamic rebinding of a signed transaction to another previous output that requires authorisation by the same key.
 
 The dynamic rebinding is opt-in due to using a separate public key type, and the breadth of transactions the signature can be rebound to can be further restricted by using different keys, committing to the script being spent in the signature, using different amounts between UTXOs, using different nSequence values in the spending transaction, or using the codeseparator opcode to commit to the position in the script.
@@ -200,6 +200,6 @@ Apart from being based on Taproot rather than SegWit v0, the main differences to
 
 == Acknowledgements ==
 
-The <code>SIGHASH_NOINPUT</code> flag was first proposed by Joseph Poon in [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012460.html February 2016], after being mentioned in the original [http://lightning.network/lightning-network-paper.pdf Lightning paper] by Joseph Poon and Thaddeus Dryja.
+The <code>SIGHASH_NOINPUT</code> flag was first proposed by Joseph Poon in [https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012460.html February 2016], after being mentioned in the original [http://lightning.network/lightning-network-paper.pdf Lightning paper] by Joseph Poon and Thaddeus Dryja.
 This document is the result of discussions with many people and had direct input from Greg Maxwell, Jonas Nick, Pieter Wuille and others.
Original file line number	Diff line number	Diff line change
Expand Up		@@ -144,4 +144,4 @@ This document is extracted from the previous BIP62 proposal, which had input fro

		==Disclosures==

		* Subsequent to the network-wide adoption and enforcement of this BIP, the author [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009697.html disclosed] that strict DER signatures provided an indirect solution to a consensus bug he had previously discovered.
		* Subsequent to the network-wide adoption and enforcement of this BIP, the author [https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009697.html disclosed] that strict DER signatures provided an indirect solution to a consensus bug he had previously discovered.