From b640e9e7269dd1d731b5a17b2a055f6bad41d4d7 Mon Sep 17 00:00:00 2001 From: Jon Atack Date: Thu, 16 Apr 2026 10:28:57 -0600 Subject: [PATCH 1/7] bip361: grammar touchups --- bip-0361.mediawiki | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/bip-0361.mediawiki b/bip-0361.mediawiki index 32d3358892..7b758e12ec 100644 --- a/bip-0361.mediawiki +++ b/bip-0361.mediawiki @@ -35,7 +35,7 @@ We seek to secure the value of the UTXO set and minimize incentives for quantum '''Accelerating quantum progress.''' -NIST ratified three production-grade PQ signature schemes in 2024; academic road-maps now estimate a cryptographically-relevant quantum computer as early as 2027-2030, [https://www.mckinsey.com/~/media/mckinsey/business%20functions/mckinsey%20digital/our%20insights/the%20year%20of%20quantum%20from%20concept%20to%20reality%20in%202025/quantum-monitor-2025.pdf?shouldIndex=false per McKinsey]. +NIST ratified three production-grade PQ signature schemes in 2024; academic road-maps now estimate a cryptographically relevant quantum computer as early as 2027-2030, [https://www.mckinsey.com/~/media/mckinsey/business%20functions/mckinsey%20digital/our%20insights/the%20year%20of%20quantum%20from%20concept%20to%20reality%20in%202025/quantum-monitor-2025.pdf?shouldIndex=false per McKinsey]. '''Quantum algorithms are rapidly improving''' @@ -51,7 +51,7 @@ Quantum attackers could compute the private key for known public keys then trans '''Private keys become public.''' -Assuming that quantum computers are able to maintain their current trajectories and overcome existing engineering obstacles, there is a near certain chance that all P2PK (and other outputs with exposed pubkeys) private keys will be found and used to steal the funds. +Assuming that quantum computers are able to maintain their current trajectories and overcome existing engineering obstacles, there is a near-certain chance that all P2PK (and other outputs with exposed pubkeys) private keys will be found and used to steal the funds. '''Impossible to know motivations.''' @@ -59,7 +59,7 @@ Prior to a quantum attack, it is impossible to know the motivations of the attac '''Upgrade inertia.''' -Coordinating wallets, exchanges, miners and custodians historically takes years. +Coordinating wallets, exchanges, miners, and custodians historically takes years. The longer we postpone migration, the harder it becomes to coordinate wallets, exchanges, miners, and custodians. A clear, time-boxed pathway is the only credible defense. @@ -105,7 +105,7 @@ Bitcoin's current signatures (ECDSA/Schnorr) will be a tantalizing target: any U '''Existing Proposals (as of March 2026) are Insufficient. ''' -To date, no quantum related proposal provides protection against: +To date, no quantum-related proposal provides protection against: 1. Short-range attacks. @@ -123,9 +123,9 @@ Any proposal that allows for the quantum theft of "lost" bitcoin is creating a r '''Minimizes attack surface''' -By disallowing new spends to quantum vulnerable script types, we minimize the attack surface with each new UTXO. +By disallowing new spends to quantum-vulnerable script types, we minimize the attack surface with each new UTXO. -Upgrades to Bitcoin have historically taken many years; this will hasten and speed up the adoption of new quantum resistant script types. +Upgrades to Bitcoin have historically taken many years; this will hasten and speed up the adoption of new quantum-resistant script types. With a clear deadline, industry stakeholders will more readily upgrade existing infrastructure to ensure continuity of services. @@ -133,7 +133,7 @@ With a clear deadline, industry stakeholders will more readily upgrade existing The new tighter verification conditions for using ECDSA and Schnorr to spend coins will be designed to rule out quantum attackers, but to permit spends from the authentic coin-holders. Such rescue protocols rely on asymmetry of knowledge between a quantum attacker and the authentic coin-holder. Any context where an asymmetry exists in favor of the authentic holder can theoretically be turned into a rescue protocol. -For instance, most wallets built since its introduction in 2012 have used [[bip-0032.mediawiki|BIP-32]] to construct deterministic HD wallets which derive Bitcoin keypairs from a seed. Any BIP-32 wallet which uses a hardened derivation step in its key-paths can thus satisfy a rescue protocol which uses BIP-32 hardened key derivation to prove knowledge of a parent XPriv which a quantum attacker would be very unlikely to know. [https://groups.google.com/g/bitcoindev/c/Q06piCEJhkI Current research on ZK-STARK-based rescue protocols] suggest proofs could be efficiently scaled, and [https://groups.google.com/g/bitcoindev/c/uUK6py0Yjq0/m/57bQJ3VSCQAJ commit/reveal protocols can likely do so even more efficiently] at the expense of a more challenging multi-step security model. +For instance, most wallets built since its introduction in 2012 have used [[bip-0032.mediawiki|BIP-32]] to construct deterministic HD wallets which derive Bitcoin keypairs from a seed. Any BIP-32 wallet which uses a hardened derivation step in its key-paths can thus satisfy a rescue protocol which uses BIP-32 hardened key derivation to prove knowledge of a parent XPriv, which a quantum attacker would be very unlikely to know. [https://groups.google.com/g/bitcoindev/c/Q06piCEJhkI Current research on ZK-STARK-based rescue protocols] suggest proofs could be efficiently scaled, and [https://groups.google.com/g/bitcoindev/c/uUK6py0Yjq0/m/57bQJ3VSCQAJ commit/reveal protocols can likely do so even more efficiently] at the expense of a more challenging multi-step security model. It remains to be seen how much of the legacy Bitcoin supply can be theoretically covered by such rescue protocols. If one or more rescue protocols can be designed to cover the majority of the Bitcoin supply, then restricting ECDSA/Schnorr verification will be at most mildly confiscatory, and will come at little expense to the overall integrity of the Bitcoin network. @@ -143,7 +143,7 @@ It remains to be seen how much of the legacy Bitcoin supply can be theoretically ! Incentive to Upgrade |- | Miners -| • Larger size PQ signatures along with incentive for users to migrate will create more demand for block space and thus higher fees collected by miners.

• Post-Phase B, non-upgraded miners produce invalid blocks.

• A quantum attack on Bitcoin will significantly devalue both their hardware and Bitcoin as a whole. +| • Larger-size PQ signatures along with incentive for users to migrate will create more demand for block space and thus higher fees collected by miners.

• Post-Phase B, non-upgraded miners produce invalid blocks.

• A quantum attack on Bitcoin will significantly devalue both their hardware and Bitcoin as a whole. |- | Institutional Holders | • Fiduciary duty: failing to act to prevent a quantum attack on Bitcoin would violate the fiduciary duty to shareholders.

• Demonstrating Bitcoin's ability to effectively mitigate emerging threats will prove Bitcoin to be an investment grade asset. @@ -160,13 +160,13 @@ It remains to be seen how much of the legacy Bitcoin supply can be theoretically '''Key Insight''': As mentioned earlier, the proposal turns quantum security into a private incentive to upgrade. -This is not an offensive attack, rather, it is defensive: our thesis is that the Bitcoin ecosystem wishes to defend itself and its interests against those who would prefer to do nothing and allow a malicious actor to destroy both value and trust. +This is not an offensive attack; rather, it is defensive: our thesis is that the Bitcoin ecosystem wishes to defend itself and its interests against those who would prefer to do nothing and allow a malicious actor to destroy both value and trust. "Lost coins only make everyone else's coins worth slightly more. Think of it as a donation to everyone." - Satoshi Nakamoto If true, the corollary is: -"Quantum recovered coins only make everyone else's coins worth less. Think of it as a theft from everyone." +"Quantum-recovered coins only make everyone else's coins worth less. Think of it as a theft from everyone." The timelines that we are proposing are meant to find the best balance between giving ample ability for account owners to migrate while maintaining the integrity of the overall ecosystem to avoid catastrophic attacks. @@ -176,4 +176,4 @@ As a series of soft forks, older nodes will continue to operate without modifica Non-upgraded wallets can receive and send bitcoin from non-upgraded and upgraded wallets until Phase A. After Phase A, they can no longer receive from any other wallets and can only send to upgraded wallets. After Phase B, both senders and receivers will require upgraded wallets. -This BIP is also compatible with an "Hourglass" style BIP for spending P2PK encumbered funds, provided such a BIP has activated by the time Phase B activates. BIP-361 authors support Hourglass for P2PK because it's not currently believed possible to construct a rescue protocol for P2PK UTXOs, as no knowledge asymmetry is known. +This BIP is also compatible with an "Hourglass" style BIP for spending P2PK-encumbered funds, provided such a BIP has activated by the time Phase B activates. BIP-361 authors support Hourglass for P2PK because it's not currently believed possible to construct a rescue protocol for P2PK UTXOs, as no knowledge asymmetry is known. From 4d1a62afd5defec557ed0dba31792728ec20e4f4 Mon Sep 17 00:00:00 2001 From: Jon Atack Date: Sat, 1 Nov 2025 15:54:46 +0100 Subject: [PATCH 2/7] bip99: add editor note about libbitcoin consensus definition Credit to forkfury for pointing out the incomplete sentence in https://github.com/bitcoin/bips/pull/2027. Co-authored-by: forkfury --- bip-0099.mediawiki | 2 ++ 1 file changed, 2 insertions(+) diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki index acf66b310a..3475d0c0df 100644 --- a/bip-0099.mediawiki +++ b/bip-0099.mediawiki @@ -43,6 +43,8 @@ deployment of changes. ;Libbitcoinconsensus : the existing implementation is a library that is compiled by default with Bitcoin Core master and exposes a single C function named bitcoinconsensus_verify_script(). Although it has a deterministic build and implements the most complex rules (most of the cryptography, which is itself heavily based on libsecp256k1 after #REPLACE_libsecp256k1_PR), it is still not a complete specification of the consensus rules. Since libconsensus doesn't manage the current state but only the validation of the next block given that state, it is known that this long effort of encapsulation and decoupling will eventually finish, and that the person who moves the last line +[BIP Editors' note: (a) the last sentence was left incomplete by the BIP author, and (b) the libbitcoin-consensus library was deprecated in Bitcoin Core v27.0 and was completely removed in v28.0; see https://github.com/bitcoin/bitcoin/pull/29189 and https://github.com/bitcoin/bitcoin/pull/29648] + ==Taxonomy of consensus forks== ===Accidental consensus fork=== From 195de00cecbabc28f1720dd987ee6ef7e030b191 Mon Sep 17 00:00:00 2001 From: Jon Atack Date: Fri, 26 Jun 2026 15:53:37 -0600 Subject: [PATCH 3/7] Github -> GitHub --- bip-0098.mediawiki | 2 +- bip-0116.mediawiki | 2 +- bip-0117.mediawiki | 2 +- bip-0433.mediawiki | 2 +- scripts/link-format-chk.sh | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/bip-0098.mediawiki b/bip-0098.mediawiki index d63fd38dc9..2492fd112c 100644 --- a/bip-0098.mediawiki +++ b/bip-0098.mediawiki @@ -278,7 +278,7 @@ Second, final entries on an odd-length list are not duplicated and hashed, which ==Implementation== -An implementation of this BIP for extraction of Merkle branches and fast, log-space Merkle branch validation is available at the following Github repository: +An implementation of this BIP for extraction of Merkle branches and fast, log-space Merkle branch validation is available at the following GitHub repository: [https://github.com/maaku/bitcoin/tree/fast-merkle-tree] diff --git a/bip-0116.mediawiki b/bip-0116.mediawiki index 3f10e01a2c..7eec4f90a9 100644 --- a/bip-0116.mediawiki +++ b/bip-0116.mediawiki @@ -104,7 +104,7 @@ When the honeypot is claimed, the (previous) owner of the coins can tell which s ==Implementation== -An implementation of this BIP, including both consensus code updates and tests is available at the following Github repository: +An implementation of this BIP, including both consensus code updates and tests is available at the following GitHub repository: [https://github.com/maaku/bitcoin/tree/merkle-branch-verify] diff --git a/bip-0117.mediawiki b/bip-0117.mediawiki index b301083f38..4624258946 100644 --- a/bip-0117.mediawiki +++ b/bip-0117.mediawiki @@ -161,7 +161,7 @@ This removes a potentially significant hurdle to deployment by making this featu ==Implementation== -An implementation of this BIP, including both consensus code changes and tests are available at the following Github repository: +An implementation of this BIP, including both consensus code changes and tests are available at the following GitHub repository: [https://github.com/maaku/bitcoin/tree/tail-call-semantics] diff --git a/bip-0433.mediawiki b/bip-0433.mediawiki index 073beb8b97..6f550bab50 100644 --- a/bip-0433.mediawiki +++ b/bip-0433.mediawiki @@ -7,7 +7,7 @@ Type: Informational Assigned: 2025-12-08 License: BSD-3-Clause - Discussion: 2024-06-27: https://github.com/bitcoin/bitcoin/pull/30352 Github PR + Discussion: 2024-06-27: https://github.com/bitcoin/bitcoin/pull/30352 GitHub PR 2024-10-10: https://bitcoinops.org/en/bitcoin-core-28-wallet-integration-guide/ wallet integration guide diff --git a/scripts/link-format-chk.sh b/scripts/link-format-chk.sh index 0c91f46646..16be3387c8 100755 --- a/scripts/link-format-chk.sh +++ b/scripts/link-format-chk.sh @@ -11,7 +11,7 @@ while IFS= read -r fname; do GRES=$(grep -nE '\]\((https?://|\.\./bip-|/bip-)' "$fname") if [ "$GRES" != "" ]; then if [ $ECODE -eq 0 ]; then - >&2 echo "Github Mediawiki format writes links as [URL text], not as [text](URL):" + >&2 echo "GitHub Mediawiki format writes links as [URL text], not as [text](URL):" fi ECODE=1 while IFS= read -r line; do From 6b87d3fc75ec9d8d2998153549122a6289fa48ae Mon Sep 17 00:00:00 2001 From: Jon Atack Date: Fri, 26 Jun 2026 15:58:52 -0600 Subject: [PATCH 4/7] bip52: grammar touchup --- bip-0052.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0052.mediawiki b/bip-0052.mediawiki index d59b6cb34c..300970e0eb 100644 --- a/bip-0052.mediawiki +++ b/bip-0052.mediawiki @@ -287,7 +287,7 @@ PoWx will also be publishing the designs of the current optical miner prototypes == Changelog == * 2026-06-18: -** Updated to Closed after the proposal has not made progress for several years and [https://groups.google.com/g/bitcoindev/c/Vrh7oED9b9Q/m/TrCEKRjNAAAJ attempts to contact the authors] did not succeed. +** Updated to Closed after the proposal had not made progress for several years and [https://groups.google.com/g/bitcoindev/c/Vrh7oED9b9Q/m/TrCEKRjNAAAJ attempts to contact the authors] did not succeed. == Acknowledgments == From 147b7bbf39ea1390e870903acc2783a45d16185b Mon Sep 17 00:00:00 2001 From: MozirDmitriy Date: Thu, 28 Aug 2025 17:19:23 +0300 Subject: [PATCH 5/7] bip18: remove non-existing reference implementation --- bip-0018.mediawiki | 4 ---- 1 file changed, 4 deletions(-) diff --git a/bip-0018.mediawiki b/bip-0018.mediawiki index ae1fc5fa9a..a3156abba8 100644 --- a/bip-0018.mediawiki +++ b/bip-0018.mediawiki @@ -121,10 +121,6 @@ If a majority of hashing power does not support the new validation rules, then r The first two bytes of hashScriptCheck specify the hash algorithm and length used to verify scriptCheck. This BIP only allows Bitcoin's Hash160 algorithm, but leaves open the possibility of a future BIP implementing others. -==Reference Implementation== - -https://github.com/gavinandresen/bitcoin-git/tree/pay_to_script_hash - ==See Also== * The [[bip-0013.mediawiki|Address format for Pay to Script Hash BIP]] From 7c555af789c247a9de9c44219a4e46d2a25d38b1 Mon Sep 17 00:00:00 2001 From: Grace Ujah Date: Thu, 28 May 2026 23:54:18 +0100 Subject: [PATCH 6/7] bip157: typo fix --- bip-0157.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0157.mediawiki b/bip-0157.mediawiki index 8b8d3bac25..7d145fc5af 100644 --- a/bip-0157.mediawiki +++ b/bip-0157.mediawiki @@ -63,7 +63,7 @@ with little risk of detection, which is unacceptable for some applications (such as Lightning Network clients) that must respond to certain on-chain events. Finally, honest nodes servicing BIP 37 light clients may incur significant I/O and CPU resource usage due to maliciously crafted Bloom filters, -creating a denial-of-service (DoS) vector and disincentizing node operators from +creating a denial-of-service (DoS) vector and disincentivizing node operators from supporting the protocolhttps://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki. From ca43ebdc6689372f2219227b7b250c95eeb12d04 Mon Sep 17 00:00:00 2001 From: MozirDmitriy Date: Tue, 4 Nov 2025 15:13:17 +0300 Subject: [PATCH 7/7] bip340: remove unused hash_sha256 helper --- bip-0340/reference.py | 3 --- 1 file changed, 3 deletions(-) diff --git a/bip-0340/reference.py b/bip-0340/reference.py index bf8f16203a..5653ac0575 100644 --- a/bip-0340/reference.py +++ b/bip-0340/reference.py @@ -79,9 +79,6 @@ def lift_x(x: int) -> Optional[Point]: def int_from_bytes(b: bytes) -> int: return int.from_bytes(b, byteorder="big") -def hash_sha256(b: bytes) -> bytes: - return hashlib.sha256(b).digest() - def has_even_y(P: Point) -> bool: assert not is_infinite(P) return y(P) % 2 == 0