update lists.linuxfoundation.org urls to gnusha.org/url

Unfortunately, lists.linuxfoundation.org is no longer hosting the bitcoin-dev mailing list static archives nor any other mailing list static archives. gnusha.org/url is a web service that redirects old style archive urls to a new location where the content can be viewed. For more information see: https://gnusha.org/url/ https://x.com/kanzure/status/1853779672514826334 bitcoin/bitcoin#29782 (comment) bitcoin/bitcoin#31240 bitcoinops/bitcoinops.github.io#2018
kanzure · Nov 9, 2024 · 55a92a5 · 55a92a5
1 parent c58a428
commit 55a92a5
Show file tree

Hide file tree

Showing 40 changed files with 96 additions and 96 deletions.
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-0112.mediawiki b/bip-0112.mediawiki
@@ -390,7 +390,7 @@ Thanks to Eric Lombrozo and Anthony Towns for contributing example use cases.
 
 [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-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.
 
diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki
@@ -393,7 +393,7 @@ transaction preimages.
 The Taproot/Schnorr BIPs use Tagged Hashes
 (`SHA256(SHA256(tag)||SHA256(tag)||msg)`) to prevent taproot leaves, branches,
 tweaks, and signatures from overlapping in a way that might introduce a security
-[vulnerability https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016091.html].
+[vulnerability https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016091.html].
 
 OP_CHECKTEMPLATEVERIFY is not subject to this sort of vulnerability as the
 hashes are effectively tagged externally, that is, by OP_CHECKTEMPLATEVERIFY
@@ -669,8 +669,8 @@ for older node versions that can be patched but not upgraded to a newer major re
 *[https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf Enhancing Bitcoin Transactions with Covenants]
 *[https://github.com/jamesob/simple-ctv-vault Simple CTV Vaults]
 *[https://github.com/kanzure/python-vaults Python Vaults]
-*[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html CTV Dramatically Improves DLCs]
-*[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020225.html Calculus of Covenants]
+*[https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html CTV Dramatically Improves DLCs]
+*[https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020225.html Calculus of Covenants]
 *[https://rubin.io/bitcoin/2021/12/10/advent-13/ Payment Pools with CTV]
 *[https://rubin.io/bitcoin/2021/12/11/advent-14/ Channels with CTV]
 *[https://rubin.io/bitcoin/2021/12/09/advent-12/ Congestion Control with CTV]

diff --git a/bip-0122.mediawiki b/bip-0122.mediawiki
@@ -9,7 +9,7 @@
   Type: Standards Track
   Created: 2015-08-29
   License: PD
-  Post-History: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010712.html
+  Post-History: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010712.html
 </pre>
 
 ==Abstract==

diff --git a/bip-0129.mediawiki b/bip-0129.mediawiki
@@ -460,6 +460,6 @@ Special thanks to Pavol Rusnak, Dmitry Petukhov, Christopher Allen, Craig Raw, R
 ==References==
 
 Related mailing list threads:
-* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018385.html
-* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018732.html
+* https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018385.html
+* https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018732.html
 
diff --git a/bip-0132.mediawiki b/bip-0132.mediawiki
@@ -48,7 +48,7 @@ The author doesn't believe this is a problem because a BIP cannot be forced on c
 
 == Process ==
 
-* '''Submit for Comments.''' The first BIP champion named in the proposal can call a &quot;submit for comments&quot; at any time by posting to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Dev Mailing List] mailing with the BIP number and a statement that the champion intends to immediately submit the BIP for comments.
+* '''Submit for Comments.''' The first BIP champion named in the proposal can call a &quot;submit for comments&quot; at any time by posting to the [https://gnusha.org/url/https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Dev Mailing List] mailing with the BIP number and a statement that the champion intends to immediately submit the BIP for comments.
 ** The BIP must have been assigned BIP-number (i.e. been approved by the BIP editor) to be submitted for comments.
 * '''Comments.'''
 ** After a BIP has been submitted for comments, a two-week waiting period begins in which the community should transition from making suggestions about a proposal to publishing their opinions or concerns on the proposal.

diff --git a/bip-0135.mediawiki b/bip-0135.mediawiki
@@ -10,7 +10,7 @@
   Created: 2017-03-29
   License: CC0-1.0
            GNU-All-Permissive
-  Post-History: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013969.html
+  Post-History: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013969.html
   Replaces: 9
 </pre>
 

diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki
@@ -156,7 +156,7 @@ A major difference at consensus level is described in [https://github.com/bitcoi
 Three relay and mining policies are also included in the first release of segregated witness at reference implementation version 0.13.1. Softforks based on these policies are likely to be proposed in the near future. To avoid indefinite delay in transaction confirmation and permanent fund loss in a potential softfork, users MUST observe the new semantics carefully:
 
 # Only compressed public keys are accepted in P2WPKH and P2WSH (See [https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Restrictions_on_public_key_type BIP143])
-# The argument of OP_IF/NOTIF in P2WSH must be minimal<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013014.html</ref>
+# The argument of OP_IF/NOTIF in P2WSH must be minimal<ref>https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013014.html</ref>
 # Signature(s) must be null vector(s) if an OP_CHECKSIG or OP_CHECKMULTISIG is failed (for both pre-segregated witness script and P2WSH. See [https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki BIP146])
 
 == Examples ==

diff --git a/bip-0148.mediawiki b/bip-0148.mediawiki
@@ -73,7 +73,7 @@ By orphaning non-signalling blocks during the last month of the BIP9 bit 1 "segw
 
 ==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-0149.mediawiki b/bip-0149.mediawiki
@@ -52,7 +52,7 @@ The '''starttime''' of this BIP is after the BIP9-segwit timeout to remove compa
 
 ==References==
 
-[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014234.html Mailing list discussion]
+[https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014234.html Mailing list discussion]
 
 [[bip-0008.mediawiki|BIP8]]
 

diff --git a/bip-0157.mediawiki b/bip-0157.mediawiki
@@ -22,7 +22,7 @@ defined in BIP
 37<ref>https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki</ref>, has
 known flaws that weaken the security and privacy of clients and allow
 denial-of-service attack vectors on full
-nodes<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012636.html</ref>.
+nodes<ref>https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012636.html</ref>.
 The new protocol overcomes these issues by allowing light clients to obtain
 compact probabilistic filters of block content from full nodes and download full
 blocks if the filter matches relevant data.
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.