From 1fa248506e2bedd7ecf8f04d1784e63147f5c181 Mon Sep 17 00:00:00 2001 From: Hunter Trujillo Date: Fri, 27 Sep 2024 10:05:14 -0600 Subject: [PATCH 01/32] QuBit - P2QRH spending rules - Final draft before submitting upstream to bitcoin/bips --- bip-p2qrh.mediawiki | 240 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 240 insertions(+) create mode 100644 bip-p2qrh.mediawiki diff --git a/bip-p2qrh.mediawiki b/bip-p2qrh.mediawiki new file mode 100644 index 0000000000..c03e13ec28 --- /dev/null +++ b/bip-p2qrh.mediawiki @@ -0,0 +1,240 @@ +
+  BIP: TBD
+  Title: QuBit - P2QRH spending rules
+  Author: Hunter Beast 
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-TBD
+  Status: Draft
+  Type: Standards Track
+  License: BSD-3-Clause
+  Created: 2024-06-08
+
+ +== Introduction == + +=== Abstract === + +This document proposes a new SegWit output type, with spending rules based initially-- but not solely-- upon FALCON signatures. (For more on why, see the Rationale and Security sections.) A constraint is that no hard fork or increase in block size are necessary. This document is inspired by [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP-341], which introduced the design of the P2TR (Taproot) address type using Schnorr signatures. + + +=== Copyright === + +This document is licensed under the 3-clause BSD license. + + +=== Motivation === + +This proposal aims to improve the quantum resistance of bitcoin's signature security should the Discrete Logarithm Problem (DLP) which secures Elliptic Curve Cryptography (ECC) no longer prove to be computationally hard, likely through quantum advantage by Cryptographically-Relevant Quantum Computers (CRQCs). [https://arxiv.org/pdf/quant-ph/0301141 A variant of Shor's algorithm] is believed to be capable of deriving the private key from a public key exponentially faster than classical means. The application of this variant of Shor's algorithm is herein referred to as quantum key decryption. Note that doubling the public key length, such as with a hypothetical secp512k1 curve, would only make deriving the private key twice as hard. The computational complexity of this is investigated further in the paper, [https://pubs.aip.org/avs/aqs/article/4/1/013801/2835275/The-impact-of-hardware-specifications-on-reaching ''The impact of hardware specifications on reaching quantum advantage in the fault tolerant regime'']. + +Mining may one day be vulnerable to disruption by very advanced quantum computers making use of Grover's algorithm. However, Grover's [https://arxiv.org/pdf/1902.02332 scales very poorly] compared to Shor's, requiring 10^40 quantum operations in comparison to 10^8 for running Shor's over ECC. It's for this reason that the primary threat to Bitcoin by quantum computers is to its signature algorithm and not Proof of Work, hence the focus on a new address format. + +The vulnerability of existing bitcoin addresses is investigated in [https://web.archive.org/web/20240715101040/https://www2.deloitte.com/nl/nl/pages/innovatie/artikelen/quantum-computers-and-the-bitcoin-blockchain.html this Deloitte report]. The report estimates that in 2020 approximately 25% of the bitcoin supply is held within addresses vulnerable to quantum attack. + +Ordinarily, when a transaction is signed, the public key can be recovered from the signature. This makes a transaction submitted to the mempool vulnerable to quantum attack until it's mined. One way to mitigate this is to submit the transaction directly to a mining pool, which bypasses the mempool. This process is known as an out-of-band transaction. The mining pool must be trusted not to reveal the key to attackers. + +It is proposed to implement a Pay to Quantum Resistant Hash (P2QRH) address type that relies on a post-quantum cryptographic (PQC) signature algorithm. This new address type protects transactions submitted to the mempool and helps preserve the free market by reducing the need for private, out-of-band mempool transactions. + +The following table is non-exhaustive, but meant to inform the average bitcoin user whether their bitcoin is vulnerable to quantum attack. + +{| +|+ Vulnerable address types +|- +! Address type !! Vulnerable !! Prefix !! Example +|- +| P2PK || Yes || 04 || 0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f8141781e62294721166bf621e73a82cbf2342c858ee +|- +| P2PKH || No || 1 || 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa +|- +| P2WPKH || No || bc1q || bc1qsnh5ktku9ztqeqfr89yrqjd05eh58nah884mku +|- +| P2TR || Yes || bc1p || bc1p92aslsnseq786wxfk3ekra90ds9ku47qttupfjsqmmj4z82xdq4q3rr58u +|} + +It should be noted that Taproot addresses are vulnerable in that they encode a 32-byte x-only public key, from which a full public key can be reconstructed. + +Should quantum advantage manifest, a convention is proposed in spending the full 65-byte P2PK key used by the coinbase output in Block 1 back to itself. It is proposed to call this the [https://mempool.space/address/0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f8141781e62294721166bf621e73a82cbf2342c858ee Canary address]. The reasoning behind this is that this can only be done by Satoshi, and given his absence, this can only be spent by others if there is a significant vulnerability in secp256k1. Should the Canary coins move, that will signal that bitcoin is presently vulnerable. Without the Canary, or an address like it, there may be some doubt as to whether the coins were moved with keys belonging to the original owner. + +As an interesting aside, coinbase outputs to P2PK keys go as far as block 200,000, so it's possible there are between 1-2 million coins that are vulnerable from the first epoch. These coins can be considered "Satoshi's Shield." Any addresses with a balance of less than the original block subsidy of 50 coins can be considered incentive incompatible to capture until all of these are mined. + +It's for this reason that, for those who wish to be prepared for quantum emergency, it is recommended that no more than 50 bitcoin are kept under a single distinct, unused Native SegWit (P2WPKH, "bc1q") address at a time. This is assuming that the attacker is financially-motivated instead of, for example, a nation state looking to break confidence in Bitcoin. Additionally, this assumes that other vulnerable targets such as central banks have upgraded their cryptography already. + +The Commercial National Security Algorithm Suite (CNSA) 2.0 has a timeline for software and networking equipment to be upgraded by 2030, with browsers and operating systems fully upgraded by 2033. + +Lastly, it is worth noting by way of comparison that [https://ethresear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/18901 Vitalik Buterin's proposed solution] in an Ethereum quantum emergency is quite different from the approach in this BIP. His plan involves a hard fork of the chain, reverting all blocks after a sufficient amount of theft, and using STARKs based on BIP-32 seeds to act as the authoritative secret when signing. These measures are deemed far too heavy-handed for bitcoin. + + +=== Rationale === + +This is the first in a series of BIPs under a QuBit soft fork. A qubit is a fundamental unit of quantum computing, and the capital B represents its connection to bitcoin. The name QuBit also rhymes to some extent with SegWit. + +It is proposed to use SegWit version 3. This results in addresses that start with bc1r, which could be a useful way to remember that these are [r]esistant addresses, similar to how bc1q corresponds to Se[q]Wit and bc1p corresponds to Ta[p]root. This is referencing the lookup table under [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32 BIP-173]. + +The proposal above also leaves a gap in case it makes sense to use version 2, or bc1z, for implementation of other address formats such as those that employ Cross Input Signature Aggregation (CISA). + +P2QRH is meant to be implemented on top of P2TR, combining the security of classical Schnorr signatures along with post-quantum cryptography. This is a form of "hybrid cryptography" such that no regression in security is presented should a vulnerability exist in one of the signature algorithms used. One key distinction between P2QRH and P2TR however is that P2QRH will encode a hash of the public key. This is a significant change in how Taproot works, but is necessary to avoid exposing public keys on-chain in advance of attackers. + +P2QRH uses a 32-byte HASH256 (specifically SHA-256 twice-over, which is similar to that used in [https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#specification BIP-16]) of the public key to reduce the size of new outputs and also to increase security by not having the public key available on-chain. This hash serves as a minimal cryptographic commitment to a public key. It goes into the output spend script, which does not receive the witness discount. + +Not having public keys exposed on-chain is an important step for quantum security. Otherwise funds would need to be spent to new addresses on a regular basis in order to prevent the possibility of a "long-range CRQC attack" recovering the key behind high value addresses. A long-range quantum attack can be considered one performed with chain data, such as that from a used address or one encoded in a spend script. A "short-range quantum attack" would be one done on keys in the mempool, which is seen as impractical given transaction throughput and block time. As the value being sent increases, so too should the fee in order to commit the transaction to the chain as soon as possible. This makes useless the public key revealed by spending a UTXO, so long as it is never reused. + +Post-quantum public keys are generally larger than those used by ECC, depending on the security level. To promote user adoption and general user-friendliness, the most secure variant (NIST V, 256 bit) is proposed, despite the increase in key length and verification time. + +Support for FALCON signatures will be introduced first, with the intention of adding SQIsign and other post-quantum algorithms as they are approved. By way of comparison, FALCON signatures are roughly 4x larger than SQIsign signatures and 20x larger than Schnorr signatures. FALCON is a more conservative approach to applied lattice cryptography than SQIsign, and its use has recently been approved by NIST. NIST approval streamlines implementations through establishing consensus in the scientific and developer community. However, even SQIsign signatures are roughly 5x larger than Schnorr signatures. This means, to maintain present transaction throughput, an increase in the witness discount will likely be desired in a QuBit soft fork. That will be specified in a future QuBit BIP. + +An increase in the witness discount must not be taken lightly. It must be resistant to applications that might take advantage of this discount (e.g. storage of arbitrary data as seen with "inscriptions") without a corresponding increase in economic activity. Such an increase would not only impact node runners but those with inscriptions would also have the scarcity of their non-monetary assets affected. The only way to prevent this while also increasing the discount is to have a completely separate witness, a quantum witness, or "quitness," that is solely responsible for providing post-quantum signatures. + +To address the risk of arbitrary data being stored using P2QRH (QuBit) addresses, very specific rules will be applied to spending from the witness stack in SegWit v3 outputs. A fixed signature size will be necessary for spending the output, and the output must be spendable to be considered valid within node consensus. A fixed signature size will also be helpful to disambiguate between signature types without an additional version byte, as SQIsign signatures are substantially smaller than FALCON signatures. Consequently, the correct signature algorithm can be inferred through byte length. The public key and signature will be pushed separately to the quitness stack. Multiple signatures can be included in order to support multisig applications, and also for spending multiple inputs. + +Since only valid signatures can be committed to in a SegWit v3 quitness, arbitrary data cannot be added by miners, as that would affect the consensus of their block. A CRQC operator is economically disincentivized from computing a spendable public key that matched arbitrary signature data due to the cost of that computation. That is because the cost of such a computation could prove quite substantial, rather than simply putting the arbitrary data within a Taproot witness. Doing the work to meet the requirement for it to be consensus-valid data would prove cost-prohibitive. + +Additionally, it should be noted, whether an output with a P2QRH spend script corresponds to a FALCON or SQIsign signature is not known until the output is spent. + +While it might be seen as a maintenance burden for bitcoin ecosystem devs to go from a single cryptosystem implementation to two distinct cryptosystems-- and it most certainly is-- the ramifications of a chain broken through extrinsic factors should provide sufficient motivation. An increase in software maintenance everywhere signatures are used should be seen as an acceptable compromise for maintained integrity of bitcoin transfers during a regime of quantum advantage. + +In the distant future, following the implementation of the P2QRH address format in a QuBit soft fork, there will likely be a need for Pay to Quantum Secure (P2QS) addresses. These will require specialized quantum hardware for signing, while still [https://quantum-journal.org/papers/q-2023-01-19-901/ using public keys that are verifiable via classical means]. Additional follow-on BIPs will be needed to implement P2QS. However, until specialized quantum cryptography hardware is widespread, quantum resistant addresses should be an adequate intermediate solution. + + +== Description == + +We first build up a definition of the signature scheme by going through the design choices. Afterwards, we specify the exact encodings and operations. + + +=== Design === + +For P2QRH descriptors, qrh() should be used. + +> Further specific details to be completed later in the draft process as outlined in [https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki BIP-2] + + +== Security == + +{| +|+ Proposed quantum resistant signature algorithms ordered by largest to smallest signature size, NIST I +|- +! Signature algorithm !! Year first introduced !! Signature size, NIST I !! Public key size, NIST I +|- +| [https://sphincs.org/data/sphincs+-r3.1-specification.pdf SPHINCS+ Rd. 3.1 (FIPS 205 - SLH-DSA)] || 2015 || 7856 bytes || 32 bytes +|- +| [https://pq-crystals.org/dilithium/ CRYSTALS-Dilithium (FIPS 204 - ML-DSA)] || 2017 || 2420 bytes || 1312 bytes +|- +| [https://eprint.iacr.org/2014/457.pdf pqNTRUsign] || 2016 || 702 bytes || 752 bytes +|- +| [https://falcon-sign.info FALCON (FIPS 206 - FN-DSA)] || 2017 || 666 bytes || 897 bytes +|- +| [https://eprint.iacr.org/2022/1155.pdf HAWK] || 2022 || 652 bytes || 1006 bytes +|- +| [https://sqisign.org SQIsign] || 2023 || 177 bytes || 64 bytes +|- +| [https://eprint.iacr.org/2024/760.pdf SQIsign2D-West] || 2024 || 148 bytes || 66 bytes +|- +| [https://link.springer.com/content/pdf/10.1007/978-3-031-58716-0_1.pdf SQIsignHD] || 2024 || 109 bytes || not provided +|} + +{| +|+ Proposed quantum resistant signature algorithms ordered by largest to smallest signature size, NIST V +|- +! Signature algorithm !! Year first introduced !! Signature size, NIST V !! Public key size, NIST V +|- +| Lamport signature || 1977 || 8192 bytes || 16384 bytes +|- +| SPHINCS+ Rd. 3.1 (FIPS 205 - SLH-DSA) || 2015 || 29792 bytes || 64 bytes +|- +| CRYSTALS-Dilithium (FIPS 204 - ML-DSA) || 2017 || 4595 bytes || 2592 bytes +|- +| pqNTRUsign || 2016 || 1814 bytes || 1927 bytes +|- +| FALCON (FIPS 206 - FN-DSA) || 2017 || 1280 bytes || 1793 bytes +|- +| HAWK || 2022 || 1261 bytes || 2329 bytes +|- +| SQIsign || 2023 || 335 bytes || 128 bytes +|- +| SQIsign2D-West || 2024 || 294 bytes || 130 bytes +|- +| SQIsignHD || 2023 || not provided || not provided +|} + +As shown, supersingular elliptic curve quaternion isogeny signature algorithms represent the state of the art in post-quantum cryptography, beyond lattice cryptography alone, especially when key and signature length are major constraints. This makes inclusion of SQIsign attractive, and support is planned, but it will be some time until it is approved for production use. Meanwhile, FALCON signatures are already approved and have achieved broader community consensus. + +In comparison, the size of currently used signature algorithms are: + +* ECDSA - 70-72 bytes +* Schnorr - 64 bytes + +In comparison to year, secp256k1 [https://www.secg.org/SEC1-Ver-1.0.pdf was originally specified in 2000]. + +One consideration for choosing an algorithm is its maturity. secp256k1 was already 8 years old by the time it was chosen as bitcoin's curve. Isogeny cryptography when it was first introduced was broken over a weekend. + +Ideally SQIsign also proves to be flexible enough to support [https://www.pierrickdartois.fr/homepage/wp-content/uploads/2022/04/Report_OSIDH_DARTOIS.pdf Isogeny Diffie-Hellman] to replace ECDH applications, and also provide methods for the key tweaking necessary to support TapScript for P2QR addresses. Additionally, isogeny-based post-quantum cryptography is based on higher-order elliptic curves, and so it might be possible to implement Isogeny Schnorr signatures. + +Signature verification speed as it compares to Schnorr or ECDSA isn't seen as high a consideration as signature size due to block space being the primary fee constraint. As a P2QRH implementation materializes, a benchmark will be added for performance comparison. Fortunately, SQIsign signatures are substantially faster to verify than it is to generate keys or to sign, which is a major consideration when a transaction need only be signed once, or a handful of times with PSBT, compared to being verified simultaneously on tens of thousands of nodes. Key generation may need to cached in [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-32 HD wallets]. + +An additional consideration is security levels. Longer signature sizes provide more security. NIST has standardized five security levels for post-quantum cryptography. NIST security level I provides security equivalent to 128-bit keys, and security level V provides 256-bit security. + + +== Specification == + +How the quitness is differentiated from the witness can be accomplished similar to how [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#user-content-Transaction_ID BIP-141] introduced the marker and flag, with the QuBit flag being set to 0x02. This means all QuBit transactions are also SegWit transactions. The additional data would be included as a second array of byte arrays following the witness stack. + +The new transaction serialization format would be as follows: + + [nVersion][marker][flag][txins][txouts][witness][quitness][nLockTime] + +WIP + +=== Public Key Generation === + +TBD, pending test vectors + +=== Public Key Conversion === + +TBD + +=== Default Signing === + +TBD + +=== Alternative Signing === + +TBD + +=== Verification === + +TBD + +=== Batch Verification === + +TBD + +=== Usage Considerations === + +TBD + +== Test Vectors and Reference Code == + +TBD + + +== References == + +* [https://groups.google.com/g/bitcoindev/c/Aee8xKuIC2s/m/cu6xej1mBQAJ Mailing list discussion] +* [https://delvingbitcoin.org/t/proposing-a-p2qrh-bip-towards-a-quantum-resistant-soft-fork/956?u=cryptoquick Delving Bitcoin discussion] +* [https://bitcoinops.org/en/newsletters/2024/06/14/ Bitcoin OpTech newsletter] +* [https://bitcoinops.org/en/podcast/2024/06/18/#draft-bip-for-quantum-safe-address-format Bitcoin OpTech discussion transcript] + + + + +== Changelog == + +To help implementors understand updates to this BIP, we keep a list of substantial changes. + +* 2024-06: High level rough draft +* 2024-07: Additional algorithms in PQC table +* 2024-08: Add FALCON signatures, update to use NIST standard terminology, add public key sizes. +* 2024-09: Additional detail on P2QS. Deprecate P2QR. Postpone SQIsign. Add details on quitness. + + +== Acknowledgements == + +Much gratitude to my co-founder, Kyle Crews for proofreading and editing, and to David Croisant. who suggested the name "QuBit." Thank you as well to those who took the time to review and contribute, including Adam Borcany, Antoine Riard, and Pierre-Luc Dallaire-Demers. From 6f67a3d6860921bf869404e14239581c139ff69d Mon Sep 17 00:00:00 2001 From: Hunter Trujillo Date: Fri, 27 Sep 2024 10:23:41 -0600 Subject: [PATCH 02/32] Add pqNTRUsign to .typos.toml. --- .typos.toml | 1 + 1 file changed, 1 insertion(+) diff --git a/.typos.toml b/.typos.toml index 15d831fa1e..4f9fbef9af 100644 --- a/.typos.toml +++ b/.typos.toml @@ -15,6 +15,7 @@ extend-ignore-re = [ "ser.*", "prefix.*", "value: .*", + "pqNTRUsign", ] [default.extend-words] From d83c29d59b78443e20a040395ca23777bfc332f1 Mon Sep 17 00:00:00 2001 From: Hunter Trujillo Date: Sat, 28 Sep 2024 11:57:31 -0600 Subject: [PATCH 03/32] QuBit - P2QRH --- bip-p2qrh.mediawiki | 131 +++++++++++++++++++++++++++----------------- 1 file changed, 81 insertions(+), 50 deletions(-) diff --git a/bip-p2qrh.mediawiki b/bip-p2qrh.mediawiki index c03e13ec28..4d94886509 100644 --- a/bip-p2qrh.mediawiki +++ b/bip-p2qrh.mediawiki @@ -26,11 +26,13 @@ This document is licensed under the 3-clause BSD license. This proposal aims to improve the quantum resistance of bitcoin's signature security should the Discrete Logarithm Problem (DLP) which secures Elliptic Curve Cryptography (ECC) no longer prove to be computationally hard, likely through quantum advantage by Cryptographically-Relevant Quantum Computers (CRQCs). [https://arxiv.org/pdf/quant-ph/0301141 A variant of Shor's algorithm] is believed to be capable of deriving the private key from a public key exponentially faster than classical means. The application of this variant of Shor's algorithm is herein referred to as quantum key decryption. Note that doubling the public key length, such as with a hypothetical secp512k1 curve, would only make deriving the private key twice as hard. The computational complexity of this is investigated further in the paper, [https://pubs.aip.org/avs/aqs/article/4/1/013801/2835275/The-impact-of-hardware-specifications-on-reaching ''The impact of hardware specifications on reaching quantum advantage in the fault tolerant regime'']. -Mining may one day be vulnerable to disruption by very advanced quantum computers making use of Grover's algorithm. However, Grover's [https://arxiv.org/pdf/1902.02332 scales very poorly] compared to Shor's, requiring 10^40 quantum operations in comparison to 10^8 for running Shor's over ECC. It's for this reason that the primary threat to Bitcoin by quantum computers is to its signature algorithm and not Proof of Work, hence the focus on a new address format. +The primary threat to Bitcoin by CRQCs is [https://en.bitcoin.it/wiki/Quantum_computing_and_Bitcoin#QC_attacks generally considered to be to its uses of ECC used in signatures and Taproot commitments], hence the focus on a new address format. This is because Shor's algorithm enables a CRQC to break the cryptographic assumptions of ECC in roughly 10^8 quantum operations. While a CRQC could use [https://en.wikipedia.org/wiki/Grover's_algorithm Grover's algorithm] to gain a quadratic speed up on brute force attacks on the hash functions used in Bitcoin, a significantly more powerful CRQC is needed for these attacks to meaningfully impact Bitcoin. For instance, a preimage attack on HASH160used by P2PKH, P2SH, and P2WPKH addresses, though not P2WSH because it uses 256-bit hashes using Grover's algorithm would require at least 10^24 quantum operations. As for Grover's application to mining, see [https://quantumcomputing.stackexchange.com/a/12847 Sam Jaques post on this]. -The vulnerability of existing bitcoin addresses is investigated in [https://web.archive.org/web/20240715101040/https://www2.deloitte.com/nl/nl/pages/innovatie/artikelen/quantum-computers-and-the-bitcoin-blockchain.html this Deloitte report]. The report estimates that in 2020 approximately 25% of the bitcoin supply is held within addresses vulnerable to quantum attack. +The vulnerability of existing bitcoin addresses is investigated in [https://web.archive.org/web/20240715101040/https://www2.deloitte.com/nl/nl/pages/innovatie/artikelen/quantum-computers-and-the-bitcoin-blockchain.html this Deloitte report]. The report estimates that in 2020 approximately 25% of the bitcoin supply is held within addresses vulnerable to quantum attack. As of the time of writing, that number is now closer to 20%. Additionally, Peter Wuille estimates even more might be vulnerable, for the reasons provided [https://x.com/pwuille/status/1108085284862713856 here]. -Ordinarily, when a transaction is signed, the public key can be recovered from the signature. This makes a transaction submitted to the mempool vulnerable to quantum attack until it's mined. One way to mitigate this is to submit the transaction directly to a mining pool, which bypasses the mempool. This process is known as an out-of-band transaction. The mining pool must be trusted not to reveal the key to attackers. +Ordinarily, when a transaction is signed, the public key can be recovered from the signature. This makes a transaction submitted to the mempool vulnerable to quantum attack until it's mined. One way to mitigate this is to submit the transaction directly to a mining pool, which bypasses the mempool. This process is known as an out-of-band transaction. The mining pool must be trusted not to reveal the transaction public key to attackers. + +Not having public keys exposed on-chain is an important step for quantum security. Otherwise funds would need to be spent to new addresses on a regular basis in order to prevent the possibility of a "long-range CRQC attack" recovering the key behind high value addresses. A long-range quantum attack can be considered one performed with chain data, such as that from a used address or one encoded in a spend script. A "short-range quantum attack" would be one done on keys in the mempool, which is seen as impractical given transaction throughput and block time. As the value being sent increases, so too should the fee in order to commit the transaction to the chain as soon as possible. This makes useless the public key revealed by spending a UTXO, so long as it is never reused. It is proposed to implement a Pay to Quantum Resistant Hash (P2QRH) address type that relies on a post-quantum cryptographic (PQC) signature algorithm. This new address type protects transactions submitted to the mempool and helps preserve the free market by reducing the need for private, out-of-band mempool transactions. @@ -52,6 +54,28 @@ The following table is non-exhaustive, but meant to inform the average bitcoin u It should be noted that Taproot addresses are vulnerable in that they encode a 32-byte x-only public key, from which a full public key can be reconstructed. +If a key is recovered by a CRQC, it can also be trivially checked to see if any child keys were produced using an unhardened [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-32] derivation path. + +The following table summarizes the scenarios in which public keys are revealed when using Bitcoin, and what type of attack they're vulnerable to: + +{| +|+ Scenarios for revealed public keys on Bitcoin +|- +! Scenario !! Type of attack +|- +| Early addresses (Satoshi's coins, CPU miners, starts with 04) || Long-range +|- +| Reused addresses (any type, except bc1r) || Long-range +|- +| Taproot addresses (starts with bc1p) || Long-range +|- +| Any transaction in the mempool (except for bc1r) || Short-range +|- +| Unhardened BIP-32 HD wallet keys || Both Long-range or Short-range +|} + +The only time a short-range attack can occur is when the transaction is in the mempool, whereas long-range attacks are when the public key is known well in advance. Short-range attacks require much larger, more expensive CRQCs. + Should quantum advantage manifest, a convention is proposed in spending the full 65-byte P2PK key used by the coinbase output in Block 1 back to itself. It is proposed to call this the [https://mempool.space/address/0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f8141781e62294721166bf621e73a82cbf2342c858ee Canary address]. The reasoning behind this is that this can only be done by Satoshi, and given his absence, this can only be spent by others if there is a significant vulnerability in secp256k1. Should the Canary coins move, that will signal that bitcoin is presently vulnerable. Without the Canary, or an address like it, there may be some doubt as to whether the coins were moved with keys belonging to the original owner. As an interesting aside, coinbase outputs to P2PK keys go as far as block 200,000, so it's possible there are between 1-2 million coins that are vulnerable from the first epoch. These coins can be considered "Satoshi's Shield." Any addresses with a balance of less than the original block subsidy of 50 coins can be considered incentive incompatible to capture until all of these are mined. @@ -75,21 +99,21 @@ P2QRH is meant to be implemented on top of P2TR, combining the security of class P2QRH uses a 32-byte HASH256 (specifically SHA-256 twice-over, which is similar to that used in [https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#specification BIP-16]) of the public key to reduce the size of new outputs and also to increase security by not having the public key available on-chain. This hash serves as a minimal cryptographic commitment to a public key. It goes into the output spend script, which does not receive the witness discount. -Not having public keys exposed on-chain is an important step for quantum security. Otherwise funds would need to be spent to new addresses on a regular basis in order to prevent the possibility of a "long-range CRQC attack" recovering the key behind high value addresses. A long-range quantum attack can be considered one performed with chain data, such as that from a used address or one encoded in a spend script. A "short-range quantum attack" would be one done on keys in the mempool, which is seen as impractical given transaction throughput and block time. As the value being sent increases, so too should the fee in order to commit the transaction to the chain as soon as possible. This makes useless the public key revealed by spending a UTXO, so long as it is never reused. - Post-quantum public keys are generally larger than those used by ECC, depending on the security level. To promote user adoption and general user-friendliness, the most secure variant (NIST V, 256 bit) is proposed, despite the increase in key length and verification time. Support for FALCON signatures will be introduced first, with the intention of adding SQIsign and other post-quantum algorithms as they are approved. By way of comparison, FALCON signatures are roughly 4x larger than SQIsign signatures and 20x larger than Schnorr signatures. FALCON is a more conservative approach to applied lattice cryptography than SQIsign, and its use has recently been approved by NIST. NIST approval streamlines implementations through establishing consensus in the scientific and developer community. However, even SQIsign signatures are roughly 5x larger than Schnorr signatures. This means, to maintain present transaction throughput, an increase in the witness discount will likely be desired in a QuBit soft fork. That will be specified in a future QuBit BIP. -An increase in the witness discount must not be taken lightly. It must be resistant to applications that might take advantage of this discount (e.g. storage of arbitrary data as seen with "inscriptions") without a corresponding increase in economic activity. Such an increase would not only impact node runners but those with inscriptions would also have the scarcity of their non-monetary assets affected. The only way to prevent this while also increasing the discount is to have a completely separate witness, a quantum witness, or "quitness," that is solely responsible for providing post-quantum signatures. +An increase in the witness discount must not be taken lightly. It must be resistant to applications that might take advantage of this discount (e.g. storage of arbitrary data as seen with "inscriptions") without a corresponding increase in economic activity. Such an increase would not only impact node runners but those with inscriptions would also have the scarcity of their non-monetary assets affected. The only way to prevent this while also increasing the discount is to have a completely separate witness, a "quantum witness". Because it is meant only for public keys and signatures, we call this section of the transaction the attestation. -To address the risk of arbitrary data being stored using P2QRH (QuBit) addresses, very specific rules will be applied to spending from the witness stack in SegWit v3 outputs. A fixed signature size will be necessary for spending the output, and the output must be spendable to be considered valid within node consensus. A fixed signature size will also be helpful to disambiguate between signature types without an additional version byte, as SQIsign signatures are substantially smaller than FALCON signatures. Consequently, the correct signature algorithm can be inferred through byte length. The public key and signature will be pushed separately to the quitness stack. Multiple signatures can be included in order to support multisig applications, and also for spending multiple inputs. +To address the risk of arbitrary data being stored using P2QRH (QuBit) addresses, very specific rules will be applied to spending from the witness stack in SegWit v3 outputs. A fixed signature size will be necessary for spending the output, and the output must be spendable to be considered valid within node consensus. A fixed signature size will also be helpful to disambiguate between signature types without an additional version byte, as SQIsign signatures are substantially smaller than FALCON signatures. Consequently, the correct signature algorithm can be inferred through byte length. The public key and signature will be pushed separately to the attestation stack. Multiple signatures can be included in order to support multisig applications, and also for spending multiple inputs. -Since only valid signatures can be committed to in a SegWit v3 quitness, arbitrary data cannot be added by miners, as that would affect the consensus of their block. A CRQC operator is economically disincentivized from computing a spendable public key that matched arbitrary signature data due to the cost of that computation. That is because the cost of such a computation could prove quite substantial, rather than simply putting the arbitrary data within a Taproot witness. Doing the work to meet the requirement for it to be consensus-valid data would prove cost-prohibitive. +Since only valid signatures can be committed to in a SegWit v3 attestation, arbitrary data cannot be added by miners, as that would affect the consensus of their block. A CRQC operator is economically disincentivized from computing a spendable public key that matched arbitrary signature data due to the cost of that computation. That is because the cost of such a computation could prove quite substantial, rather than simply putting the arbitrary data within a Taproot witness. Doing the work to meet the requirement for it to be consensus-valid data would prove cost-prohibitive. Additionally, it should be noted, whether an output with a P2QRH spend script corresponds to a FALCON or SQIsign signature is not known until the output is spent. -While it might be seen as a maintenance burden for bitcoin ecosystem devs to go from a single cryptosystem implementation to two distinct cryptosystems-- and it most certainly is-- the ramifications of a chain broken through extrinsic factors should provide sufficient motivation. An increase in software maintenance everywhere signatures are used should be seen as an acceptable compromise for maintained integrity of bitcoin transfers during a regime of quantum advantage. +While it might be seen as a maintenance burden for bitcoin ecosystem devs to go from a single cryptosystem implementation to four additional distinct PQC cryptosystems-- and it most certainly is-- the ramifications of a chain broken through extrinsic factors should provide sufficient motivation. An increase in software maintenance everywhere signatures are used should be seen as an acceptable compromise for maintained integrity of bitcoin transfers during a regime of quantum advantage. + +The inclusion of these four cryptosystems: SPHINCS, XMSS, FALCON, and SQIsign have various advocates within the community due to their varying security assumptions. Hash-based cryptosystems are more conservative, time-tested, and well-reviewed. Lattice cryptography is relatively new and introduces novel security assumptions to Bitcoin, but their signatures are smaller and might be considered by some to be an adequate alternative to Hash-based signatures. SQIsign is much smaller, however, it is based on a very novel form of cryptography known as supersingular elliptic curve quaternion isogeny, and at the time of writing, is not yet approved by NIST or the broader PQC community. In the distant future, following the implementation of the P2QRH address format in a QuBit soft fork, there will likely be a need for Pay to Quantum Secure (P2QS) addresses. These will require specialized quantum hardware for signing, while still [https://quantum-journal.org/papers/q-2023-01-19-901/ using public keys that are verifiable via classical means]. Additional follow-on BIPs will be needed to implement P2QS. However, until specialized quantum cryptography hardware is widespread, quantum resistant addresses should be an adequate intermediate solution. @@ -109,51 +133,35 @@ For P2QRH descriptors, qrh() should be used. == Security == {| -|+ Proposed quantum resistant signature algorithms ordered by largest to smallest signature size, NIST I +|+ Proposed quantum resistant signature algorithms ordered by largest to smallest NIST V signature size |- -! Signature algorithm !! Year first introduced !! Signature size, NIST I !! Public key size, NIST I +! Signature Algorithm !! Year First Introduced !! Signature Size !! Public Key Size || Cryptographic Assumptions |- -| [https://sphincs.org/data/sphincs+-r3.1-specification.pdf SPHINCS+ Rd. 3.1 (FIPS 205 - SLH-DSA)] || 2015 || 7856 bytes || 32 bytes +| [https://en.wikipedia.org/wiki/Lamport_signature Lamport signature] || 1977 || 8192 bytes || 16384 bytes || Hash-based cryptography |- -| [https://pq-crystals.org/dilithium/ CRYSTALS-Dilithium (FIPS 204 - ML-DSA)] || 2017 || 2420 bytes || 1312 bytes +| [https://eprint.iacr.org/2011/191.pdf Winternitz signature] || 1982 || 2368 bytes* || 2368 bytesFootnote: Winternitz signatures are much smaller than Lamport signatures due to efficient chunking, but computation is much higher, especially with high values for w. Winternitz values are for w of 4. || Hash-based cryptography |- -| [https://eprint.iacr.org/2014/457.pdf pqNTRUsign] || 2016 || 702 bytes || 752 bytes +| [https://sphincs.org/data/sphincs+-r3.1-specification.pdf SPHINCS+ Rd. 3.1 (FIPS 205 - SLH-DSA)] || 2015 || 29792 bytes || 64 bytes || Hash-based cryptography |- -| [https://falcon-sign.info FALCON (FIPS 206 - FN-DSA)] || 2017 || 666 bytes || 897 bytes +| [https://eprint.iacr.org/2011/484.pdf XMSS]XMSS, which is based on Winternitz, uses a value of 108 for its most compact signature size, with only a 4.6x (2.34/0.51) increase in verification time. Signing and key generation are not considered a significant factor because they are not distributed throughout the entire Bitcoin network, which take place only inside of wallets one time. || 2011 || 15384 bytes || 13568 bytes || Hash-based cryptography (Winternitz OTS) |- -| [https://eprint.iacr.org/2022/1155.pdf HAWK] || 2022 || 652 bytes || 1006 bytes +| [https://pq-crystals.org/dilithium/ CRYSTALS-Dilithium (FIPS 204 - ML-DSA)] || 2017 || 4595 bytes || 2592 bytes || Lattice cryptography |- -| [https://sqisign.org SQIsign] || 2023 || 177 bytes || 64 bytes +| [https://eprint.iacr.org/2014/457.pdf pqNTRUsign] || 2016 || 1814 bytes || 1927 bytes || Lattice cryptography (NTRU) |- -| [https://eprint.iacr.org/2024/760.pdf SQIsign2D-West] || 2024 || 148 bytes || 66 bytes +| [https://falcon-sign.info FALCON (FIPS 206 - FN-DSA)] || 2017 || 1280 bytes || 1793 bytes || Lattice cryptography (NTRU) |- -| [https://link.springer.com/content/pdf/10.1007/978-3-031-58716-0_1.pdf SQIsignHD] || 2024 || 109 bytes || not provided -|} - -{| -|+ Proposed quantum resistant signature algorithms ordered by largest to smallest signature size, NIST V +| [https://eprint.iacr.org/2022/1155.pdf HAWK] || 2022 || 1261 bytes || 2329 bytes || Lattice cryptography |- -! Signature algorithm !! Year first introduced !! Signature size, NIST V !! Public key size, NIST V +| [https://sqisign.org SQIsign] || 2023 || 335 bytes || 128 bytes || Supersingular Elliptic Curve Isogeny |- -| Lamport signature || 1977 || 8192 bytes || 16384 bytes +| [https://eprint.iacr.org/2024/760.pdf SQIsign2D-West] || 2024 || 294 bytes || 130 bytes || Supersingular Elliptic Curve Isogeny |- -| SPHINCS+ Rd. 3.1 (FIPS 205 - SLH-DSA) || 2015 || 29792 bytes || 64 bytes -|- -| CRYSTALS-Dilithium (FIPS 204 - ML-DSA) || 2017 || 4595 bytes || 2592 bytes -|- -| pqNTRUsign || 2016 || 1814 bytes || 1927 bytes -|- -| FALCON (FIPS 206 - FN-DSA) || 2017 || 1280 bytes || 1793 bytes -|- -| HAWK || 2022 || 1261 bytes || 2329 bytes -|- -| SQIsign || 2023 || 335 bytes || 128 bytes -|- -| SQIsign2D-West || 2024 || 294 bytes || 130 bytes -|- -| SQIsignHD || 2023 || not provided || not provided +| [https://eprint.iacr.org/2023/436.pdf SQIsignHD] || 2023 || 109 butes (NIST I) || not provided || Supersingular Elliptic Curve Isogeny |} + + As shown, supersingular elliptic curve quaternion isogeny signature algorithms represent the state of the art in post-quantum cryptography, beyond lattice cryptography alone, especially when key and signature length are major constraints. This makes inclusion of SQIsign attractive, and support is planned, but it will be some time until it is approved for production use. Meanwhile, FALCON signatures are already approved and have achieved broader community consensus. In comparison, the size of currently used signature algorithms are: @@ -167,20 +175,40 @@ One consideration for choosing an algorithm is its maturity. secp256k1 was alrea Ideally SQIsign also proves to be flexible enough to support [https://www.pierrickdartois.fr/homepage/wp-content/uploads/2022/04/Report_OSIDH_DARTOIS.pdf Isogeny Diffie-Hellman] to replace ECDH applications, and also provide methods for the key tweaking necessary to support TapScript for P2QR addresses. Additionally, isogeny-based post-quantum cryptography is based on higher-order elliptic curves, and so it might be possible to implement Isogeny Schnorr signatures. -Signature verification speed as it compares to Schnorr or ECDSA isn't seen as high a consideration as signature size due to block space being the primary fee constraint. As a P2QRH implementation materializes, a benchmark will be added for performance comparison. Fortunately, SQIsign signatures are substantially faster to verify than it is to generate keys or to sign, which is a major consideration when a transaction need only be signed once, or a handful of times with PSBT, compared to being verified simultaneously on tens of thousands of nodes. Key generation may need to cached in [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-32 HD wallets]. +Signature verification speed as it compares to Schnorr or ECDSA isn't seen as high a consideration as signature size due to block space being the primary fee constraint. As a P2QRH implementation materializes, a benchmark will be added for performance comparison. Fortunately, SQIsign signatures are substantially faster to verify than it is to generate keys or to sign, which is a major consideration when a transaction need only be signed once, or a handful of times with PSBT, compared to being verified simultaneously on tens of thousands of nodes. Key generation may need to cached in BIP-32 Hierarchical Deterministic wallets. An additional consideration is security levels. Longer signature sizes provide more security. NIST has standardized five security levels for post-quantum cryptography. NIST security level I provides security equivalent to 128-bit keys, and security level V provides 256-bit security. == Specification == -How the quitness is differentiated from the witness can be accomplished similar to how [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#user-content-Transaction_ID BIP-141] introduced the marker and flag, with the QuBit flag being set to 0x02. This means all QuBit transactions are also SegWit transactions. The additional data would be included as a second array of byte arrays following the witness stack. +How the attestation is differentiated from the witness can be accomplished similar to how [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#user-content-Transaction_ID BIP-141] introduced the marker and flag, with the QuBit flag being set to 0x02. This means all QuBit transactions are also SegWit transactions. The additional data would be included as a second array of byte arrays following the witness stack. + +The new transaction serialization format is as follows: -The new transaction serialization format would be as follows: + [nVersion][marker][flag][txins][txouts][witness][attestation][nLockTime] - [nVersion][marker][flag][txins][txouts][witness][quitness][nLockTime] +QuBit spend scripts are as follows: + +* OP_PUSHNUM_3 to indicate SegWit version 3 +* OP_PUSHBYTES_32 +* HASH256 of the following bytes concatenated: + * HASH256 of the public key at attestation index 0 + * If there are more public keys: + * All public keys are hashed via HASH256 and concatenated + +In short, the new spend script serialization format is as follows: + + OP_PUSHNUM_3 HASH256([HASH256(Public Key Bytes at Attestation Index 0)][HASH256(PK Q1)][..]) + +Addresses then encode this script using bech32m. + +32-byte attestation fields are assumed to be Schnorr public keys for Taproot fields, because they are ordinarily included in the spend script, but cannot be included in P2QRH for security reasons. Public key / signature pairs for Taproot fields come before QuBit public key / signature pairs. + +Which key type is inferred by its size, as provided by the attestation varint pair, determining whether it's processed as secp256k1 Schnorr, SPHINCS, XMSS, FALCON, and SQIsign. + +If the transaction fails to include the public keys needed to match the spend script hash, it is an invalid transaction, because the cryptographic commitment for the keys has not been met. Because of this, only valid public keys and signatures can be included within the attestation, and no other data. -WIP === Public Key Generation === @@ -222,6 +250,9 @@ TBD * [https://bitcoinops.org/en/newsletters/2024/06/14/ Bitcoin OpTech newsletter] * [https://bitcoinops.org/en/podcast/2024/06/18/#draft-bip-for-quantum-safe-address-format Bitcoin OpTech discussion transcript] + +== Footnotes == + @@ -229,12 +260,12 @@ TBD To help implementors understand updates to this BIP, we keep a list of substantial changes. -* 2024-06: High level rough draft -* 2024-07: Additional algorithms in PQC table -* 2024-08: Add FALCON signatures, update to use NIST standard terminology, add public key sizes. -* 2024-09: Additional detail on P2QS. Deprecate P2QR. Postpone SQIsign. Add details on quitness. +* 2024-09-30 - Refactor the ECC vs PoW section. Swap quitness for attestation. +* 2024-09-29 - Update section on PoW to include partial-preimage. +* 2024-09-28 - Add Winternitz, XMSS signatures, and security assumption types to PQC table. Omit NIST I table. Add spend script specification. Add revealed public key scenario table. +* 2024-09-27 - Initial draft proposal == Acknowledgements == -Much gratitude to my co-founder, Kyle Crews for proofreading and editing, and to David Croisant. who suggested the name "QuBit." Thank you as well to those who took the time to review and contribute, including Adam Borcany, Antoine Riard, and Pierre-Luc Dallaire-Demers. +Much gratitude to my co-founder, Kyle Crews for proofreading and editing, to David Croisant, who suggested the name "QuBit", and Guy Swann for pointing out the earlier name for the attestation, "quitness", was imperfect. Thank you as well to those who took the time to review and contribute, including Adam Borcany, Antoine Riard, Pierre-Luc Dallaire-Demers, Ethan Heilman, and Jon Atack. From ae0936ae6f46fa12301b523c9b26dd4af9769f31 Mon Sep 17 00:00:00 2001 From: Jameson Lopp Date: Wed, 2 Oct 2024 10:30:43 -0400 Subject: [PATCH 04/32] typo fix --- bip-p2qrh.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-p2qrh.mediawiki b/bip-p2qrh.mediawiki index 4d94886509..211d1c4746 100644 --- a/bip-p2qrh.mediawiki +++ b/bip-p2qrh.mediawiki @@ -157,7 +157,7 @@ For P2QRH descriptors, qrh() should be used. |- | [https://eprint.iacr.org/2024/760.pdf SQIsign2D-West] || 2024 || 294 bytes || 130 bytes || Supersingular Elliptic Curve Isogeny |- -| [https://eprint.iacr.org/2023/436.pdf SQIsignHD] || 2023 || 109 butes (NIST I) || not provided || Supersingular Elliptic Curve Isogeny +| [https://eprint.iacr.org/2023/436.pdf SQIsignHD] || 2023 || 109 bytes (NIST I) || not provided || Supersingular Elliptic Curve Isogeny |} From b4c329b55b9205f78a6896ed0627228cb5baafbd Mon Sep 17 00:00:00 2001 From: Hunter Trujillo Date: Mon, 21 Oct 2024 10:01:30 -0600 Subject: [PATCH 05/32] QuBit - P2QRH spending rules --- bip-p2qrh.mediawiki | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/bip-p2qrh.mediawiki b/bip-p2qrh.mediawiki index 211d1c4746..85c72e2f6b 100644 --- a/bip-p2qrh.mediawiki +++ b/bip-p2qrh.mediawiki @@ -113,7 +113,7 @@ Additionally, it should be noted, whether an output with a P2QRH spend script co While it might be seen as a maintenance burden for bitcoin ecosystem devs to go from a single cryptosystem implementation to four additional distinct PQC cryptosystems-- and it most certainly is-- the ramifications of a chain broken through extrinsic factors should provide sufficient motivation. An increase in software maintenance everywhere signatures are used should be seen as an acceptable compromise for maintained integrity of bitcoin transfers during a regime of quantum advantage. -The inclusion of these four cryptosystems: SPHINCS, XMSS, FALCON, and SQIsign have various advocates within the community due to their varying security assumptions. Hash-based cryptosystems are more conservative, time-tested, and well-reviewed. Lattice cryptography is relatively new and introduces novel security assumptions to Bitcoin, but their signatures are smaller and might be considered by some to be an adequate alternative to Hash-based signatures. SQIsign is much smaller, however, it is based on a very novel form of cryptography known as supersingular elliptic curve quaternion isogeny, and at the time of writing, is not yet approved by NIST or the broader PQC community. +The inclusion of these four cryptosystems: SPHINCS, CRYSTALS-Dilithium, FALCON, and SQIsign have various advocates within the community due to their varying security assumptions. Hash-based cryptosystems are more conservative, time-tested, and well-reviewed. Lattice cryptography is relatively new and introduces novel security assumptions to Bitcoin, but their signatures are smaller and might be considered by some to be an adequate alternative to Hash-based signatures. SQIsign is much smaller, however, it is based on a very novel form of cryptography known as supersingular elliptic curve quaternion isogeny, and at the time of writing, is not yet approved by NIST or the broader PQC community. In the distant future, following the implementation of the P2QRH address format in a QuBit soft fork, there will likely be a need for Pay to Quantum Secure (P2QS) addresses. These will require specialized quantum hardware for signing, while still [https://quantum-journal.org/papers/q-2023-01-19-901/ using public keys that are verifiable via classical means]. Additional follow-on BIPs will be needed to implement P2QS. However, until specialized quantum cryptography hardware is widespread, quantum resistant addresses should be an adequate intermediate solution. @@ -260,6 +260,7 @@ TBD To help implementors understand updates to this BIP, we keep a list of substantial changes. +* 2024-10-21 - Replace XMSS with CRYSTALS-Dilithium due to NIST approval and size constraints. * 2024-09-30 - Refactor the ECC vs PoW section. Swap quitness for attestation. * 2024-09-29 - Update section on PoW to include partial-preimage. * 2024-09-28 - Add Winternitz, XMSS signatures, and security assumption types to PQC table. Omit NIST I table. Add spend script specification. Add revealed public key scenario table. @@ -268,4 +269,4 @@ To help implementors understand updates to this BIP, we keep a list of substanti == Acknowledgements == -Much gratitude to my co-founder, Kyle Crews for proofreading and editing, to David Croisant, who suggested the name "QuBit", and Guy Swann for pointing out the earlier name for the attestation, "quitness", was imperfect. Thank you as well to those who took the time to review and contribute, including Adam Borcany, Antoine Riard, Pierre-Luc Dallaire-Demers, Ethan Heilman, and Jon Atack. +Much gratitude to my co-founder, Kyle Crews for proofreading and editing, to David Croisant, who suggested the name "QuBit", and Guy Swann for pointing out the earlier name for the attestation, "quitness", was imperfect. Thank you as well to those who took the time to review and contribute, including Adam Borcany, Antoine Riard, Pierre-Luc Dallaire-Demers, Ethan Heilman, Jon Atack, and Jameson Lopp. From 53d497e376f499c210bce4980e28d8f503b9a2b9 Mon Sep 17 00:00:00 2001 From: Kyle Crews Date: Tue, 5 Nov 2024 09:12:26 -0600 Subject: [PATCH 06/32] Adds clarity and brevity --- bip-p2qrh.mediawiki | 44 ++++++++++++++++++++++---------------------- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/bip-p2qrh.mediawiki b/bip-p2qrh.mediawiki index 85c72e2f6b..b332e77250 100644 --- a/bip-p2qrh.mediawiki +++ b/bip-p2qrh.mediawiki @@ -14,7 +14,7 @@ === Abstract === -This document proposes a new SegWit output type, with spending rules based initially-- but not solely-- upon FALCON signatures. (For more on why, see the Rationale and Security sections.) A constraint is that no hard fork or increase in block size are necessary. This document is inspired by [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP-341], which introduced the design of the P2TR (Taproot) address type using Schnorr signatures. +This document proposes a new SegWit output type, with spending rules based initially-- but not solely-- upon FALCON signatures. (For more on why, see the Rationale and Security sections.) A constraint is that no hard fork or increase in block size is necessary. This document is inspired by [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP-341], which introduced the design of the P2TR (Taproot) address type using Schnorr signatures. === Copyright === @@ -26,17 +26,17 @@ This document is licensed under the 3-clause BSD license. This proposal aims to improve the quantum resistance of bitcoin's signature security should the Discrete Logarithm Problem (DLP) which secures Elliptic Curve Cryptography (ECC) no longer prove to be computationally hard, likely through quantum advantage by Cryptographically-Relevant Quantum Computers (CRQCs). [https://arxiv.org/pdf/quant-ph/0301141 A variant of Shor's algorithm] is believed to be capable of deriving the private key from a public key exponentially faster than classical means. The application of this variant of Shor's algorithm is herein referred to as quantum key decryption. Note that doubling the public key length, such as with a hypothetical secp512k1 curve, would only make deriving the private key twice as hard. The computational complexity of this is investigated further in the paper, [https://pubs.aip.org/avs/aqs/article/4/1/013801/2835275/The-impact-of-hardware-specifications-on-reaching ''The impact of hardware specifications on reaching quantum advantage in the fault tolerant regime'']. -The primary threat to Bitcoin by CRQCs is [https://en.bitcoin.it/wiki/Quantum_computing_and_Bitcoin#QC_attacks generally considered to be to its uses of ECC used in signatures and Taproot commitments], hence the focus on a new address format. This is because Shor's algorithm enables a CRQC to break the cryptographic assumptions of ECC in roughly 10^8 quantum operations. While a CRQC could use [https://en.wikipedia.org/wiki/Grover's_algorithm Grover's algorithm] to gain a quadratic speed up on brute force attacks on the hash functions used in Bitcoin, a significantly more powerful CRQC is needed for these attacks to meaningfully impact Bitcoin. For instance, a preimage attack on HASH160used by P2PKH, P2SH, and P2WPKH addresses, though not P2WSH because it uses 256-bit hashes using Grover's algorithm would require at least 10^24 quantum operations. As for Grover's application to mining, see [https://quantumcomputing.stackexchange.com/a/12847 Sam Jaques post on this]. +The primary threat to Bitcoin by CRQCs is [https://en.bitcoin.it/wiki/Quantum_computing_and_Bitcoin#QC_attacks generally considered to be to its breaking of ECC used in signatures and Taproot commitments], hence the focus on a new address format. This is because Shor's algorithm enables a CRQC to break the cryptographic assumptions of ECC in roughly 10^8 quantum operations. While a CRQC could use [https://en.wikipedia.org/wiki/Grover's_algorithm Grover's algorithm] to gain a quadratic speed up on brute force attacks on the hash functions used in Bitcoin, a significantly more powerful CRQC is needed for these attacks to meaningfully impact Bitcoin. For instance, a preimage attack on HASH160used by P2PKH, P2SH, and P2WPKH addresses, though not P2WSH because it uses 256-bit hashes using Grover's algorithm would require at least 10^24 quantum operations. As for Grover's application to mining, see [https://quantumcomputing.stackexchange.com/a/12847 Sam Jaques post on this]. -The vulnerability of existing bitcoin addresses is investigated in [https://web.archive.org/web/20240715101040/https://www2.deloitte.com/nl/nl/pages/innovatie/artikelen/quantum-computers-and-the-bitcoin-blockchain.html this Deloitte report]. The report estimates that in 2020 approximately 25% of the bitcoin supply is held within addresses vulnerable to quantum attack. As of the time of writing, that number is now closer to 20%. Additionally, Peter Wuille estimates even more might be vulnerable, for the reasons provided [https://x.com/pwuille/status/1108085284862713856 here]. +The vulnerability of existing bitcoin addresses is investigated in [https://web.archive.org/web/20240715101040/https://www2.deloitte.com/nl/nl/pages/innovatie/artikelen/quantum-computers-and-the-bitcoin-blockchain.html this Deloitte report]. The report estimates that in 2020 approximately 25% of the bitcoin supply is held within addresses vulnerable to quantum attack. As of the time of writing, that number is now closer to 20%. Additionally, cryptographer Peter Wuille estimates even more might be vulnerable, for the reasons provided [https://x.com/pwuille/status/1108085284862713856 here]. Ordinarily, when a transaction is signed, the public key can be recovered from the signature. This makes a transaction submitted to the mempool vulnerable to quantum attack until it's mined. One way to mitigate this is to submit the transaction directly to a mining pool, which bypasses the mempool. This process is known as an out-of-band transaction. The mining pool must be trusted not to reveal the transaction public key to attackers. -Not having public keys exposed on-chain is an important step for quantum security. Otherwise funds would need to be spent to new addresses on a regular basis in order to prevent the possibility of a "long-range CRQC attack" recovering the key behind high value addresses. A long-range quantum attack can be considered one performed with chain data, such as that from a used address or one encoded in a spend script. A "short-range quantum attack" would be one done on keys in the mempool, which is seen as impractical given transaction throughput and block time. As the value being sent increases, so too should the fee in order to commit the transaction to the chain as soon as possible. This makes useless the public key revealed by spending a UTXO, so long as it is never reused. +Not having public keys exposed on-chain is an important step for quantum security. Otherwise funds would need to be spent to new addresses on a regular basis in order to prevent the possibility of a "long-range CRQC attack" recovering the key behind high value addresses. A long-range quantum attack can be considered one performed with chain data, such as that from a used address or one encoded in a spend script. A "short-range quantum attack" would be one performed on keys in the mempool, which is seen as impractical given transaction throughput and block time. As the value being sent increases, so too should the fee in order to commit the transaction to the chain as soon as possible. This makes useless the public key revealed by spending a UTXO, so long as it is never reused. -It is proposed to implement a Pay to Quantum Resistant Hash (P2QRH) address type that relies on a post-quantum cryptographic (PQC) signature algorithm. This new address type protects transactions submitted to the mempool and helps preserve the free market by reducing the need for private, out-of-band mempool transactions. +It is proposed to implement a Pay to Quantum Resistant Hash (P2QRH) address type that relies on a Post-Quantum Cryptographic (PQC) signature algorithm. This new address type protects transactions submitted to the mempool and helps preserve the free market by reducing the need for private, out-of-band mempool transactions. -The following table is non-exhaustive, but meant to inform the average bitcoin user whether their bitcoin is vulnerable to quantum attack. +The following table is non-exhaustive but intended to inform the average bitcoin user whether their bitcoin is vulnerable to quantum attack. {| |+ Vulnerable address types @@ -54,9 +54,9 @@ The following table is non-exhaustive, but meant to inform the average bitcoin u It should be noted that Taproot addresses are vulnerable in that they encode a 32-byte x-only public key, from which a full public key can be reconstructed. -If a key is recovered by a CRQC, it can also be trivially checked to see if any child keys were produced using an unhardened [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-32] derivation path. +If a key is recovered by a CRQC it can also be trivially checked to see if any child keys were produced using an unhardened [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-32] derivation path. -The following table summarizes the scenarios in which public keys are revealed when using Bitcoin, and what type of attack they're vulnerable to: +The following table summarizes the scenarios in which public keys are revealed when using Bitcoin and what type of attack the underlying addresses are vulnerable to: {| |+ Scenarios for revealed public keys on Bitcoin @@ -74,13 +74,13 @@ The following table summarizes the scenarios in which public keys are revealed w | Unhardened BIP-32 HD wallet keys || Both Long-range or Short-range |} -The only time a short-range attack can occur is when the transaction is in the mempool, whereas long-range attacks are when the public key is known well in advance. Short-range attacks require much larger, more expensive CRQCs. +The only time a short-range attack can occur is when the transaction is in the mempool, whereas a long-range attack occurs when the public key is known well in advance. Short-range attacks require much larger, more expensive CRQCs. -Should quantum advantage manifest, a convention is proposed in spending the full 65-byte P2PK key used by the coinbase output in Block 1 back to itself. It is proposed to call this the [https://mempool.space/address/0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f8141781e62294721166bf621e73a82cbf2342c858ee Canary address]. The reasoning behind this is that this can only be done by Satoshi, and given his absence, this can only be spent by others if there is a significant vulnerability in secp256k1. Should the Canary coins move, that will signal that bitcoin is presently vulnerable. Without the Canary, or an address like it, there may be some doubt as to whether the coins were moved with keys belonging to the original owner. +Should quantum advantage manifest, a convention is proposed in spending the full 65-byte P2PK key used by the coinbase output in Block 1 back to itself. It is proposed to call the address in Block 1 the [https://mempool.space/address/0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f8141781e62294721166bf621e73a82cbf2342c858ee Canary address] since it can only be spent from by others (assuming Satoshi's continued absence) if secp256k1 is broken. Should the Canary coins move, that will signal that reliance on secp256k1 is presently vulnerable. Without the Canary, or an address like it, there may be some doubt as to whether the coins were moved with keys belonging to the original owner. As an interesting aside, coinbase outputs to P2PK keys go as far as block 200,000, so it's possible there are between 1-2 million coins that are vulnerable from the first epoch. These coins can be considered "Satoshi's Shield." Any addresses with a balance of less than the original block subsidy of 50 coins can be considered incentive incompatible to capture until all of these are mined. -It's for this reason that, for those who wish to be prepared for quantum emergency, it is recommended that no more than 50 bitcoin are kept under a single distinct, unused Native SegWit (P2WPKH, "bc1q") address at a time. This is assuming that the attacker is financially-motivated instead of, for example, a nation state looking to break confidence in Bitcoin. Additionally, this assumes that other vulnerable targets such as central banks have upgraded their cryptography already. +It's for the above reason that, for those who wish to be prepared for quantum emergency, it is recommended that no more than 50 bitcoin are kept under a single distinct, unused Native SegWit (P2WPKH, "bc1q") address at a time. This is assuming that the attacker is financially-motivated instead of, for example, a nation state looking to break confidence in Bitcoin. Additionally, this assumes that other vulnerable targets such as central banks have upgraded their cryptography already. The Commercial National Security Algorithm Suite (CNSA) 2.0 has a timeline for software and networking equipment to be upgraded by 2030, with browsers and operating systems fully upgraded by 2033. @@ -89,13 +89,13 @@ Lastly, it is worth noting by way of comparison that [https://ethresear.ch/t/how === Rationale === -This is the first in a series of BIPs under a QuBit soft fork. A qubit is a fundamental unit of quantum computing, and the capital B represents its connection to bitcoin. The name QuBit also rhymes to some extent with SegWit. +This is the first in a series of BIPs under a QuBit soft fork. A qubit is a fundamental unit of quantum computing, and the capital B refers to bitcoin. The name QuBit also rhymes to some extent with SegWit. -It is proposed to use SegWit version 3. This results in addresses that start with bc1r, which could be a useful way to remember that these are [r]esistant addresses, similar to how bc1q corresponds to Se[q]Wit and bc1p corresponds to Ta[p]root. This is referencing the lookup table under [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32 BIP-173]. +It is proposed to use SegWit version 3. This results in addresses that start with bc1r, which could be a useful way to remember that these are quantum [r]esistant addresses (similar to how bc1q corresponds to Se[q]Wit and bc1p corresponds to Ta[p]root). This is referencing the lookup table under [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32 BIP-173]. The proposal above also leaves a gap in case it makes sense to use version 2, or bc1z, for implementation of other address formats such as those that employ Cross Input Signature Aggregation (CISA). -P2QRH is meant to be implemented on top of P2TR, combining the security of classical Schnorr signatures along with post-quantum cryptography. This is a form of "hybrid cryptography" such that no regression in security is presented should a vulnerability exist in one of the signature algorithms used. One key distinction between P2QRH and P2TR however is that P2QRH will encode a hash of the public key. This is a significant change in how Taproot works, but is necessary to avoid exposing public keys on-chain in advance of attackers. +P2QRH is meant to be implemented on top of P2TR, combining the security of classical Schnorr signatures along with post-quantum cryptography. This is a form of "hybrid cryptography" such that no regression in security is presented should a vulnerability exist in one of the signature algorithms used. One key distinction between P2QRH and P2TR however is that P2QRH will encode a hash of the public key. This is a significant deviation from how Taproot works by itself, but it is necessary to avoid exposing public keys on-chain where they are vulnerable to attack. P2QRH uses a 32-byte HASH256 (specifically SHA-256 twice-over, which is similar to that used in [https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#specification BIP-16]) of the public key to reduce the size of new outputs and also to increase security by not having the public key available on-chain. This hash serves as a minimal cryptographic commitment to a public key. It goes into the output spend script, which does not receive the witness discount. @@ -103,11 +103,11 @@ Post-quantum public keys are generally larger than those used by ECC, depending Support for FALCON signatures will be introduced first, with the intention of adding SQIsign and other post-quantum algorithms as they are approved. By way of comparison, FALCON signatures are roughly 4x larger than SQIsign signatures and 20x larger than Schnorr signatures. FALCON is a more conservative approach to applied lattice cryptography than SQIsign, and its use has recently been approved by NIST. NIST approval streamlines implementations through establishing consensus in the scientific and developer community. However, even SQIsign signatures are roughly 5x larger than Schnorr signatures. This means, to maintain present transaction throughput, an increase in the witness discount will likely be desired in a QuBit soft fork. That will be specified in a future QuBit BIP. -An increase in the witness discount must not be taken lightly. It must be resistant to applications that might take advantage of this discount (e.g. storage of arbitrary data as seen with "inscriptions") without a corresponding increase in economic activity. Such an increase would not only impact node runners but those with inscriptions would also have the scarcity of their non-monetary assets affected. The only way to prevent this while also increasing the discount is to have a completely separate witness, a "quantum witness". Because it is meant only for public keys and signatures, we call this section of the transaction the attestation. +An increase in the witness discount must not be taken lightly. It must be resistant to applications that might take advantage of this discount (e.g. storage of arbitrary data as seen with "inscriptions") without a corresponding increase in economic activity. An increase in the witness discount would not only impact node runners but those with inscriptions would also have the scarcity of their non-monetary assets affected. The only way to prevent these affects while also increasing the discount is to have a completely separate witness-- a "quantum witness." Because it is meant only for public keys and signatures, we call this section of the transaction the attestation. To address the risk of arbitrary data being stored using P2QRH (QuBit) addresses, very specific rules will be applied to spending from the witness stack in SegWit v3 outputs. A fixed signature size will be necessary for spending the output, and the output must be spendable to be considered valid within node consensus. A fixed signature size will also be helpful to disambiguate between signature types without an additional version byte, as SQIsign signatures are substantially smaller than FALCON signatures. Consequently, the correct signature algorithm can be inferred through byte length. The public key and signature will be pushed separately to the attestation stack. Multiple signatures can be included in order to support multisig applications, and also for spending multiple inputs. -Since only valid signatures can be committed to in a SegWit v3 attestation, arbitrary data cannot be added by miners, as that would affect the consensus of their block. A CRQC operator is economically disincentivized from computing a spendable public key that matched arbitrary signature data due to the cost of that computation. That is because the cost of such a computation could prove quite substantial, rather than simply putting the arbitrary data within a Taproot witness. Doing the work to meet the requirement for it to be consensus-valid data would prove cost-prohibitive. +Since only valid signatures can be committed to in a SegWit v3 attestation, arbitrary data cannot be added by miners, as that would affect the consensus of their block. A CRQC operator is economically disincentivized from computing a spendable public key that matched arbitrary signature data due to the cost of that computation. That is because the cost of such a computation could prove quite substantial, rather than simply putting the arbitrary data within a Taproot witness. Additionally, it should be noted, whether an output with a P2QRH spend script corresponds to a FALCON or SQIsign signature is not known until the output is spent. @@ -133,7 +133,7 @@ For P2QRH descriptors, qrh() should be used. == Security == {| -|+ Proposed quantum resistant signature algorithms ordered by largest to smallest NIST V signature size +|+ Candidate quantum resistant signature algorithms ordered by largest to smallest NIST V signature size |- ! Signature Algorithm !! Year First Introduced !! Signature Size !! Public Key Size || Cryptographic Assumptions |- @@ -169,7 +169,7 @@ In comparison, the size of currently used signature algorithms are: * ECDSA - 70-72 bytes * Schnorr - 64 bytes -In comparison to year, secp256k1 [https://www.secg.org/SEC1-Ver-1.0.pdf was originally specified in 2000]. +In comparison to inception date, secp256k1 [https://www.secg.org/SEC1-Ver-1.0.pdf was originally specified in 2000]. One consideration for choosing an algorithm is its maturity. secp256k1 was already 8 years old by the time it was chosen as bitcoin's curve. Isogeny cryptography when it was first introduced was broken over a weekend. @@ -177,7 +177,7 @@ Ideally SQIsign also proves to be flexible enough to support [https://www.pierri Signature verification speed as it compares to Schnorr or ECDSA isn't seen as high a consideration as signature size due to block space being the primary fee constraint. As a P2QRH implementation materializes, a benchmark will be added for performance comparison. Fortunately, SQIsign signatures are substantially faster to verify than it is to generate keys or to sign, which is a major consideration when a transaction need only be signed once, or a handful of times with PSBT, compared to being verified simultaneously on tens of thousands of nodes. Key generation may need to cached in BIP-32 Hierarchical Deterministic wallets. -An additional consideration is security levels. Longer signature sizes provide more security. NIST has standardized five security levels for post-quantum cryptography. NIST security level I provides security equivalent to 128-bit keys, and security level V provides 256-bit security. +An additional consideration is security level. Longer signature sizes provide more security. NIST has standardized five security levels for post-quantum cryptography. NIST security level I provides security equivalent to 128-bit keys, and security level V provides 256-bit security. == Specification == @@ -203,11 +203,11 @@ In short, the new spend script serialization format is as follows: Addresses then encode this script using bech32m. -32-byte attestation fields are assumed to be Schnorr public keys for Taproot fields, because they are ordinarily included in the spend script, but cannot be included in P2QRH for security reasons. Public key / signature pairs for Taproot fields come before QuBit public key / signature pairs. +32-byte attestation fields are assumed to be Schnorr public keys for Taproot fields because they are ordinarily included in the spend script, but they cannot be included in P2QRH for security reasons. Public key / signature pairs for Taproot fields come before QuBit public key / signature pairs. -Which key type is inferred by its size, as provided by the attestation varint pair, determining whether it's processed as secp256k1 Schnorr, SPHINCS, XMSS, FALCON, and SQIsign. +The exact key type is inferred by its size, as provided by the attestation variant pair, which determines whether it's processed as secp256k1 Schnorr, SPHINCS, XMSS, FALCON, or SQIsign. -If the transaction fails to include the public keys needed to match the spend script hash, it is an invalid transaction, because the cryptographic commitment for the keys has not been met. Because of this, only valid public keys and signatures can be included within the attestation, and no other data. +If the transaction fails to include the public keys needed to match the spend script hash, it is an invalid transaction because the cryptographic commitment for the keys has not been met. Consequently, only valid public keys and signatures can be included within the attestation and no other data. === Public Key Generation === From 0a2ed4a23f232abdbb09db9c55edb5f489f020bc Mon Sep 17 00:00:00 2001 From: Hunter Beast Date: Wed, 20 Nov 2024 18:15:32 -0700 Subject: [PATCH 07/32] Apply suggestions from review Co-authored-by: Mark "Murch" Erhardt --- bip-p2qrh.mediawiki | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/bip-p2qrh.mediawiki b/bip-p2qrh.mediawiki index b332e77250..3f7cecdafb 100644 --- a/bip-p2qrh.mediawiki +++ b/bip-p2qrh.mediawiki @@ -14,7 +14,7 @@ === Abstract === -This document proposes a new SegWit output type, with spending rules based initially-- but not solely-- upon FALCON signatures. (For more on why, see the Rationale and Security sections.) A constraint is that no hard fork or increase in block size is necessary. This document is inspired by [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP-341], which introduced the design of the P2TR (Taproot) address type using Schnorr signatures. +This document proposes the introduction of a new output type based on FALCON signatures. This approach for adding a post-quantum secure output type does not require a hard fork or block size increase. === Copyright === @@ -26,9 +26,9 @@ This document is licensed under the 3-clause BSD license. This proposal aims to improve the quantum resistance of bitcoin's signature security should the Discrete Logarithm Problem (DLP) which secures Elliptic Curve Cryptography (ECC) no longer prove to be computationally hard, likely through quantum advantage by Cryptographically-Relevant Quantum Computers (CRQCs). [https://arxiv.org/pdf/quant-ph/0301141 A variant of Shor's algorithm] is believed to be capable of deriving the private key from a public key exponentially faster than classical means. The application of this variant of Shor's algorithm is herein referred to as quantum key decryption. Note that doubling the public key length, such as with a hypothetical secp512k1 curve, would only make deriving the private key twice as hard. The computational complexity of this is investigated further in the paper, [https://pubs.aip.org/avs/aqs/article/4/1/013801/2835275/The-impact-of-hardware-specifications-on-reaching ''The impact of hardware specifications on reaching quantum advantage in the fault tolerant regime'']. -The primary threat to Bitcoin by CRQCs is [https://en.bitcoin.it/wiki/Quantum_computing_and_Bitcoin#QC_attacks generally considered to be to its breaking of ECC used in signatures and Taproot commitments], hence the focus on a new address format. This is because Shor's algorithm enables a CRQC to break the cryptographic assumptions of ECC in roughly 10^8 quantum operations. While a CRQC could use [https://en.wikipedia.org/wiki/Grover's_algorithm Grover's algorithm] to gain a quadratic speed up on brute force attacks on the hash functions used in Bitcoin, a significantly more powerful CRQC is needed for these attacks to meaningfully impact Bitcoin. For instance, a preimage attack on HASH160used by P2PKH, P2SH, and P2WPKH addresses, though not P2WSH because it uses 256-bit hashes using Grover's algorithm would require at least 10^24 quantum operations. As for Grover's application to mining, see [https://quantumcomputing.stackexchange.com/a/12847 Sam Jaques post on this]. +The primary threat to Bitcoin by CRQCs is [https://en.bitcoin.it/wiki/Quantum_computing_and_Bitcoin#QC_attacks generally considered to be to its breaking of ECC used in signatures and Taproot commitments], hence the focus on a new address format. This is because Shor's algorithm enables a CRQC to break the cryptographic assumptions of ECC in roughly 10^8 quantum operations. While a CRQC could use [https://en.wikipedia.org/wiki/Grover's_algorithm Grover's algorithm] to gain a quadratic speed up on brute force attacks on the hash functions used in Bitcoin, a significantly more powerful CRQC is needed for these attacks to meaningfully impact Bitcoin. For instance, a preimage attack on HASH160used by P2PKH, P2SH, and P2WPKH addresses, though not P2WSH because it uses 256-bit hashes using Grover's algorithm would require at least 10^24 quantum operations. As for Grover's application to mining, see [https://quantumcomputing.stackexchange.com/a/12847 Sam Jaques’ post on this]. -The vulnerability of existing bitcoin addresses is investigated in [https://web.archive.org/web/20240715101040/https://www2.deloitte.com/nl/nl/pages/innovatie/artikelen/quantum-computers-and-the-bitcoin-blockchain.html this Deloitte report]. The report estimates that in 2020 approximately 25% of the bitcoin supply is held within addresses vulnerable to quantum attack. As of the time of writing, that number is now closer to 20%. Additionally, cryptographer Peter Wuille estimates even more might be vulnerable, for the reasons provided [https://x.com/pwuille/status/1108085284862713856 here]. +The vulnerability of existing bitcoin addresses is investigated in [https://web.archive.org/web/20240715101040/https://www2.deloitte.com/nl/nl/pages/innovatie/artikelen/quantum-computers-and-the-bitcoin-blockchain.html this Deloitte report]. The report estimates that in 2020 approximately 25% of the bitcoin supply is held within addresses vulnerable to quantum attack. As of the time of writing, that number is now closer to 20%. Additionally, cryptographer Pieter Wuille [https://x.com/pwuille/status/1108085284862713856 reasons] even more might be vulnerable. Ordinarily, when a transaction is signed, the public key can be recovered from the signature. This makes a transaction submitted to the mempool vulnerable to quantum attack until it's mined. One way to mitigate this is to submit the transaction directly to a mining pool, which bypasses the mempool. This process is known as an out-of-band transaction. The mining pool must be trusted not to reveal the transaction public key to attackers. @@ -36,7 +36,7 @@ Not having public keys exposed on-chain is an important step for quantum securit It is proposed to implement a Pay to Quantum Resistant Hash (P2QRH) address type that relies on a Post-Quantum Cryptographic (PQC) signature algorithm. This new address type protects transactions submitted to the mempool and helps preserve the free market by reducing the need for private, out-of-band mempool transactions. -The following table is non-exhaustive but intended to inform the average bitcoin user whether their bitcoin is vulnerable to quantum attack. +The following table is non-exhaustive but intended to inform the average bitcoin user whether their bitcoin is vulnerable to a long-range quantum attack. {| |+ Vulnerable address types From c92a9b0e4db7e46ff11c7fc9efd32c991e635074 Mon Sep 17 00:00:00 2001 From: Hunter Trujillo Date: Wed, 20 Nov 2024 18:17:59 -0700 Subject: [PATCH 08/32] QuBit - P2QRH spending rules --- bip-p2qrh.mediawiki | 42 ++++++++++++++++++++---------------------- 1 file changed, 20 insertions(+), 22 deletions(-) diff --git a/bip-p2qrh.mediawiki b/bip-p2qrh.mediawiki index 3f7cecdafb..a1e63e59b1 100644 --- a/bip-p2qrh.mediawiki +++ b/bip-p2qrh.mediawiki @@ -14,7 +14,7 @@ === Abstract === -This document proposes the introduction of a new output type based on FALCON signatures. This approach for adding a post-quantum secure output type does not require a hard fork or block size increase. +This document proposes the introduction of a new output type using signatures based on Post-Quantum Cryptography (PQC). This approach for adding a post-quantum secure output type does not require a hard fork or block size increase. === Copyright === @@ -30,11 +30,11 @@ The primary threat to Bitcoin by CRQCs is [https://en.bitcoin.it/wiki/Quantum_co The vulnerability of existing bitcoin addresses is investigated in [https://web.archive.org/web/20240715101040/https://www2.deloitte.com/nl/nl/pages/innovatie/artikelen/quantum-computers-and-the-bitcoin-blockchain.html this Deloitte report]. The report estimates that in 2020 approximately 25% of the bitcoin supply is held within addresses vulnerable to quantum attack. As of the time of writing, that number is now closer to 20%. Additionally, cryptographer Pieter Wuille [https://x.com/pwuille/status/1108085284862713856 reasons] even more might be vulnerable. -Ordinarily, when a transaction is signed, the public key can be recovered from the signature. This makes a transaction submitted to the mempool vulnerable to quantum attack until it's mined. One way to mitigate this is to submit the transaction directly to a mining pool, which bypasses the mempool. This process is known as an out-of-band transaction. The mining pool must be trusted not to reveal the transaction public key to attackers. +Ordinarily, when a transaction is signed, the public key can be recovered from the signature. This makes a transaction submitted to the mempool vulnerable to quantum attack until it's mined. One way to mitigate this is to submit the transaction directly to a mining pool, which bypasses the mempool. This process is known as an out-of-band transaction. The mining pool must be trusted not to reveal the transaction public key to attackers. The problem with this approach is that it requires a trusted third party, which is what this P2QRH proposal aims to avoid. -Not having public keys exposed on-chain is an important step for quantum security. Otherwise funds would need to be spent to new addresses on a regular basis in order to prevent the possibility of a "long-range CRQC attack" recovering the key behind high value addresses. A long-range quantum attack can be considered one performed with chain data, such as that from a used address or one encoded in a spend script. A "short-range quantum attack" would be one performed on keys in the mempool, which is seen as impractical given transaction throughput and block time. As the value being sent increases, so too should the fee in order to commit the transaction to the chain as soon as possible. This makes useless the public key revealed by spending a UTXO, so long as it is never reused. +Not having public keys exposed on-chain is an important step for quantum security. Otherwise funds would need to be spent to new addresses on a regular basis in order to prevent the possibility of a "long-range CRQC attack" recovering the key behind high value addresses. A long-range quantum attack can be considered one performed with chain data, such as that from a used address or one encoded in a spend script. This is likely to be more common early on, as early quantum computers must be run for longer in order to overcome errors caused by noise. A "short-range quantum attack" would be one performed on keys in the mempool, which is seen as much more difficult given the block time, and so it requires more sophisticated CRQCs. As the value being sent increases, so too should the fee in order to commit the transaction to the chain as soon as possible. Once the transaction is mined, it makes useless the public key revealed by spending a UTXO, so long as it is never reused. -It is proposed to implement a Pay to Quantum Resistant Hash (P2QRH) address type that relies on a Post-Quantum Cryptographic (PQC) signature algorithm. This new address type protects transactions submitted to the mempool and helps preserve the free market by reducing the need for private, out-of-band mempool transactions. +It is proposed to implement a Pay to Quantum Resistant Hash (P2QRH) address type that relies on a PQC signature algorithm. This new address type protects transactions submitted to the mempool and helps preserve the free market by preventing the need for private, out-of-band mempool transactions. The following table is non-exhaustive but intended to inform the average bitcoin user whether their bitcoin is vulnerable to a long-range quantum attack. @@ -65,11 +65,11 @@ The following table summarizes the scenarios in which public keys are revealed w |- | Early addresses (Satoshi's coins, CPU miners, starts with 04) || Long-range |- -| Reused addresses (any type, except bc1r) || Long-range +| Reused addresses (any type, except P2QRH) || Long-range |- | Taproot addresses (starts with bc1p) || Long-range |- -| Any transaction in the mempool (except for bc1r) || Short-range +| Any transaction in the mempool (except for P2QRH) || Short-range |- | Unhardened BIP-32 HD wallet keys || Both Long-range or Short-range |} @@ -78,13 +78,11 @@ The only time a short-range attack can occur is when the transaction is in the m Should quantum advantage manifest, a convention is proposed in spending the full 65-byte P2PK key used by the coinbase output in Block 1 back to itself. It is proposed to call the address in Block 1 the [https://mempool.space/address/0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f8141781e62294721166bf621e73a82cbf2342c858ee Canary address] since it can only be spent from by others (assuming Satoshi's continued absence) if secp256k1 is broken. Should the Canary coins move, that will signal that reliance on secp256k1 is presently vulnerable. Without the Canary, or an address like it, there may be some doubt as to whether the coins were moved with keys belonging to the original owner. -As an interesting aside, coinbase outputs to P2PK keys go as far as block 200,000, so it's possible there are between 1-2 million coins that are vulnerable from the first epoch. These coins can be considered "Satoshi's Shield." Any addresses with a balance of less than the original block subsidy of 50 coins can be considered incentive incompatible to capture until all of these are mined. +As an interesting aside, coinbase outputs to P2PK keys go as far as block 200,000, so there are 1,723,848 coins that are vulnerable from the first epoch at the time of writing in P2PK outputs alone. Since the majority of these have a block reward of 50 coins each, there are roughly 34,000 distinct P2PK addresses that are vulnerable. These coins can be considered "Satoshi's Shield." Any addresses with a balance of less than the original block subsidy of 50 coins can be considered incentive incompatible to capture until all of these are mined, and these addresses serve to provide time to transition Bitcoin to implement post-quantum security. -It's for the above reason that, for those who wish to be prepared for quantum emergency, it is recommended that no more than 50 bitcoin are kept under a single distinct, unused Native SegWit (P2WPKH, "bc1q") address at a time. This is assuming that the attacker is financially-motivated instead of, for example, a nation state looking to break confidence in Bitcoin. Additionally, this assumes that other vulnerable targets such as central banks have upgraded their cryptography already. +It's for the above reason that, for those who wish to be prepared for quantum emergency, it is recommended that no more than 50 bitcoin are kept under a single, distinct, unused Native SegWit (P2WPKH, "bc1q") address at a time. This is assuming that the attacker is financially-motivated instead of, for example, a nation state looking to break confidence in Bitcoin. Additionally, this assumes that other vulnerable targets such as central banks have upgraded their cryptography by this time. -The Commercial National Security Algorithm Suite (CNSA) 2.0 has a timeline for software and networking equipment to be upgraded by 2030, with browsers and operating systems fully upgraded by 2033. - -Lastly, it is worth noting by way of comparison that [https://ethresear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/18901 Vitalik Buterin's proposed solution] in an Ethereum quantum emergency is quite different from the approach in this BIP. His plan involves a hard fork of the chain, reverting all blocks after a sufficient amount of theft, and using STARKs based on BIP-32 seeds to act as the authoritative secret when signing. These measures are deemed far too heavy-handed for bitcoin. +The Commercial National Security Algorithm Suite (CNSA) 2.0 has a timeline for software and networking equipment to be upgraded by 2030, with browsers and operating systems fully upgraded by 2033. According to NIST IR 8547, Elliptic Curve Cryptography is planned to be disallowed within the US Federal government after 2035. An exception is made for hybrid cryptography, which is the use of ECC and post-quantum algorithms together. === Rationale === @@ -95,7 +93,7 @@ It is proposed to use SegWit version 3. This results in addresses that start wit The proposal above also leaves a gap in case it makes sense to use version 2, or bc1z, for implementation of other address formats such as those that employ Cross Input Signature Aggregation (CISA). -P2QRH is meant to be implemented on top of P2TR, combining the security of classical Schnorr signatures along with post-quantum cryptography. This is a form of "hybrid cryptography" such that no regression in security is presented should a vulnerability exist in one of the signature algorithms used. One key distinction between P2QRH and P2TR however is that P2QRH will encode a hash of the public key. This is a significant deviation from how Taproot works by itself, but it is necessary to avoid exposing public keys on-chain where they are vulnerable to attack. +P2QRH is meant to be implemented on top of P2TR, combining the security of classical Schnorr signatures along with post-quantum cryptography. This is a form of hybrid cryptography such that no regression in security is presented should a vulnerability exist in one of the signature algorithms used. One key distinction between P2QRH and P2TR however is that P2QRH will encode a hash of the public key. This is a significant deviation from how Taproot works by itself, but it is necessary to avoid exposing public keys on-chain where they are vulnerable to attack. P2QRH uses a 32-byte HASH256 (specifically SHA-256 twice-over, which is similar to that used in [https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#specification BIP-16]) of the public key to reduce the size of new outputs and also to increase security by not having the public key available on-chain. This hash serves as a minimal cryptographic commitment to a public key. It goes into the output spend script, which does not receive the witness discount. @@ -218,11 +216,7 @@ TBD, pending test vectors TBD -=== Default Signing === - -TBD - -=== Alternative Signing === +=== Signing === TBD @@ -230,10 +224,6 @@ TBD TBD -=== Batch Verification === - -TBD - === Usage Considerations === TBD @@ -243,6 +233,11 @@ TBD TBD +== Related Work == + +It is worth noting by way of comparison that [https://ethresear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/18901 Vitalik Buterin's proposed solution] in an Ethereum quantum emergency is quite different from the approach in this BIP. His plan involves a hard fork of the chain, reverting all blocks after a sufficient amount of theft, and using STARKs based on BIP-32 seeds to act as the authoritative secret when signing. These measures are deemed far too heavy-handed for bitcoin. + + == References == * [https://groups.google.com/g/bitcoindev/c/Aee8xKuIC2s/m/cu6xej1mBQAJ Mailing list discussion] @@ -260,6 +255,7 @@ TBD To help implementors understand updates to this BIP, we keep a list of substantial changes. +* 2024-11-20 - Clarifications based on feedback from Murch. Remove some sections that are not yet ready. * 2024-10-21 - Replace XMSS with CRYSTALS-Dilithium due to NIST approval and size constraints. * 2024-09-30 - Refactor the ECC vs PoW section. Swap quitness for attestation. * 2024-09-29 - Update section on PoW to include partial-preimage. @@ -269,4 +265,6 @@ To help implementors understand updates to this BIP, we keep a list of substanti == Acknowledgements == -Much gratitude to my co-founder, Kyle Crews for proofreading and editing, to David Croisant, who suggested the name "QuBit", and Guy Swann for pointing out the earlier name for the attestation, "quitness", was imperfect. Thank you as well to those who took the time to review and contribute, including Adam Borcany, Antoine Riard, Pierre-Luc Dallaire-Demers, Ethan Heilman, Jon Atack, and Jameson Lopp. +This document is inspired by [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP-341], which introduced the design of the P2TR (Taproot) address type using Schnorr signatures. + +Much gratitude to my co-founder, Kyle Crews for proofreading and editing, to David Croisant, who suggested the name "QuBit", and Guy Swann for pointing out the earlier name for the attestation, "quitness", was imperfect. Thank you as well to those who took the time to review and contribute, including Adam Borcany, Antoine Riard, Pierre-Luc Dallaire-Demers, Ethan Heilman, Jon Atack, Jameson Lopp, and Murchandamus. From e1b7007cd93027409aa99a43ce2e35854771088b Mon Sep 17 00:00:00 2001 From: Hunter Beast Date: Tue, 3 Dec 2024 15:36:38 -0700 Subject: [PATCH 09/32] Add details on attestation structure and parsing. (#14) * Add details on attestation structure and parsing. * bip-p2qrh.mediawiki: Separating discussion about Grovers algorithm into its own section. * Update phrasing and formatting. * Kyle fixes * Add Jeff Bride to acknowledgments * Apply suggestions from code review Co-authored-by: Kyle Crews <92337423+CrewsControlSolutions@users.noreply.github.com> * Updates to clarity. --------- Co-authored-by: jbride Co-authored-by: Kyle Crews <92337423+CrewsControlSolutions@users.noreply.github.com> --- bip-p2qrh.mediawiki | 224 +++++++++++++++++++++++++++++++++++++------- 1 file changed, 192 insertions(+), 32 deletions(-) diff --git a/bip-p2qrh.mediawiki b/bip-p2qrh.mediawiki index a1e63e59b1..5d715417bb 100644 --- a/bip-p2qrh.mediawiki +++ b/bip-p2qrh.mediawiki @@ -24,9 +24,9 @@ This document is licensed under the 3-clause BSD license. === Motivation === -This proposal aims to improve the quantum resistance of bitcoin's signature security should the Discrete Logarithm Problem (DLP) which secures Elliptic Curve Cryptography (ECC) no longer prove to be computationally hard, likely through quantum advantage by Cryptographically-Relevant Quantum Computers (CRQCs). [https://arxiv.org/pdf/quant-ph/0301141 A variant of Shor's algorithm] is believed to be capable of deriving the private key from a public key exponentially faster than classical means. The application of this variant of Shor's algorithm is herein referred to as quantum key decryption. Note that doubling the public key length, such as with a hypothetical secp512k1 curve, would only make deriving the private key twice as hard. The computational complexity of this is investigated further in the paper, [https://pubs.aip.org/avs/aqs/article/4/1/013801/2835275/The-impact-of-hardware-specifications-on-reaching ''The impact of hardware specifications on reaching quantum advantage in the fault tolerant regime'']. +This proposal aims to improve the quantum resistance of bitcoin's signature security should the Discrete Logarithm Problem (DLP) which secures Elliptic Curve Cryptography (ECC) no longer prove to be computationally hard, likely through quantum advantage by Cryptoanalytically-Relevant Quantum Computers (CRQCs). [https://arxiv.org/pdf/quant-ph/0301141 A variant of Shor's algorithm] is believed to be capable of deriving the private key from a public key exponentially faster than classical means. The application of this variant of Shor's algorithm is herein referred to as quantum key decryption. Note that doubling the public key length, such as with a hypothetical secp512k1 curve, would only make deriving the private key twice as hard. The computational complexity of this is investigated further in the paper, [https://pubs.aip.org/avs/aqs/article/4/1/013801/2835275/The-impact-of-hardware-specifications-on-reaching ''The impact of hardware specifications on reaching quantum advantage in the fault tolerant regime'']. -The primary threat to Bitcoin by CRQCs is [https://en.bitcoin.it/wiki/Quantum_computing_and_Bitcoin#QC_attacks generally considered to be to its breaking of ECC used in signatures and Taproot commitments], hence the focus on a new address format. This is because Shor's algorithm enables a CRQC to break the cryptographic assumptions of ECC in roughly 10^8 quantum operations. While a CRQC could use [https://en.wikipedia.org/wiki/Grover's_algorithm Grover's algorithm] to gain a quadratic speed up on brute force attacks on the hash functions used in Bitcoin, a significantly more powerful CRQC is needed for these attacks to meaningfully impact Bitcoin. For instance, a preimage attack on HASH160used by P2PKH, P2SH, and P2WPKH addresses, though not P2WSH because it uses 256-bit hashes using Grover's algorithm would require at least 10^24 quantum operations. As for Grover's application to mining, see [https://quantumcomputing.stackexchange.com/a/12847 Sam Jaques’ post on this]. +The primary threat to Bitcoin by CRQCs is [https://en.bitcoi.it/wiki/Quantum_computing_and_Bitcoin#QC_attacks generally considered to be their potential to break ECC, which is used in signatures and Taproot commitments], hence the focus on a new address format. Shor's algorithm enables a CRQC to break the cryptographic assumptions of ECC in roughly 10^8 quantum operations. The vulnerability of existing bitcoin addresses is investigated in [https://web.archive.org/web/20240715101040/https://www2.deloitte.com/nl/nl/pages/innovatie/artikelen/quantum-computers-and-the-bitcoin-blockchain.html this Deloitte report]. The report estimates that in 2020 approximately 25% of the bitcoin supply is held within addresses vulnerable to quantum attack. As of the time of writing, that number is now closer to 20%. Additionally, cryptographer Pieter Wuille [https://x.com/pwuille/status/1108085284862713856 reasons] even more might be vulnerable. @@ -84,12 +84,13 @@ It's for the above reason that, for those who wish to be prepared for quantum em The Commercial National Security Algorithm Suite (CNSA) 2.0 has a timeline for software and networking equipment to be upgraded by 2030, with browsers and operating systems fully upgraded by 2033. According to NIST IR 8547, Elliptic Curve Cryptography is planned to be disallowed within the US Federal government after 2035. An exception is made for hybrid cryptography, which is the use of ECC and post-quantum algorithms together. +Although CRQCs could pose a threat to the signatures used in Bitcoin, a smaller threat is to Bitcoin's hash algorithms. In particular, while a CRQC could use [https://en.wikipedia.org/wiki/Grover's_algorithm Grover's algorithm] to gain a quadratic speed up on brute force attacks on the hash functions used in Bitcoin, a significantly more powerful CRQC is needed for these attacks to meaningfully impact Bitcoin. For instance, a preimage attack on HASH160used by P2PKH, P2SH, and P2WPKH addresses, though not P2WSH because it uses 256-bit hashes using Grover's algorithm would require at least 10^24 quantum operations. As for Grover's application to mining, see [https://quantumcomputing.stackexchange.com/a/12847 Sam Jaques’ post on this]. === Rationale === This is the first in a series of BIPs under a QuBit soft fork. A qubit is a fundamental unit of quantum computing, and the capital B refers to bitcoin. The name QuBit also rhymes to some extent with SegWit. -It is proposed to use SegWit version 3. This results in addresses that start with bc1r, which could be a useful way to remember that these are quantum [r]esistant addresses (similar to how bc1q corresponds to Se[q]Wit and bc1p corresponds to Ta[p]root). This is referencing the lookup table under [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32 BIP-173]. +It is proposed to use SegWit version 3. This results in addresses that start with bc1r, which could be a useful way to remember that these are quantum (r)esistant addresses (similar to how bc1q corresponds to Se(q)Wit and bc1p corresponds to Ta(p)root). This is referencing the lookup table under [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32 BIP-173]. The proposal above also leaves a gap in case it makes sense to use version 2, or bc1z, for implementation of other address formats such as those that employ Cross Input Signature Aggregation (CISA). @@ -123,9 +124,105 @@ We first build up a definition of the signature scheme by going through the desi === Design === -For P2QRH descriptors, qrh() should be used. +==== Descriptor Format ==== -> Further specific details to be completed later in the draft process as outlined in [https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki BIP-2] +To integrate P2QRH into existing wallet software and scripts, we introduce a new output descriptor function qrh(). This function represents a P2QRH output, similar to how wpkh() and tr() are used for P2WPKH and P2TR outputs, respectively. + +The qrh() function takes the HASH256 of the concatenated HASH256 of the quantum-resistant public keys as its argument. For example: + + +qrh(HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ...)) + + +The above function allows wallets to manage P2QRH addresses and outputs while accommodating multiple public keys of varying lengths, such as in multisig schemes, while keeping the public keys hidden until the time of spending. + + +==== Address Format ==== + +P2QRH uses SegWit version 3 outputs, resulting in addresses that start with bc1r, following [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32 BIP-173]. Bech32 encoding maps version 3 to the prefix r. + +Example P2QRH address: + + +bc1r... (32-byte Bech32m-encoded HASH256 of the HASH256 of the public keys) + + +==== ScriptPubKey ==== + +The scriptPubKey for a P2QRH output is: + + +OP_PUSHNUM_3 OP_PUSHBYTES_32 + + +Where: + +* OP_PUSHNUM_3 (0x03) indicates SegWit version 3. +* is the 32-byte HASH256 of the concatenated HASH256 of each public key. + +===== Hash Computation ===== + + +hash = HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN)) + + +This construction creates a cryptographic commitment to multiple public keys. + +==== Transaction Serialization ==== + +Following BIP-141, the transaction serialization is modified to include a new attestation field after the witness field: + + +[nVersion][marker][flag][txins][txouts][witness][attestation][nLockTime] + + +* marker: 0x00 (same as SegWit) +* flag: 0x02 (indicates the presence of both witness and attestation data) +* attestation: Contains the quantum-resistant public keys and signatures. + +==== Attestation Structure ==== + +The attestation field consists of: + +* num_pubkeys: The number of public keys (VarInt encoded). +* For each public key: +** pubkey_length: VarInt encoded length of the public key. +** pubkey: The public key bytes. +* num_signatures: The number of signatures (VarInt encoded). +* For each signature: +** signature_length: VarInt encoded length of the signature. +** signature: The signature bytes. + +This structure repeats for each input, in order, for flexibility in supporting multisig schemes and various quantum-resistant algorithms. + +For each input, a separate attestation field is used. To know how many attestation fields are present, implementations must count the number of inputs present in the transaction. + +The specific algorithm is determined by the size of the public key and signature, as described in the next section. + +==== Signature Algorithm Identification ==== + +The specific quantum-resistant signature algorithm used is inferred from the length of the public key and signature. Implementations must recognize the supported algorithms and validate accordingly. + +Supported algorithms and their NIST Level V parameters: + +* '''SPHINCS+-256f:''' +** Public Key Length: 64 bytes +** Signature Length: 49,856 bytes +* '''CRYSTALS-Dilithium Level 5''': +** Public Key Length: 2,592 bytes +** Signature Length: 4,595 bytes +* '''FALCON-1024''': +** Public Key Length: 1,793 bytes +** Signature Length: 1,280 bytes +* '''SQIsign NIST-V''': +** Public Key Length: 128 bytes +** Signature Length: 335 bytes + +Implementations must reject public keys and signatures that do not match expected lengths for supported algorithms. + +==== Compatibility with BIP-141 ==== + +By adhering to the SegWit transaction structure and versioning, P2QRH outputs are compatible with existing transaction processing rules. Nodes that do not recognize SegWit version 3 will treat these outputs as anyone-can-spend but, per BIP-141, will not relay or mine such transactions. == Security == @@ -159,8 +256,7 @@ For P2QRH descriptors, qrh() should be used. |} - -As shown, supersingular elliptic curve quaternion isogeny signature algorithms represent the state of the art in post-quantum cryptography, beyond lattice cryptography alone, especially when key and signature length are major constraints. This makes inclusion of SQIsign attractive, and support is planned, but it will be some time until it is approved for production use. Meanwhile, FALCON signatures are already approved and have achieved broader community consensus. +As shown, supersingular elliptic curve quaternion isogeny signature algorithms represent the state of the art in post-quantum cryptography, beyond lattice cryptography alone, especially when key and signature length are major constraints. This makes inclusion of SQIsign attractive, and support is planned, but it will be some time until it is approved for production use. Meanwhile, SPHINCS+ and CRYSTALS-Dilithium signatures are already approved and have achieved broader community consensus. FALCON signatures are also NIST approved. In comparison, the size of currently used signature algorithms are: @@ -182,51 +278,114 @@ An additional consideration is security level. Longer signature sizes provide mo How the attestation is differentiated from the witness can be accomplished similar to how [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#user-content-Transaction_ID BIP-141] introduced the marker and flag, with the QuBit flag being set to 0x02. This means all QuBit transactions are also SegWit transactions. The additional data would be included as a second array of byte arrays following the witness stack. -The new transaction serialization format is as follows: +32-byte attestation fields are assumed to be Schnorr public keys for Taproot fields because they are ordinarily included in the spend script, but they cannot be included in P2QRH for security reasons. Public key / signature pairs for Taproot fields come before QuBit public key / signature pairs. - [nVersion][marker][flag][txins][txouts][witness][attestation][nLockTime] +The exact key type is inferred by its size, as provided by the attestation variant pair, which determines whether it's processed as secp256k1 Schnorr, SPHINCS, CRYSTALS-Dilithium, FALCON, or SQIsign. -QuBit spend scripts are as follows: +If the transaction fails to include the public keys needed to match the spend script hash, it is an invalid transaction because the cryptographic commitment for the keys has not been met. Consequently, only valid public keys and signatures can be included within the attestation and no other data. -* OP_PUSHNUM_3 to indicate SegWit version 3 -* OP_PUSHBYTES_32 -* HASH256 of the following bytes concatenated: - * HASH256 of the public key at attestation index 0 - * If there are more public keys: - * All public keys are hashed via HASH256 and concatenated -In short, the new spend script serialization format is as follows: +=== Script Validation === - OP_PUSHNUM_3 HASH256([HASH256(Public Key Bytes at Attestation Index 0)][HASH256(PK Q1)][..]) +To spend a P2QRH output, the following conditions must be met: -Addresses then encode this script using bech32m. +1. The scriptPubKey must be of the form: -32-byte attestation fields are assumed to be Schnorr public keys for Taproot fields because they are ordinarily included in the spend script, but they cannot be included in P2QRH for security reasons. Public key / signature pairs for Taproot fields come before QuBit public key / signature pairs. + +OP_PUSHNUM_3 <32-byte hash> + -The exact key type is inferred by its size, as provided by the attestation variant pair, which determines whether it's processed as secp256k1 Schnorr, SPHINCS, XMSS, FALCON, or SQIsign. +2. The attestation must include: -If the transaction fails to include the public keys needed to match the spend script hash, it is an invalid transaction because the cryptographic commitment for the keys has not been met. Consequently, only valid public keys and signatures can be included within the attestation and no other data. +** The quantum-resistant public key(s) whose HASH256 concatenated and hashed again matches the in the scriptPubKey. +** Valid signatures corresponding to the public key(s) and the transaction data. +3. For multi-signature schemes, all required public keys and signatures must be provided for that input within the attestation. This includes classical Schnorr signatures. -=== Public Key Generation === -TBD, pending test vectors +==== Public Key Hashing ==== -=== Public Key Conversion === +All public keys included in the attestation are hashed using HASH256 (double SHA-256). The concatenation of these hashes is then hashed again using HASH256 before being included in the scriptPubKey. This ensures a fixed-size commitment to potentially multiple public keys of varying lengths. -TBD +'''Hash Computation:''' -=== Signing === + +hash = HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN)) + -TBD -=== Verification === +==== Sighash Calculation ==== -TBD +The sighash for P2QRH outputs follows the same procedure as defined in BIP-0143 for SegWit transactions: + +* '''Hash Prevouts:''' Computed over the previous outputs being spent. +* '''Hash Sequence:''' Computed over the sequence fields. +* '''Hash Outputs:''' Computed over the outputs of the transaction. + +The message to be signed includes these hashes, ensuring transaction malleability is prevented. + +==== Signature Verification ==== + +Signature verification is as follows: + +1. Extract the from the scriptPubKey. +2. For each input: +** Compute hashed_pubkeys by concatenating the HASH256 of each provided public key. + +hashed_pubkeys = HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN) + +** Compute computed_hash + +computed_hash = HASH256(hashed_pubkeys) + +** Compare the resulting hash to . If they do not match, the script fails. +3. Verify each signature against the corresponding public key and the sighash. +4. Ensure that the signature algorithm used matches the expected lengths for NIST Level V security and is supported. + +==== Attestation Parsing Example ==== + +Signing for a single input using both FALCON-1024 and secp256k1 Schnorr: + +* [num_pubkeys]: 0x02 +** '''Pubkey 1:''' +*** [pubkey_length]: 0x0701 (1793 bytes) +*** [pubkey]: public_key_falcon_1024 +** '''Pubkey 2:''' +*** [pubkey_length]: 0x20 (32 bytes) +*** [pubkey]: public_key_secp256k1 +* [num_signatures]: 0x02 +** '''Signature 1:''' +*** [signature_length]: 0x0500 (1280 bytes) +*** [signature]: signature_falcon_1024 +** '''Signature 2:''' +*** [signature_length]: 0x40 (64 bytes) +*** [signature]: signature_secp256k1 + +Note: This contrasts with multisig inputs, where the attestation structure repeats for each public key and signature. === Usage Considerations === -TBD +==== Transaction Size and Fees ==== + +Quantum-resistant signatures are significantly larger than traditional signatures, increasing transaction size and the fees required. Users and wallet developers should be aware of this and plan accordingly. + +For example, for CRYSTALS-Dilithium Level V, a single signature is 4595 bytes, a substantial increase over current ECDSA or Schnorr signatures. + + +==== Performance Impact ==== + +Verification of quantum-resistant signatures will be computationally more intensive, and any attestation discount will also increase storage requirements. Node operators should consider the potential impact on resource usage in the long term. Developers may need to optimize signature verification implementations, especially by implementing caching for key generation. + + +==== Algorithm Selection ==== + +Introducing four quantum-resistant algorithms to the bitcoin ecosystem provides users with the option to select an appropriate algorithm for their use case, generally based on the amount of value they wish to secure. Developers can choose to implement support for multiple algorithms in wallets and on nodes to offer quantum-resistant options. + + +==== Backward Compatibility ==== + +Older wallets and nodes that have not been made compatible with SegWit version 3 and P2QRH will not recognize these outputs. Users should ensure they are using updated wallets and nodes to use P2QRH addresses and validate transactions using P2QRH outputs. + == Test Vectors and Reference Code == @@ -255,6 +414,7 @@ It is worth noting by way of comparison that [https://ethresear.ch/t/how-to-hard To help implementors understand updates to this BIP, we keep a list of substantial changes. +* 2024-12-01 - Add details on attestation structure and parsing. * 2024-11-20 - Clarifications based on feedback from Murch. Remove some sections that are not yet ready. * 2024-10-21 - Replace XMSS with CRYSTALS-Dilithium due to NIST approval and size constraints. * 2024-09-30 - Refactor the ECC vs PoW section. Swap quitness for attestation. @@ -267,4 +427,4 @@ To help implementors understand updates to this BIP, we keep a list of substanti This document is inspired by [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP-341], which introduced the design of the P2TR (Taproot) address type using Schnorr signatures. -Much gratitude to my co-founder, Kyle Crews for proofreading and editing, to David Croisant, who suggested the name "QuBit", and Guy Swann for pointing out the earlier name for the attestation, "quitness", was imperfect. Thank you as well to those who took the time to review and contribute, including Adam Borcany, Antoine Riard, Pierre-Luc Dallaire-Demers, Ethan Heilman, Jon Atack, Jameson Lopp, and Murchandamus. +Much gratitude to my co-founder, Kyle Crews for proofreading and editing, to David Croisant, who suggested the name "QuBit", and Guy Swann for pointing out the earlier name for the attestation, "quitness", was imperfect. Thank you as well to those who took the time to review and contribute, including Jeff Bride, Adam Borcany, Antoine Riard, Pierre-Luc Dallaire-Demers, Ethan Heilman, Jon Atack, Jameson Lopp, and Murchandamus. From 60d72942aa23a760a5c50df48b86f88c71d0915d Mon Sep 17 00:00:00 2001 From: Hunter Trujillo Date: Tue, 3 Dec 2024 16:22:21 -0700 Subject: [PATCH 10/32] MediaWiki formatting fixes --- bip-p2qrh.mediawiki | 59 ++++++++++++++++++++++++++------------------- 1 file changed, 34 insertions(+), 25 deletions(-) diff --git a/bip-p2qrh.mediawiki b/bip-p2qrh.mediawiki index 5d715417bb..bfd6043e6e 100644 --- a/bip-p2qrh.mediawiki +++ b/bip-p2qrh.mediawiki @@ -291,27 +291,27 @@ To spend a P2QRH output, the following conditions must be met: 1. The scriptPubKey must be of the form: - +
 OP_PUSHNUM_3 <32-byte hash>
-
+
2. The attestation must include: -** The quantum-resistant public key(s) whose HASH256 concatenated and hashed again matches the in the scriptPubKey. -** Valid signatures corresponding to the public key(s) and the transaction data. +* The quantum-resistant public key(s) whose HASH256 concatenated and hashed again matches the in the scriptPubKey. +* Valid signatures corresponding to the public key(s) and the transaction data. 3. For multi-signature schemes, all required public keys and signatures must be provided for that input within the attestation. This includes classical Schnorr signatures. ==== Public Key Hashing ==== -All public keys included in the attestation are hashed using HASH256 (double SHA-256). The concatenation of these hashes is then hashed again using HASH256 before being included in the scriptPubKey. This ensures a fixed-size commitment to potentially multiple public keys of varying lengths. +All public keys included in the attestation are hashed using HASH256 (double SHA-256). The concatenation of these hashes is then hashed again using HASH256 before being included in the 
scriptPubKey
. This ensures a fixed-size commitment to potentially multiple public keys of varying lengths. '''Hash Computation:''' - +
 hash = HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN))
-
+
==== Sighash Calculation ==== @@ -328,38 +328,46 @@ The message to be signed includes these hashes, ensuring transaction malleabilit Signature verification is as follows: -1. Extract the from the scriptPubKey. +1. Extract the
from the 
scriptPubKey
. + 2. For each input: -** Compute hashed_pubkeys by concatenating the HASH256 of each provided public key. - + +* Compute 
hashed_pubkeys
by concatenating the HASH256 of each provided public key. + +
 hashed_pubkeys = HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN)
-
-** Compute computed_hash
-
+
+ +* Compute 
computed_hash
+ +
 computed_hash = HASH256(hashed_pubkeys)
-
-** Compare the resulting hash to . If they do not match, the script fails.
+
+ +* Compare the resulting hash to
. If they do not match, the script fails. + 3. Verify each signature against the corresponding public key and the sighash. + 4. Ensure that the signature algorithm used matches the expected lengths for NIST Level V security and is supported. ==== Attestation Parsing Example ==== Signing for a single input using both FALCON-1024 and secp256k1 Schnorr: -* [num_pubkeys]: 0x02 +* 
[num_pubkeys]
: 
0x02
** '''Pubkey 1:''' -*** [pubkey_length]: 0x0701 (1793 bytes) -*** [pubkey]: public_key_falcon_1024 +*** 
[pubkey_length]
: 
0x0701
(1793 bytes) +*** 
[pubkey]
: 
public_key_falcon_1024
** '''Pubkey 2:''' -*** [pubkey_length]: 0x20 (32 bytes) -*** [pubkey]: public_key_secp256k1 -* [num_signatures]: 0x02 +*** 
[pubkey_length]
: 
0x20
(32 bytes) +*** 
[pubkey]
: 
public_key_secp256k1
+* 
[num_signatures]
: 
0x02
** '''Signature 1:''' -*** [signature_length]: 0x0500 (1280 bytes) -*** [signature]: signature_falcon_1024 +*** 
[signature_length]
: 
0x0500
(1280 bytes) +*** 
[signature]
: 
signature_falcon_1024
** '''Signature 2:''' -*** [signature_length]: 0x40 (64 bytes) -*** [signature]: signature_secp256k1 +*** 
[signature_length]
: 
0x40
(64 bytes) +*** 
[signature]
: 
signature_secp256k1
Note: This contrasts with multisig inputs, where the attestation structure repeats for each public key and signature. @@ -414,6 +422,7 @@ It is worth noting by way of comparison that [https://ethresear.ch/t/how-to-hard To help implementors understand updates to this BIP, we keep a list of substantial changes. +* 2024-12-03 - MediaWiki formatting fixes. * 2024-12-01 - Add details on attestation structure and parsing. * 2024-11-20 - Clarifications based on feedback from Murch. Remove some sections that are not yet ready. * 2024-10-21 - Replace XMSS with CRYSTALS-Dilithium due to NIST approval and size constraints. From 2d098d9adf11929234258793e22776a0e2ddb9fa Mon Sep 17 00:00:00 2001 From: Hunter Trujillo Date: Thu, 5 Dec 2024 09:04:28 -0700 Subject: [PATCH 11/32] MediaWiki formatting fixes --- bip-p2qrh.mediawiki | 60 +++++++++++++++++++++++++-------------------- 1 file changed, 34 insertions(+), 26 deletions(-) diff --git a/bip-p2qrh.mediawiki b/bip-p2qrh.mediawiki index bfd6043e6e..af2483ec6c 100644 --- a/bip-p2qrh.mediawiki +++ b/bip-p2qrh.mediawiki @@ -162,9 +162,9 @@ Where: ===== Hash Computation ===== - +
 hash = HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN))
-
+
This construction creates a cryptographic commitment to multiple public keys. @@ -305,9 +305,10 @@ OP_PUSHNUM_3 <32-byte hash> ==== Public Key Hashing ==== -All public keys included in the attestation are hashed using HASH256 (double SHA-256). The concatenation of these hashes is then hashed again using HASH256 before being included in the 
scriptPubKey
. This ensures a fixed-size commitment to potentially multiple public keys of varying lengths. +All public keys included in the attestation are hashed using HASH256 (double SHA-256). The concatenation of these hashes is then hashed again using HASH256 before being included in the scriptPubKey. This ensures a fixed-size commitment to potentially multiple public keys of varying lengths. -'''Hash Computation:''' + +==== Hash Computation ==== 
 hash = HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN))
@@ -328,23 +329,23 @@ The message to be signed includes these hashes, ensuring transaction malleabilit
 
 Signature verification is as follows:
 
-1. Extract the 
 from the 
scriptPubKey
.
+1. Extract the  from the scriptPubKey.
 
 2. For each input:
 
-* Compute 
hashed_pubkeys
 by concatenating the HASH256 of each provided public key.
+   * Compute hashed_pubkeys by concatenating the HASH256 of each provided public key:
 
-
+     
 hashed_pubkeys = HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN)
-

+     

 
-* Compute 
computed_hash

+   * Compute computed_hash:
 
-
+     
 computed_hash = HASH256(hashed_pubkeys)
-

+     

 
-* Compare the resulting hash to 
. If they do not match, the script fails.
+   * Compare the resulting hash to . If they do not match, the script fails.
 
 3. Verify each signature against the corresponding public key and the sighash.
 
@@ -354,20 +355,27 @@ computed_hash = HASH256(hashed_pubkeys)
 
 Signing for a single input using both FALCON-1024 and secp256k1 Schnorr:
 
-* 
[num_pubkeys]
: 
0x02

-** '''Pubkey 1:'''
-*** 
[pubkey_length]
: 
0x0701
 (1793 bytes)
-*** 
[pubkey]
: 
public_key_falcon_1024

-** '''Pubkey 2:'''
-*** 
[pubkey_length]
: 
0x20
 (32 bytes)
-*** 
[pubkey]
: 
public_key_secp256k1

-* 
[num_signatures]
: 
0x02

-** '''Signature 1:'''
-*** 
[signature_length]
: 
0x0500
 (1280 bytes)
-*** 
[signature]
: 
signature_falcon_1024

-** '''Signature 2:'''
-*** 
[signature_length]
: 
0x40
 (64 bytes)
-*** 
[signature]
: 
signature_secp256k1

+
+[num_pubkeys]: 0x02
+
+Pubkey 1:
+  [pubkey_length]: 0x0701 (1793 bytes)
+  [pubkey]: public_key_falcon_1024
+
+Pubkey 2:
+  [pubkey_length]: 0x20 (32 bytes)
+  [pubkey]: public_key_secp256k1
+
+[num_signatures]: 0x02
+
+Signature 1:
+  [signature_length]: 0x0500 (1280 bytes)
+  [signature]: signature_falcon_1024
+
+Signature 2:
+  [signature_length]: 0x40 (64 bytes)
+  [signature]: signature_secp256k1
+

 
 Note: This contrasts with multisig inputs, where the attestation structure repeats for each public key and signature.
 

From ed4e8627e67c8404c297e451fa3620dd8f85e5a6 Mon Sep 17 00:00:00 2001
From: Hunter Beast 
Date: Fri, 6 Dec 2024 08:29:44 -0700
Subject: [PATCH 12/32] MediaWiki fixes, remove redundant sections. (#16)

* MediaWiki fixes, remove redundant sections.

* Fix link format check
---
 bip-p2qrh.mediawiki | 284 ++++++++++++++++++++------------------------
 1 file changed, 126 insertions(+), 158 deletions(-)

diff --git a/bip-p2qrh.mediawiki b/bip-p2qrh.mediawiki
index af2483ec6c..f79473c28f 100644
--- a/bip-p2qrh.mediawiki
+++ b/bip-p2qrh.mediawiki
@@ -16,29 +16,27 @@
 
 This document proposes the introduction of a new output type using signatures based on Post-Quantum Cryptography (PQC). This approach for adding a post-quantum secure output type does not require a hard fork or block size increase.
 
-
 === Copyright ===
 
 This document is licensed under the 3-clause BSD license.
 
-
 === Motivation ===
 
-This proposal aims to improve the quantum resistance of bitcoin's signature security should the Discrete Logarithm Problem (DLP) which secures Elliptic Curve Cryptography (ECC) no longer prove to be computationally hard, likely through quantum advantage by Cryptoanalytically-Relevant Quantum Computers (CRQCs). [https://arxiv.org/pdf/quant-ph/0301141 A variant of Shor's algorithm] is believed to be capable of deriving the private key from a public key exponentially faster than classical means. The application of this variant of Shor's algorithm is herein referred to as quantum key decryption. Note that doubling the public key length, such as with a hypothetical secp512k1 curve, would only make deriving the private key twice as hard. The computational complexity of this is investigated further in the paper, [https://pubs.aip.org/avs/aqs/article/4/1/013801/2835275/The-impact-of-hardware-specifications-on-reaching ''The impact of hardware specifications on reaching quantum advantage in the fault tolerant regime''].
+This proposal aims to improve the quantum resistance of Bitcoin's signature security should the Discrete Logarithm Problem (DLP), which secures Elliptic Curve Cryptography (ECC), no longer prove to be computationally hard, likely through quantum advantage by Cryptoanalytically-Relevant Quantum Computers (CRQCs). [https://arxiv.org/pdf/quant-ph/0301141 A variant of Shor's algorithm] is believed to be capable of deriving the private key from a public key exponentially faster than classical means. The application of this variant of Shor's algorithm is herein referred to as quantum key decryption. Note that doubling the public key length, such as with a hypothetical secp512k1 curve, would only make deriving the private key twice as hard. The computational complexity of this is investigated further in the paper, [https://pubs.aip.org/avs/aqs/article/4/1/013801/2835275/The-impact-of-hardware-specifications-on-reaching ''The impact of hardware specifications on reaching quantum advantage in the fault tolerant regime''].
 
-The primary threat to Bitcoin by CRQCs is [https://en.bitcoi.it/wiki/Quantum_computing_and_Bitcoin#QC_attacks generally considered to be their potential to break ECC, which is used in signatures and Taproot commitments], hence the focus on a new address format. Shor's algorithm enables a CRQC to break the cryptographic assumptions of ECC in roughly 10^8 quantum operations.
+The primary threat to Bitcoin by CRQCs is [https://en.bitcoin.it/wiki/Quantum_computing_and_Bitcoin#QC_attacks generally considered to be their potential to break ECC, which is used in signatures and Taproot commitments], hence the focus on a new address format. Shor's algorithm enables a CRQC to break the cryptographic assumptions of ECC in roughly 10^8 quantum operations.
 
-The vulnerability of existing bitcoin addresses is investigated in [https://web.archive.org/web/20240715101040/https://www2.deloitte.com/nl/nl/pages/innovatie/artikelen/quantum-computers-and-the-bitcoin-blockchain.html this Deloitte report]. The report estimates that in 2020 approximately 25% of the bitcoin supply is held within addresses vulnerable to quantum attack. As of the time of writing, that number is now closer to 20%. Additionally, cryptographer Pieter Wuille [https://x.com/pwuille/status/1108085284862713856 reasons] even more might be vulnerable.
+The vulnerability of existing Bitcoin addresses is investigated in [https://web.archive.org/web/20240715101040/https://www2.deloitte.com/nl/nl/pages/innovatie/artikelen/quantum-computers-and-the-bitcoin-blockchain.html this Deloitte report]. The report estimates that in 2020 approximately 25% of the Bitcoin supply is held within addresses vulnerable to quantum attack. As of the time of writing, that number is now closer to 20%. Additionally, cryptographer Pieter Wuille [https://x.com/pwuille/status/1108085284862713856 reasons] even more might be vulnerable.
 
 Ordinarily, when a transaction is signed, the public key can be recovered from the signature. This makes a transaction submitted to the mempool vulnerable to quantum attack until it's mined. One way to mitigate this is to submit the transaction directly to a mining pool, which bypasses the mempool. This process is known as an out-of-band transaction. The mining pool must be trusted not to reveal the transaction public key to attackers. The problem with this approach is that it requires a trusted third party, which is what this P2QRH proposal aims to avoid.
 
-Not having public keys exposed on-chain is an important step for quantum security. Otherwise funds would need to be spent to new addresses on a regular basis in order to prevent the possibility of a "long-range CRQC attack" recovering the key behind high value addresses. A long-range quantum attack can be considered one performed with chain data, such as that from a used address or one encoded in a spend script. This is likely to be more common early on, as early quantum computers must be run for longer in order to overcome errors caused by noise. A "short-range quantum attack" would be one performed on keys in the mempool, which is seen as much more difficult given the block time, and so it requires more sophisticated CRQCs. As the value being sent increases, so too should the fee in order to commit the transaction to the chain as soon as possible. Once the transaction is mined, it makes useless the public key revealed by spending a UTXO, so long as it is never reused.
+Not having public keys exposed on-chain is an important step for quantum security. Otherwise, funds would need to be spent to new addresses on a regular basis in order to prevent the possibility of a "long-range CRQC attack" recovering the key behind high-value addresses. A long-range quantum attack can be considered one performed with chain data, such as that from a used address or one encoded in a spend script. This is likely to be more common early on, as early quantum computers must be run for longer in order to overcome errors caused by noise. A "short-range quantum attack" would be one performed on keys in the mempool, which is seen as much more difficult given the block time, and so it requires more sophisticated CRQCs. As the value being sent increases, so too should the fee in order to commit the transaction to the chain as soon as possible. Once the transaction is mined, it makes useless the public key revealed by spending a UTXO, so long as it is never reused.
 
 It is proposed to implement a Pay to Quantum Resistant Hash (P2QRH) address type that relies on a PQC signature algorithm. This new address type protects transactions submitted to the mempool and helps preserve the free market by preventing the need for private, out-of-band mempool transactions.
 
-The following table is non-exhaustive but intended to inform the average bitcoin user whether their bitcoin is vulnerable to a long-range quantum attack.
+The following table is non-exhaustive but intended to inform the average Bitcoin user whether their bitcoin is vulnerable to a long-range quantum attack.
 
-{|
+{| class="wikitable"
 |+ Vulnerable address types
 |-
 ! Address type !! Vulnerable !! Prefix !! Example
@@ -58,7 +56,7 @@ If a key is recovered by a CRQC it can also be trivially checked to see if any c
 
 The following table summarizes the scenarios in which public keys are revealed when using Bitcoin and what type of attack the underlying addresses are vulnerable to:
 
-{|
+{| class="wikitable"
 |+ Scenarios for revealed public keys on Bitcoin
 |-
 ! Scenario !! Type of attack
@@ -80,15 +78,15 @@ Should quantum advantage manifest, a convention is proposed in spending the full
 
 As an interesting aside, coinbase outputs to P2PK keys go as far as block 200,000, so there are 1,723,848 coins that are vulnerable from the first epoch at the time of writing in P2PK outputs alone. Since the majority of these have a block reward of 50 coins each, there are roughly 34,000 distinct P2PK addresses that are vulnerable. These coins can be considered "Satoshi's Shield." Any addresses with a balance of less than the original block subsidy of 50 coins can be considered incentive incompatible to capture until all of these are mined, and these addresses serve to provide time to transition Bitcoin to implement post-quantum security.
 
-It's for the above reason that, for those who wish to be prepared for quantum emergency, it is recommended that no more than 50 bitcoin are kept under a single, distinct, unused Native SegWit (P2WPKH, "bc1q") address at a time. This is assuming that the attacker is financially-motivated instead of, for example, a nation state looking to break confidence in Bitcoin. Additionally, this assumes that other vulnerable targets such as central banks have upgraded their cryptography by this time.
+It's for the above reason that, for those who wish to be prepared for quantum emergency, it is recommended that no more than 50 bitcoin are kept under a single, distinct, unused Native SegWit (P2WPKH, "bc1q") address at a time. This is assuming that the attacker is financially motivated instead of, for example, a nation state looking to break confidence in Bitcoin. Additionally, this assumes that other vulnerable targets such as central banks have upgraded their cryptography by this time.
 
 The Commercial National Security Algorithm Suite (CNSA) 2.0 has a timeline for software and networking equipment to be upgraded by 2030, with browsers and operating systems fully upgraded by 2033. According to NIST IR 8547, Elliptic Curve Cryptography is planned to be disallowed within the US Federal government after 2035. An exception is made for hybrid cryptography, which is the use of ECC and post-quantum algorithms together.
 
-Although CRQCs could pose a threat to the signatures used in Bitcoin, a smaller threat is to Bitcoin's hash algorithms.  In particular, while a CRQC could use [https://en.wikipedia.org/wiki/Grover's_algorithm Grover's algorithm] to gain a quadratic speed up on brute force attacks on the hash functions used in Bitcoin, a significantly more powerful CRQC is needed for these attacks to meaningfully impact Bitcoin. For instance, a preimage attack on HASH160used by P2PKH, P2SH, and P2WPKH addresses, though not P2WSH because it uses 256-bit hashes using Grover's algorithm would require at least 10^24 quantum operations. As for Grover's application to mining, see [https://quantumcomputing.stackexchange.com/a/12847 Sam Jaques’ post on this].
+Although CRQCs could pose a threat to the signatures used in Bitcoin, a smaller threat is to Bitcoin's hash algorithms. In particular, while a CRQC could use [https://en.wikipedia.org/wiki/Grover's_algorithm Grover's algorithm] to gain a quadratic speedup on brute-force attacks on the hash functions used in Bitcoin, a significantly more powerful CRQC is needed for these attacks to meaningfully impact Bitcoin. For instance, a preimage attack on HASH160Used by P2PKH, P2SH, and P2WPKH addresses, though not P2WSH because it uses 256-bit hashes. using Grover's algorithm would require at least 1024 quantum operations. As for Grover's application to mining, see [https://quantumcomputing.stackexchange.com/a/12847 Sam Jaques’ post on this].
 
 === Rationale ===
 
-This is the first in a series of BIPs under a QuBit soft fork. A qubit is a fundamental unit of quantum computing, and the capital B refers to bitcoin. The name QuBit also rhymes to some extent with SegWit.
+This is the first in a series of BIPs under a QuBit soft fork. A qubit is a fundamental unit of quantum computing, and the capital B refers to Bitcoin. The name QuBit also rhymes to some extent with SegWit.
 
 It is proposed to use SegWit version 3. This results in addresses that start with bc1r, which could be a useful way to remember that these are quantum (r)esistant addresses (similar to how bc1q corresponds to Se(q)Wit and bc1p corresponds to Ta(p)root). This is referencing the lookup table under [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32 BIP-173].
 
@@ -98,11 +96,11 @@ P2QRH is meant to be implemented on top of P2TR, combining the security of class
 
 P2QRH uses a 32-byte HASH256 (specifically SHA-256 twice-over, which is similar to that used in [https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#specification BIP-16]) of the public key to reduce the size of new outputs and also to increase security by not having the public key available on-chain. This hash serves as a minimal cryptographic commitment to a public key. It goes into the output spend script, which does not receive the witness discount.
 
-Post-quantum public keys are generally larger than those used by ECC, depending on the security level. To promote user adoption and general user-friendliness, the most secure variant (NIST V, 256 bit) is proposed, despite the increase in key length and verification time.
+Post-quantum public keys are generally larger than those used by ECC, depending on the security level. To promote user adoption and general user-friendliness, the most secure variant (NIST Level V, 256-bit security) is proposed, despite the increase in key length and verification time.
 
 Support for FALCON signatures will be introduced first, with the intention of adding SQIsign and other post-quantum algorithms as they are approved. By way of comparison, FALCON signatures are roughly 4x larger than SQIsign signatures and 20x larger than Schnorr signatures. FALCON is a more conservative approach to applied lattice cryptography than SQIsign, and its use has recently been approved by NIST. NIST approval streamlines implementations through establishing consensus in the scientific and developer community. However, even SQIsign signatures are roughly 5x larger than Schnorr signatures. This means, to maintain present transaction throughput, an increase in the witness discount will likely be desired in a QuBit soft fork. That will be specified in a future QuBit BIP.
 
-An increase in the witness discount must not be taken lightly.  It must be resistant to applications that might take advantage of this discount (e.g. storage of arbitrary data as seen with "inscriptions") without a corresponding increase in economic activity. An increase in the witness discount would not only impact node runners but those with inscriptions would also have the scarcity of their non-monetary assets affected. The only way to prevent these affects while also increasing the discount is to have a completely separate witness-- a "quantum witness." Because it is meant only for public keys and signatures, we call this section of the transaction the attestation.
+An increase in the witness discount must not be taken lightly. It must be resistant to applications that might take advantage of this discount (e.g., storage of arbitrary data as seen with "inscriptions") without a corresponding increase in economic activity. An increase in the witness discount would not only impact node runners but those with inscriptions would also have the scarcity of their non-monetary assets affected. The only way to prevent these effects while also increasing the discount is to have a completely separate witness—a "quantum witness." Because it is meant only for public keys and signatures, we call this section of the transaction the attestation.
 
 To address the risk of arbitrary data being stored using P2QRH (QuBit) addresses, very specific rules will be applied to spending from the witness stack in SegWit v3 outputs. A fixed signature size will be necessary for spending the output, and the output must be spendable to be considered valid within node consensus. A fixed signature size will also be helpful to disambiguate between signature types without an additional version byte, as SQIsign signatures are substantially smaller than FALCON signatures. Consequently, the correct signature algorithm can be inferred through byte length. The public key and signature will be pushed separately to the attestation stack. Multiple signatures can be included in order to support multisig applications, and also for spending multiple inputs.
 
@@ -110,57 +108,48 @@ Since only valid signatures can be committed to in a SegWit v3 attestation, arbi
 
 Additionally, it should be noted, whether an output with a P2QRH spend script corresponds to a FALCON or SQIsign signature is not known until the output is spent.
 
-While it might be seen as a maintenance burden for bitcoin ecosystem devs to go from a single cryptosystem implementation to four additional distinct PQC cryptosystems-- and it most certainly is-- the ramifications of a chain broken through extrinsic factors should provide sufficient motivation. An increase in software maintenance everywhere signatures are used should be seen as an acceptable compromise for maintained integrity of bitcoin transfers during a regime of quantum advantage.
+While it might be seen as a maintenance burden for Bitcoin ecosystem devs to go from a single cryptosystem implementation to four additional distinct PQC cryptosystems—and it most certainly is—the ramifications of a chain broken through extrinsic factors should provide sufficient motivation. An increase in software maintenance everywhere signatures are used should be seen as an acceptable compromise for maintained integrity of Bitcoin transfers during a regime of quantum advantage.
 
-The inclusion of these four cryptosystems: SPHINCS, CRYSTALS-Dilithium, FALCON, and SQIsign have various advocates within the community due to their varying security assumptions. Hash-based cryptosystems are more conservative, time-tested, and well-reviewed. Lattice cryptography is relatively new and introduces novel security assumptions to Bitcoin, but their signatures are smaller and might be considered by some to be an adequate alternative to Hash-based signatures. SQIsign is much smaller, however, it is based on a very novel form of cryptography known as supersingular elliptic curve quaternion isogeny, and at the time of writing, is not yet approved by NIST or the broader PQC community.
+The inclusion of these four cryptosystems: SPHINCS+, CRYSTALS-Dilithium, FALCON, and SQIsign have various advocates within the community due to their varying security assumptions. Hash-based cryptosystems are more conservative, time-tested, and well-reviewed. Lattice cryptography is relatively new and introduces novel security assumptions to Bitcoin, but their signatures are smaller and might be considered by some to be an adequate alternative to hash-based signatures. SQIsign is much smaller; however, it is based on a very novel form of cryptography known as supersingular elliptic curve quaternion isogeny, and at the time of writing, is not yet approved by NIST or the broader PQC community.
 
 In the distant future, following the implementation of the P2QRH address format in a QuBit soft fork, there will likely be a need for Pay to Quantum Secure (P2QS) addresses. These will require specialized quantum hardware for signing, while still [https://quantum-journal.org/papers/q-2023-01-19-901/ using public keys that are verifiable via classical means]. Additional follow-on BIPs will be needed to implement P2QS. However, until specialized quantum cryptography hardware is widespread, quantum resistant addresses should be an adequate intermediate solution.
 
+== Specification ==
 
-== Description ==
-
-We first build up a definition of the signature scheme by going through the design choices. Afterwards, we specify the exact encodings and operations.
-
-
-=== Design ===
+We define the signature scheme and transaction structure as follows.
 
-==== Descriptor Format ====
+=== Descriptor Format ===
 
 To integrate P2QRH into existing wallet software and scripts, we introduce a new output descriptor function qrh(). This function represents a P2QRH output, similar to how wpkh() and tr() are used for P2WPKH and P2TR outputs, respectively.
 
 The qrh() function takes the HASH256 of the concatenated HASH256 of the quantum-resistant public keys as its argument. For example:
 
-
-qrh(HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ...))
-
-
-The above function allows wallets to manage P2QRH addresses and outputs while accommodating multiple public keys of varying lengths, such as in multisig schemes, while keeping the public keys hidden until the time of spending.
+qrh(HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ...))
 
+This function allows wallets to manage P2QRH addresses and outputs while accommodating multiple public keys of varying lengths, such as in multisig schemes, while keeping the public keys hidden until the time of spending.
 
-==== Address Format ====
+=== Address Format ===
 
-P2QRH uses SegWit version 3 outputs, resulting in addresses that start with bc1r, following [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32 BIP-173]. Bech32 encoding maps version 3 to the prefix r.
+P2QRH uses SegWit version 3 outputs, resulting in addresses that start with bc1r, following [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32 BIP-173]. Bech32 encoding maps version 3 to the prefix r.
 
 Example P2QRH address:
 
-
-bc1r... (32-byte Bech32m-encoded HASH256 of the HASH256 of the public keys)
-
+bc1r... (32-byte Bech32m-encoded HASH256 of the HASH256 of the public keys)
 
-==== ScriptPubKey ====
+=== ScriptPubKey ===
 
 The scriptPubKey for a P2QRH output is:
 
-
+
 OP_PUSHNUM_3 OP_PUSHBYTES_32 
-
+

 
 Where:
 
-* OP_PUSHNUM_3 (0x03) indicates SegWit version 3.
-*  is the 32-byte HASH256 of the concatenated HASH256 of each public key.
+- OP_PUSHNUM_3 (0x03) indicates SegWit version 3.
+-  is the 32-byte HASH256 of the concatenated HASH256 of each public key.
 
-===== Hash Computation =====
+==== Hash Computation ====
 
 
 hash = HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN))
@@ -168,128 +157,68 @@ hash = HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN))
 
 This construction creates a cryptographic commitment to multiple public keys.
 
-==== Transaction Serialization ====
+=== Transaction Serialization ===
 
 Following BIP-141, the transaction serialization is modified to include a new attestation field after the witness field:
 
-
+
 [nVersion][marker][flag][txins][txouts][witness][attestation][nLockTime]
-
+

 
-* marker: 0x00 (same as SegWit)
-* flag: 0x02 (indicates the presence of both witness and attestation data)
-* attestation: Contains the quantum-resistant public keys and signatures.
+- marker: 0x00 (same as SegWit)
+- flag: 0x02 (indicates the presence of both witness and attestation data)
+- attestation: Contains the quantum-resistant public keys and signatures.
 
-==== Attestation Structure ====
+=== Attestation Structure ===
 
 The attestation field consists of:
 
 * num_pubkeys: The number of public keys (VarInt encoded).
-* For each public key:
-** pubkey_length: VarInt encoded length of the public key.
-** pubkey: The public key bytes.
+
+For each public key:
+
+* pubkey_length: VarInt encoded length of the public key.
+* pubkey: The public key bytes.
+
+Then:
+
 * num_signatures: The number of signatures (VarInt encoded).
-* For each signature:
-** signature_length: VarInt encoded length of the signature.
-** signature: The signature bytes.
+
+For each signature:
+
+* signature_length: VarInt encoded length of the signature.
+* signature: The signature bytes.
 
 This structure repeats for each input, in order, for flexibility in supporting multisig schemes and various quantum-resistant algorithms.
 
 For each input, a separate attestation field is used. To know how many attestation fields are present, implementations must count the number of inputs present in the transaction.
 
-The specific algorithm is determined by the size of the public key and signature, as described in the next section.
-
-==== Signature Algorithm Identification ====
+=== Signature Algorithm Identification ===
 
 The specific quantum-resistant signature algorithm used is inferred from the length of the public key and signature. Implementations must recognize the supported algorithms and validate accordingly.
 
 Supported algorithms and their NIST Level V parameters:
 
 * '''SPHINCS+-256f:'''
-** Public Key Length: 64 bytes
-** Signature Length: 49,856 bytes
-* '''CRYSTALS-Dilithium Level 5''':
-** Public Key Length: 2,592 bytes
-** Signature Length: 4,595 bytes
-* '''FALCON-1024''':
-** Public Key Length: 1,793 bytes
-** Signature Length: 1,280 bytes
-* '''SQIsign NIST-V''':
-** Public Key Length: 128 bytes
-** Signature Length: 335 bytes
+  * Public Key Length: 64 bytes
+  * Signature Length: 49,856 bytes
+* '''CRYSTALS-Dilithium Level 5:'''
+  * Public Key Length: 2,592 bytes
+  * Signature Length: 4,595 bytes
+* '''FALCON-1024:'''
+  * Public Key Length: 1,793 bytes
+  * Signature Length: 1,280 bytes
+* '''SQIsign NIST-V:'''
+  * Public Key Length: 128 bytes
+  * Signature Length: 335 bytes
 
 Implementations must reject public keys and signatures that do not match expected lengths for supported algorithms.
 
-==== Compatibility with BIP-141 ====
-
-By adhering to the SegWit transaction structure and versioning, P2QRH outputs are compatible with existing transaction processing rules. Nodes that do not recognize SegWit version 3 will treat these outputs as anyone-can-spend but, per BIP-141, will not relay or mine such transactions.
-
-
-== Security ==
-
-{|
-|+ Candidate quantum resistant signature algorithms ordered by largest to smallest NIST V signature size
-|-
-! Signature Algorithm !! Year First Introduced !! Signature Size !! Public Key Size || Cryptographic Assumptions
-|-
-| [https://en.wikipedia.org/wiki/Lamport_signature Lamport signature] || 1977 || 8192 bytes || 16384 bytes || Hash-based cryptography
-|-
-| [https://eprint.iacr.org/2011/191.pdf Winternitz signature] || 1982 || 2368 bytes* || 2368 bytesFootnote: Winternitz signatures are much smaller than Lamport signatures due to efficient chunking, but computation is much higher, especially with high values for w. Winternitz values are for w of 4. || Hash-based cryptography
-|-
-| [https://sphincs.org/data/sphincs+-r3.1-specification.pdf SPHINCS+ Rd. 3.1 (FIPS 205 - SLH-DSA)] || 2015 || 29792 bytes || 64 bytes || Hash-based cryptography
-|-
-| [https://eprint.iacr.org/2011/484.pdf XMSS]XMSS, which is based on Winternitz, uses a value of 108 for its most compact signature size, with only a 4.6x (2.34/0.51) increase in verification time. Signing and key generation are not considered a significant factor because they are not distributed throughout the entire Bitcoin network, which take place only inside of wallets one time. || 2011 || 15384 bytes || 13568 bytes || Hash-based cryptography (Winternitz OTS)
-|-
-| [https://pq-crystals.org/dilithium/ CRYSTALS-Dilithium (FIPS 204 - ML-DSA)] || 2017 || 4595 bytes || 2592 bytes || Lattice cryptography
-|-
-| [https://eprint.iacr.org/2014/457.pdf pqNTRUsign] || 2016 || 1814 bytes || 1927 bytes || Lattice cryptography (NTRU)
-|-
-| [https://falcon-sign.info FALCON (FIPS 206 - FN-DSA)] || 2017 || 1280 bytes || 1793 bytes || Lattice cryptography (NTRU)
-|-
-| [https://eprint.iacr.org/2022/1155.pdf HAWK] || 2022 || 1261 bytes || 2329 bytes || Lattice cryptography
-|-
-| [https://sqisign.org SQIsign] || 2023 || 335 bytes || 128 bytes || Supersingular Elliptic Curve Isogeny
-|-
-| [https://eprint.iacr.org/2024/760.pdf SQIsign2D-West] || 2024 || 294 bytes || 130 bytes || Supersingular Elliptic Curve Isogeny
-|-
-| [https://eprint.iacr.org/2023/436.pdf SQIsignHD] || 2023 || 109 bytes (NIST I) || not provided || Supersingular Elliptic Curve Isogeny
-|}
-
-
-As shown, supersingular elliptic curve quaternion isogeny signature algorithms represent the state of the art in post-quantum cryptography, beyond lattice cryptography alone, especially when key and signature length are major constraints. This makes inclusion of SQIsign attractive, and support is planned, but it will be some time until it is approved for production use. Meanwhile, SPHINCS+ and CRYSTALS-Dilithium signatures are already approved and have achieved broader community consensus.  FALCON signatures are also NIST approved.
-
-In comparison, the size of currently used signature algorithms are:
-
-* ECDSA - 70-72 bytes
-* Schnorr - 64 bytes
-
-In comparison to inception date, secp256k1 [https://www.secg.org/SEC1-Ver-1.0.pdf was originally specified in 2000].
-
-One consideration for choosing an algorithm is its maturity. secp256k1 was already 8 years old by the time it was chosen as bitcoin's curve. Isogeny cryptography when it was first introduced was broken over a weekend.
-
-Ideally SQIsign also proves to be flexible enough to support [https://www.pierrickdartois.fr/homepage/wp-content/uploads/2022/04/Report_OSIDH_DARTOIS.pdf Isogeny Diffie-Hellman] to replace ECDH applications, and also provide methods for the key tweaking necessary to support TapScript for P2QR addresses. Additionally, isogeny-based post-quantum cryptography is based on higher-order elliptic curves, and so it might be possible to implement Isogeny Schnorr signatures.
-
-Signature verification speed as it compares to Schnorr or ECDSA isn't seen as high a consideration as signature size due to block space being the primary fee constraint. As a P2QRH implementation materializes, a benchmark will be added for performance comparison. Fortunately, SQIsign signatures are substantially faster to verify than it is to generate keys or to sign, which is a major consideration when a transaction need only be signed once, or a handful of times with PSBT, compared to being verified simultaneously on tens of thousands of nodes. Key generation may need to cached in BIP-32 Hierarchical Deterministic wallets.
-
-An additional consideration is security level. Longer signature sizes provide more security. NIST has standardized five security levels for post-quantum cryptography. NIST security level I provides security equivalent to 128-bit keys, and security level V provides 256-bit security.
-
-
-== Specification ==
-
-How the attestation is differentiated from the witness can be accomplished similar to how [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#user-content-Transaction_ID BIP-141] introduced the marker and flag, with the QuBit flag being set to 0x02. This means all QuBit transactions are also SegWit transactions. The additional data would be included as a second array of byte arrays following the witness stack.
-
-32-byte attestation fields are assumed to be Schnorr public keys for Taproot fields because they are ordinarily included in the spend script, but they cannot be included in P2QRH for security reasons. Public key / signature pairs for Taproot fields come before QuBit public key / signature pairs.
-
-The exact key type is inferred by its size, as provided by the attestation variant pair, which determines whether it's processed as secp256k1 Schnorr, SPHINCS, CRYSTALS-Dilithium, FALCON, or SQIsign.
-
-If the transaction fails to include the public keys needed to match the spend script hash, it is an invalid transaction because the cryptographic commitment for the keys has not been met. Consequently, only valid public keys and signatures can be included within the attestation and no other data.
-
-
 === Script Validation ===
 
 To spend a P2QRH output, the following conditions must be met:
 
-1. The scriptPubKey must be of the form:
+1. The scriptPubKey must be of the form:
 
 
 OP_PUSHNUM_3 <32-byte hash>
@@ -297,16 +226,14 @@ OP_PUSHNUM_3 <32-byte hash>
 
 2. The attestation must include:
 
-* The quantum-resistant public key(s) whose HASH256 concatenated and hashed again matches the  in the scriptPubKey.
+* The quantum-resistant public key(s) whose HASH256 concatenated and hashed again matches the  in the scriptPubKey.
 * Valid signatures corresponding to the public key(s) and the transaction data.
 
 3. For multi-signature schemes, all required public keys and signatures must be provided for that input within the attestation. This includes classical Schnorr signatures.
 
-
 ==== Public Key Hashing ====
 
-All public keys included in the attestation are hashed using HASH256 (double SHA-256). The concatenation of these hashes is then hashed again using HASH256 before being included in the scriptPubKey. This ensures a fixed-size commitment to potentially multiple public keys of varying lengths.
-
+All public keys included in the attestation are hashed using HASH256 (double SHA-256). The concatenation of these hashes is then hashed again using HASH256 before being included in the scriptPubKey. This ensures a fixed-size commitment to potentially multiple public keys of varying lengths.
 
 ==== Hash Computation ====
 
@@ -314,7 +241,6 @@ All public keys included in the attestation are hashed using HASH256 (double SHA
 hash = HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN))
 

 
-
 ==== Sighash Calculation ====
 
 The sighash for P2QRH outputs follows the same procedure as defined in BIP-0143 for SegWit transactions:
@@ -333,19 +259,19 @@ Signature verification is as follows:
 
 2. For each input:
 
-   * Compute hashed_pubkeys by concatenating the HASH256 of each provided public key:
+* Compute hashed_pubkeys by concatenating the HASH256 of each provided public key:
 
-     
-hashed_pubkeys = HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN)
-     

+
+  hashed_pubkeys = HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN)
+

 
-   * Compute computed_hash:
+* Compute computed_hash:
 
-     
-computed_hash = HASH256(hashed_pubkeys)
-     

+
+  computed_hash = HASH256(hashed_pubkeys)
+

 
-   * Compare the resulting hash to . If they do not match, the script fails.
+* Compare the resulting hash to . If they do not match, the script fails.
 
 3. Verify each signature against the corresponding public key and the sighash.
 
@@ -379,39 +305,84 @@ Signature 2:
 
 Note: This contrasts with multisig inputs, where the attestation structure repeats for each public key and signature.
 
+=== Compatibility with BIP-141 ===
+
+By adhering to the SegWit transaction structure and versioning, P2QRH outputs are compatible with existing transaction processing rules. Nodes that do not recognize SegWit version 3 will treat these outputs as anyone-can-spend but, per BIP-141, will not relay or mine such transactions.
+
 === Usage Considerations ===
 
 ==== Transaction Size and Fees ====
 
 Quantum-resistant signatures are significantly larger than traditional signatures, increasing transaction size and the fees required. Users and wallet developers should be aware of this and plan accordingly.
 
-For example, for CRYSTALS-Dilithium Level V, a single signature is 4595 bytes, a substantial increase over current ECDSA or Schnorr signatures.
-
+For example, for CRYSTALS-Dilithium Level V, a single signature is 4,595 bytes, a substantial increase over current ECDSA or Schnorr signatures.
 
 ==== Performance Impact ====
 
 Verification of quantum-resistant signatures will be computationally more intensive, and any attestation discount will also increase storage requirements. Node operators should consider the potential impact on resource usage in the long term. Developers may need to optimize signature verification implementations, especially by implementing caching for key generation.
 
-
 ==== Algorithm Selection ====
 
-Introducing four quantum-resistant algorithms to the bitcoin ecosystem provides users with the option to select an appropriate algorithm for their use case, generally based on the amount of value they wish to secure. Developers can choose to implement support for multiple algorithms in wallets and on nodes to offer quantum-resistant options.
-
+Introducing four quantum-resistant algorithms to the Bitcoin ecosystem provides users with the option to select an appropriate algorithm for their use case, generally based on the amount of value they wish to secure. Developers can choose to implement support for multiple algorithms in wallets and on nodes to offer quantum-resistant options.
 
 ==== Backward Compatibility ====
 
 Older wallets and nodes that have not been made compatible with SegWit version 3 and P2QRH will not recognize these outputs. Users should ensure they are using updated wallets and nodes to use P2QRH addresses and validate transactions using P2QRH outputs.
 
+== Security ==
+
+{| class="wikitable"
+|+ Candidate quantum-resistant signature algorithms ordered by largest to smallest NIST Level V signature size
+|-
+! Signature Algorithm !! Year First Introduced !! Signature Size !! Public Key Size !! Cryptographic Assumptions
+|-
+| [https://en.wikipedia.org/wiki/Lamport_signature Lamport signature] || 1977 || 8,192 bytes || 16,384 bytes || Hash-based cryptography
+|-
+| [https://eprint.iacr.org/2011/191.pdf Winternitz signature] || 1982 || 2,368 bytesWinternitz signatures are much smaller than Lamport signatures due to efficient chunking, but computation is much higher, especially with high values for w. Winternitz values are for w of 4. || 2,368 bytes || Hash-based cryptography
+|-
+| [https://sphincs.org/data/sphincs+-r3.1-specification.pdf SPHINCS+ Rd. 3.1 (FIPS 205 - SLH-DSA)] || 2015 || 29,792 bytes || 64 bytes || Hash-based cryptography
+|-
+| [https://eprint.iacr.org/2011/484.pdf XMSS]XMSS, which is based on Winternitz, uses a value of 108 for its most compact signature size, with only a 4.6x (2.34/0.51) increase in verification time. Signing and key generation are not considered a significant factor because they are not distributed throughout the entire Bitcoin network, which take place only inside of wallets one time. || 2011 || 15,384 bytes || 13,568 bytes || Hash-based cryptography (Winternitz OTS)
+|-
+| [https://pq-crystals.org/dilithium/ CRYSTALS-Dilithium (FIPS 204 - ML-DSA)] || 2017 || 4,595 bytes || 2,592 bytes || Lattice cryptography
+|-
+| [https://eprint.iacr.org/2014/457.pdf pqNTRUsign] || 2016 || 1,814 bytes || 1,927 bytes || Lattice cryptography (NTRU)
+|-
+| [https://falcon-sign.info FALCON (FIPS 206 - FN-DSA)] || 2017 || 1,280 bytes || 1,793 bytes || Lattice cryptography (NTRU)
+|-
+| [https://eprint.iacr.org/2022/1155.pdf HAWK] || 2022 || 1,261 bytes || 2,329 bytes || Lattice cryptography
+|-
+| [https://sqisign.org SQIsign] || 2023 || 335 bytes || 128 bytes || Supersingular Elliptic Curve Isogeny
+|-
+| [https://eprint.iacr.org/2024/760.pdf SQIsign2D-West] || 2024 || 294 bytes || 130 bytes || Supersingular Elliptic Curve Isogeny
+|-
+| [https://eprint.iacr.org/2023/436.pdf SQIsignHD] || 2023 || 109 bytes (NIST Level I) || Not provided || Supersingular Elliptic Curve Isogeny
+|}
+
+As shown, supersingular elliptic curve quaternion isogeny signature algorithms represent the state of the art in post-quantum cryptography, beyond lattice cryptography alone, especially when key and signature length are major constraints. This makes inclusion of SQIsign attractive, and support is planned, but it will be some time until it is approved for production use. Meanwhile, SPHINCS+ and CRYSTALS-Dilithium signatures are already approved and have achieved broader community consensus. FALCON signatures are also NIST approved.
+
+In comparison, the size of currently used signature algorithms are:
+
+- ECDSA: 70-72 bytes
+- Schnorr: 64 bytes
+
+In comparison to inception date, secp256k1 [https://www.secg.org/SEC1-Ver-1.0.pdf was originally specified in 2000].
+
+One consideration for choosing an algorithm is its maturity. secp256k1 was already 8 years old by the time it was chosen as Bitcoin's curve. Isogeny cryptography when it was first introduced was broken over a weekend.
+
+Ideally SQIsign also proves to be flexible enough to support [https://www.pierrickdartois.fr/homepage/wp-content/uploads/2022/04/Report_OSIDH_DARTOIS.pdf Isogeny Diffie-Hellman] to replace ECDH applications, and also provide methods for the key tweaking necessary to support TapScript for P2QR addresses. Additionally, isogeny-based post-quantum cryptography is based on higher-order elliptic curves, and so it might be possible to implement Isogeny Schnorr signatures.
+
+Signature verification speed as it compares to Schnorr or ECDSA isn't seen as high a consideration as signature size due to block space being the primary fee constraint. As a P2QRH implementation materializes, a benchmark will be added for performance comparison. Fortunately, SQIsign signatures are substantially faster to verify than it is to generate keys or to sign, which is a major consideration when a transaction need only be signed once, or a handful of times with PSBT, compared to being verified simultaneously on tens of thousands of nodes. Key generation may need to be cached in BIP-32 Hierarchical Deterministic wallets.
+
+An additional consideration is security level. Longer signature sizes provide more security. NIST has standardized five security levels for post-quantum cryptography. NIST security level I provides security equivalent to 128-bit keys, and security level V provides 256-bit security.
 
 == Test Vectors and Reference Code ==
 
 TBD
 
-
 == Related Work ==
 
-It is worth noting by way of comparison that [https://ethresear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/18901 Vitalik Buterin's proposed solution] in an Ethereum quantum emergency is quite different from the approach in this BIP. His plan involves a hard fork of the chain, reverting all blocks after a sufficient amount of theft, and using STARKs based on BIP-32 seeds to act as the authoritative secret when signing. These measures are deemed far too heavy-handed for bitcoin.
-
+It is worth noting by way of comparison that [https://ethresear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/18901 Vitalik Buterin's proposed solution] in an Ethereum quantum emergency is quite different from the approach in this BIP. His plan involves a hard fork of the chain, reverting all blocks after a sufficient amount of theft, and using STARKs based on BIP-32 seeds to act as the authoritative secret when signing. These measures are deemed far too heavy-handed for Bitcoin.
 
 == References ==
 
@@ -420,12 +391,10 @@ It is worth noting by way of comparison that [https://ethresear.ch/t/how-to-hard
 * [https://bitcoinops.org/en/newsletters/2024/06/14/ Bitcoin OpTech newsletter]
 * [https://bitcoinops.org/en/podcast/2024/06/18/#draft-bip-for-quantum-safe-address-format Bitcoin OpTech discussion transcript]
 
-
 == Footnotes ==
 
 
 
-
 == Changelog ==
 
 To help implementors understand updates to this BIP, we keep a list of substantial changes.
@@ -436,10 +405,9 @@ To help implementors understand updates to this BIP, we keep a list of substanti
 * 2024-10-21 - Replace XMSS with CRYSTALS-Dilithium due to NIST approval and size constraints.
 * 2024-09-30 - Refactor the ECC vs PoW section. Swap quitness for attestation.
 * 2024-09-29 - Update section on PoW to include partial-preimage.
-* 2024-09-28 - Add Winternitz, XMSS signatures, and security assumption types to PQC table. Omit NIST I table. Add spend script specification. Add revealed public key scenario table.
+* 2024-09-28 - Add Winternitz, XMSS signatures, and security assumption types to PQC table. Omit NIST Level I table. Add spend script specification. Add revealed public key scenario table.
 * 2024-09-27 - Initial draft proposal
 
-
 == Acknowledgements ==
 
 This document is inspired by [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP-341], which introduced the design of the P2TR (Taproot) address type using Schnorr signatures.

From f2426c66569a93b393da0f9a9d535184306640d1 Mon Sep 17 00:00:00 2001
From: Hunter Trujillo 
Date: Fri, 6 Dec 2024 10:08:27 -0700
Subject: [PATCH 13/32] Update title and formatting.

---
 bip-p2qrh.mediawiki | 361 +++++++++++++++++++++++++++++++++-----------
 1 file changed, 269 insertions(+), 92 deletions(-)

diff --git a/bip-p2qrh.mediawiki b/bip-p2qrh.mediawiki
index f79473c28f..45f6427b24 100644
--- a/bip-p2qrh.mediawiki
+++ b/bip-p2qrh.mediawiki
@@ -1,6 +1,6 @@
 
   BIP: TBD
-  Title: QuBit - P2QRH spending rules
+  Title: QuBit: SegWit version 3 spending rules (P2QRH)
   Author: Hunter Beast 
   Comments-Summary: No comments yet.
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-TBD
@@ -14,7 +14,8 @@
 
 === Abstract ===
 
-This document proposes the introduction of a new output type using signatures based on Post-Quantum Cryptography (PQC). This approach for adding a post-quantum secure output type does not require a hard fork or block size increase.
+This document proposes the introduction of a new output type using signatures based on Post-Quantum Cryptography (PQC).
+This approach for adding a post-quantum secure output type does not require a hard fork or block size increase.
 
 === Copyright ===
 
@@ -22,26 +23,60 @@ This document is licensed under the 3-clause BSD license.
 
 === Motivation ===
 
-This proposal aims to improve the quantum resistance of Bitcoin's signature security should the Discrete Logarithm Problem (DLP), which secures Elliptic Curve Cryptography (ECC), no longer prove to be computationally hard, likely through quantum advantage by Cryptoanalytically-Relevant Quantum Computers (CRQCs). [https://arxiv.org/pdf/quant-ph/0301141 A variant of Shor's algorithm] is believed to be capable of deriving the private key from a public key exponentially faster than classical means. The application of this variant of Shor's algorithm is herein referred to as quantum key decryption. Note that doubling the public key length, such as with a hypothetical secp512k1 curve, would only make deriving the private key twice as hard. The computational complexity of this is investigated further in the paper, [https://pubs.aip.org/avs/aqs/article/4/1/013801/2835275/The-impact-of-hardware-specifications-on-reaching ''The impact of hardware specifications on reaching quantum advantage in the fault tolerant regime''].
-
-The primary threat to Bitcoin by CRQCs is [https://en.bitcoin.it/wiki/Quantum_computing_and_Bitcoin#QC_attacks generally considered to be their potential to break ECC, which is used in signatures and Taproot commitments], hence the focus on a new address format. Shor's algorithm enables a CRQC to break the cryptographic assumptions of ECC in roughly 10^8 quantum operations.
-
-The vulnerability of existing Bitcoin addresses is investigated in [https://web.archive.org/web/20240715101040/https://www2.deloitte.com/nl/nl/pages/innovatie/artikelen/quantum-computers-and-the-bitcoin-blockchain.html this Deloitte report]. The report estimates that in 2020 approximately 25% of the Bitcoin supply is held within addresses vulnerable to quantum attack. As of the time of writing, that number is now closer to 20%. Additionally, cryptographer Pieter Wuille [https://x.com/pwuille/status/1108085284862713856 reasons] even more might be vulnerable.
-
-Ordinarily, when a transaction is signed, the public key can be recovered from the signature. This makes a transaction submitted to the mempool vulnerable to quantum attack until it's mined. One way to mitigate this is to submit the transaction directly to a mining pool, which bypasses the mempool. This process is known as an out-of-band transaction. The mining pool must be trusted not to reveal the transaction public key to attackers. The problem with this approach is that it requires a trusted third party, which is what this P2QRH proposal aims to avoid.
-
-Not having public keys exposed on-chain is an important step for quantum security. Otherwise, funds would need to be spent to new addresses on a regular basis in order to prevent the possibility of a "long-range CRQC attack" recovering the key behind high-value addresses. A long-range quantum attack can be considered one performed with chain data, such as that from a used address or one encoded in a spend script. This is likely to be more common early on, as early quantum computers must be run for longer in order to overcome errors caused by noise. A "short-range quantum attack" would be one performed on keys in the mempool, which is seen as much more difficult given the block time, and so it requires more sophisticated CRQCs. As the value being sent increases, so too should the fee in order to commit the transaction to the chain as soon as possible. Once the transaction is mined, it makes useless the public key revealed by spending a UTXO, so long as it is never reused.
-
-It is proposed to implement a Pay to Quantum Resistant Hash (P2QRH) address type that relies on a PQC signature algorithm. This new address type protects transactions submitted to the mempool and helps preserve the free market by preventing the need for private, out-of-band mempool transactions.
-
-The following table is non-exhaustive but intended to inform the average Bitcoin user whether their bitcoin is vulnerable to a long-range quantum attack.
+This proposal aims to improve the quantum resistance of Bitcoin's signature security should the Discrete Logarithm
+Problem (DLP), which secures Elliptic Curve Cryptography (ECC), no longer prove to be computationally hard, likely
+through quantum advantage by Cryptoanalytically-Relevant Quantum Computers (CRQCs).
+[https://arxiv.org/pdf/quant-ph/0301141 A variant of Shor's algorithm] is believed to be capable of deriving the
+private key from a public key exponentially faster than classical means. The application of this variant of Shor's
+algorithm is herein referred to as quantum key decryption. Note that doubling the public key length, such as with a
+hypothetical secp512k1 curve, would only make deriving the private key twice as hard. The computational complexity of
+this is investigated further in the paper,
+[https://pubs.aip.org/avs/aqs/article/4/1/013801/2835275/The-impact-of-hardware-specifications-on-reaching ''The impact
+of hardware specifications on reaching quantum advantage in the fault tolerant regime''].
+
+The primary threat to Bitcoin by CRQCs is [https://en.bitcoin.it/wiki/Quantum_computing_and_Bitcoin#QC_attacks
+generally considered to be their potential to break ECC, which is used in signatures and Taproot commitments], hence
+the focus on a new address format. Shor's algorithm enables a CRQC to break the cryptographic assumptions of ECC in
+roughly 10^8 quantum operations.
+
+The vulnerability of existing Bitcoin addresses is investigated in
+[https://web.archive.org/web/20240715101040/https://www2.deloitte.com/nl/nl/pages/innovatie/artikelen/quantum-computers-
+and-the-bitcoin-blockchain.html this Deloitte report]. The report estimates that in 2020 approximately 25% of the
+Bitcoin supply is held within addresses vulnerable to quantum attack. As of the time of writing, that number is now
+closer to 20%. Additionally, cryptographer Pieter Wuille [https://x.com/pwuille/status/1108085284862713856 reasons]
+even more might be vulnerable.
+
+Ordinarily, when a transaction is signed, the public key can be recovered from the signature. This makes a transaction
+submitted to the mempool vulnerable to quantum attack until it's mined. One way to mitigate this is to submit the
+transaction directly to a mining pool, which bypasses the mempool. This process is known as an out-of-band transaction.
+The mining pool must be trusted not to reveal the transaction public key to attackers. The problem with this approach
+is that it requires a trusted third party, which is what this P2QRH proposal aims to avoid.
+
+Not having public keys exposed on-chain is an important step for quantum security. Otherwise, funds would need to be
+spent to new addresses on a regular basis in order to prevent the possibility of a "long-range CRQC attack" recovering
+the key behind high-value addresses. A long-range quantum attack can be considered one performed with chain data, such
+as that from a used address or one encoded in a spend script. This is likely to be more common early on, as early
+quantum computers must be run for longer in order to overcome errors caused by noise. A "short-range quantum attack"
+would be one performed on keys in the mempool, which is seen as much more difficult given the block time, and so it
+requires more sophisticated CRQCs. As the value being sent increases, so too should the fee in order to commit the
+transaction to the chain as soon as possible. Once the transaction is mined, it makes useless the public key revealed
+by spending a UTXO, so long as it is never reused.
+
+It is proposed to implement a Pay to Quantum Resistant Hash (P2QRH) address type that relies on a PQC signature
+algorithm. This new address type protects transactions submitted to the mempool and helps preserve the free market by
+preventing the need for private, out-of-band mempool transactions.
+
+The following table is non-exhaustive but intended to inform the average Bitcoin user whether their bitcoin is
+vulnerable to a long-range quantum attack.
 
 {| class="wikitable"
 |+ Vulnerable address types
 |-
 ! Address type !! Vulnerable !! Prefix !! Example
 |-
-| P2PK || Yes || 04 || 0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f8141781e62294721166bf621e73a82cbf2342c858ee
+| P2PK || Yes || 04 ||
+0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f8141781e62294721166bf621e73a82cbf
+2342c858ee
 |-
 | P2PKH || No || 1 || 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
 |-
@@ -50,11 +85,14 @@ The following table is non-exhaustive but intended to inform the average Bitcoin
 | P2TR || Yes || bc1p || bc1p92aslsnseq786wxfk3ekra90ds9ku47qttupfjsqmmj4z82xdq4q3rr58u
 |}
 
-It should be noted that Taproot addresses are vulnerable in that they encode a 32-byte x-only public key, from which a full public key can be reconstructed.
+It should be noted that Taproot addresses are vulnerable in that they encode a 32-byte x-only public key, from which a
+full public key can be reconstructed.
 
-If a key is recovered by a CRQC it can also be trivially checked to see if any child keys were produced using an unhardened [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-32] derivation path.
+If a key is recovered by a CRQC it can also be trivially checked to see if any child keys were produced using an
+unhardened [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-32] derivation path.
 
-The following table summarizes the scenarios in which public keys are revealed when using Bitcoin and what type of attack the underlying addresses are vulnerable to:
+The following table summarizes the scenarios in which public keys are revealed when using Bitcoin and what type of
+attack the underlying addresses are vulnerable to:
 
 {| class="wikitable"
 |+ Scenarios for revealed public keys on Bitcoin
@@ -72,47 +110,122 @@ The following table summarizes the scenarios in which public keys are revealed w
 | Unhardened BIP-32 HD wallet keys || Both Long-range or Short-range
 |}
 
-The only time a short-range attack can occur is when the transaction is in the mempool, whereas a long-range attack occurs when the public key is known well in advance. Short-range attacks require much larger, more expensive CRQCs.
-
-Should quantum advantage manifest, a convention is proposed in spending the full 65-byte P2PK key used by the coinbase output in Block 1 back to itself. It is proposed to call the address in Block 1 the [https://mempool.space/address/0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f8141781e62294721166bf621e73a82cbf2342c858ee Canary address] since it can only be spent from by others (assuming Satoshi's continued absence) if secp256k1 is broken. Should the Canary coins move, that will signal that reliance on secp256k1 is presently vulnerable. Without the Canary, or an address like it, there may be some doubt as to whether the coins were moved with keys belonging to the original owner.
-
-As an interesting aside, coinbase outputs to P2PK keys go as far as block 200,000, so there are 1,723,848 coins that are vulnerable from the first epoch at the time of writing in P2PK outputs alone. Since the majority of these have a block reward of 50 coins each, there are roughly 34,000 distinct P2PK addresses that are vulnerable. These coins can be considered "Satoshi's Shield." Any addresses with a balance of less than the original block subsidy of 50 coins can be considered incentive incompatible to capture until all of these are mined, and these addresses serve to provide time to transition Bitcoin to implement post-quantum security.
-
-It's for the above reason that, for those who wish to be prepared for quantum emergency, it is recommended that no more than 50 bitcoin are kept under a single, distinct, unused Native SegWit (P2WPKH, "bc1q") address at a time. This is assuming that the attacker is financially motivated instead of, for example, a nation state looking to break confidence in Bitcoin. Additionally, this assumes that other vulnerable targets such as central banks have upgraded their cryptography by this time.
-
-The Commercial National Security Algorithm Suite (CNSA) 2.0 has a timeline for software and networking equipment to be upgraded by 2030, with browsers and operating systems fully upgraded by 2033. According to NIST IR 8547, Elliptic Curve Cryptography is planned to be disallowed within the US Federal government after 2035. An exception is made for hybrid cryptography, which is the use of ECC and post-quantum algorithms together.
-
-Although CRQCs could pose a threat to the signatures used in Bitcoin, a smaller threat is to Bitcoin's hash algorithms. In particular, while a CRQC could use [https://en.wikipedia.org/wiki/Grover's_algorithm Grover's algorithm] to gain a quadratic speedup on brute-force attacks on the hash functions used in Bitcoin, a significantly more powerful CRQC is needed for these attacks to meaningfully impact Bitcoin. For instance, a preimage attack on HASH160Used by P2PKH, P2SH, and P2WPKH addresses, though not P2WSH because it uses 256-bit hashes. using Grover's algorithm would require at least 1024 quantum operations. As for Grover's application to mining, see [https://quantumcomputing.stackexchange.com/a/12847 Sam Jaques’ post on this].
+The only time a short-range attack can occur is when the transaction is in the mempool, whereas a long-range attack
+occurs when the public key is known well in advance. Short-range attacks require much larger, more expensive CRQCs.
+
+Should quantum advantage manifest, a convention is proposed in spending the full 65-byte P2PK key used by the coinbase
+output in Block 1 back to itself. It is proposed to call the address in Block 1 the
+[https://mempool.space/address/0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f81
+41781e62294721166bf621e73a82cbf2342c858ee Canary address] since it can only be spent from by others (assuming Satoshi's
+continued absence) if secp256k1 is broken. Should the Canary coins move, that will signal that reliance on secp256k1 is
+presently vulnerable. Without the Canary, or an address like it, there may be some doubt as to whether the coins were
+moved with keys belonging to the original owner.
+
+As an interesting aside, coinbase outputs to P2PK keys go as far as block 200,000, so there are 1,723,848 coins that
+are vulnerable from the first epoch at the time of writing in P2PK outputs alone. Since the majority of these have a
+block reward of 50 coins each, there are roughly 34,000 distinct P2PK addresses that are vulnerable. These coins can be
+considered "Satoshi's Shield." Any addresses with a balance of less than the original block subsidy of 50 coins can be
+considered incentive incompatible to capture until all of these are mined, and these addresses serve to provide time to
+transition Bitcoin to implement post-quantum security.
+
+It's for the above reason that, for those who wish to be prepared for quantum emergency, it is recommended that no more
+than 50 bitcoin are kept under a single, distinct, unused Native SegWit (P2WPKH, "bc1q") address at a time. This is
+assuming that the attacker is financially motivated instead of, for example, a nation state looking to break confidence
+in Bitcoin. Additionally, this assumes that other vulnerable targets such as central banks have upgraded their
+cryptography by this time.
+
+The Commercial National Security Algorithm Suite (CNSA) 2.0 has a timeline for software and networking equipment to be
+upgraded by 2030, with browsers and operating systems fully upgraded by 2033. According to NIST IR 8547, Elliptic Curve
+Cryptography is planned to be disallowed within the US Federal government after 2035. An exception is made for hybrid
+cryptography, which is the use of ECC and post-quantum algorithms together.
+
+Although CRQCs could pose a threat to the signatures used in Bitcoin, a smaller threat is to Bitcoin's hash algorithms.
+In particular, while a CRQC could use [https://en.wikipedia.org/wiki/Grover's_algorithm Grover's algorithm] to gain a
+quadratic speedup on brute-force attacks on the hash functions used in Bitcoin, a significantly more powerful CRQC is
+needed for these attacks to meaningfully impact Bitcoin. For instance, a preimage attack on HASH160Used by P2PKH, P2SH, and P2WPKH addresses, though not P2WSH because it uses 256-bit hashes. using
+Grover's algorithm would require at least 1024 quantum operations. As for Grover's application to mining,
+see [https://quantumcomputing.stackexchange.com/a/12847 Sam Jaques’ post on this].
 
 === Rationale ===
 
-This is the first in a series of BIPs under a QuBit soft fork. A qubit is a fundamental unit of quantum computing, and the capital B refers to Bitcoin. The name QuBit also rhymes to some extent with SegWit.
-
-It is proposed to use SegWit version 3. This results in addresses that start with bc1r, which could be a useful way to remember that these are quantum (r)esistant addresses (similar to how bc1q corresponds to Se(q)Wit and bc1p corresponds to Ta(p)root). This is referencing the lookup table under [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32 BIP-173].
-
-The proposal above also leaves a gap in case it makes sense to use version 2, or bc1z, for implementation of other address formats such as those that employ Cross Input Signature Aggregation (CISA).
-
-P2QRH is meant to be implemented on top of P2TR, combining the security of classical Schnorr signatures along with post-quantum cryptography. This is a form of hybrid cryptography such that no regression in security is presented should a vulnerability exist in one of the signature algorithms used. One key distinction between P2QRH and P2TR however is that P2QRH will encode a hash of the public key. This is a significant deviation from how Taproot works by itself, but it is necessary to avoid exposing public keys on-chain where they are vulnerable to attack.
-
-P2QRH uses a 32-byte HASH256 (specifically SHA-256 twice-over, which is similar to that used in [https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#specification BIP-16]) of the public key to reduce the size of new outputs and also to increase security by not having the public key available on-chain. This hash serves as a minimal cryptographic commitment to a public key. It goes into the output spend script, which does not receive the witness discount.
-
-Post-quantum public keys are generally larger than those used by ECC, depending on the security level. To promote user adoption and general user-friendliness, the most secure variant (NIST Level V, 256-bit security) is proposed, despite the increase in key length and verification time.
-
-Support for FALCON signatures will be introduced first, with the intention of adding SQIsign and other post-quantum algorithms as they are approved. By way of comparison, FALCON signatures are roughly 4x larger than SQIsign signatures and 20x larger than Schnorr signatures. FALCON is a more conservative approach to applied lattice cryptography than SQIsign, and its use has recently been approved by NIST. NIST approval streamlines implementations through establishing consensus in the scientific and developer community. However, even SQIsign signatures are roughly 5x larger than Schnorr signatures. This means, to maintain present transaction throughput, an increase in the witness discount will likely be desired in a QuBit soft fork. That will be specified in a future QuBit BIP.
-
-An increase in the witness discount must not be taken lightly. It must be resistant to applications that might take advantage of this discount (e.g., storage of arbitrary data as seen with "inscriptions") without a corresponding increase in economic activity. An increase in the witness discount would not only impact node runners but those with inscriptions would also have the scarcity of their non-monetary assets affected. The only way to prevent these effects while also increasing the discount is to have a completely separate witness—a "quantum witness." Because it is meant only for public keys and signatures, we call this section of the transaction the attestation.
-
-To address the risk of arbitrary data being stored using P2QRH (QuBit) addresses, very specific rules will be applied to spending from the witness stack in SegWit v3 outputs. A fixed signature size will be necessary for spending the output, and the output must be spendable to be considered valid within node consensus. A fixed signature size will also be helpful to disambiguate between signature types without an additional version byte, as SQIsign signatures are substantially smaller than FALCON signatures. Consequently, the correct signature algorithm can be inferred through byte length. The public key and signature will be pushed separately to the attestation stack. Multiple signatures can be included in order to support multisig applications, and also for spending multiple inputs.
-
-Since only valid signatures can be committed to in a SegWit v3 attestation, arbitrary data cannot be added by miners, as that would affect the consensus of their block. A CRQC operator is economically disincentivized from computing a spendable public key that matched arbitrary signature data due to the cost of that computation. That is because the cost of such a computation could prove quite substantial, rather than simply putting the arbitrary data within a Taproot witness.
-
-Additionally, it should be noted, whether an output with a P2QRH spend script corresponds to a FALCON or SQIsign signature is not known until the output is spent.
-
-While it might be seen as a maintenance burden for Bitcoin ecosystem devs to go from a single cryptosystem implementation to four additional distinct PQC cryptosystems—and it most certainly is—the ramifications of a chain broken through extrinsic factors should provide sufficient motivation. An increase in software maintenance everywhere signatures are used should be seen as an acceptable compromise for maintained integrity of Bitcoin transfers during a regime of quantum advantage.
-
-The inclusion of these four cryptosystems: SPHINCS+, CRYSTALS-Dilithium, FALCON, and SQIsign have various advocates within the community due to their varying security assumptions. Hash-based cryptosystems are more conservative, time-tested, and well-reviewed. Lattice cryptography is relatively new and introduces novel security assumptions to Bitcoin, but their signatures are smaller and might be considered by some to be an adequate alternative to hash-based signatures. SQIsign is much smaller; however, it is based on a very novel form of cryptography known as supersingular elliptic curve quaternion isogeny, and at the time of writing, is not yet approved by NIST or the broader PQC community.
-
-In the distant future, following the implementation of the P2QRH address format in a QuBit soft fork, there will likely be a need for Pay to Quantum Secure (P2QS) addresses. These will require specialized quantum hardware for signing, while still [https://quantum-journal.org/papers/q-2023-01-19-901/ using public keys that are verifiable via classical means]. Additional follow-on BIPs will be needed to implement P2QS. However, until specialized quantum cryptography hardware is widespread, quantum resistant addresses should be an adequate intermediate solution.
+This is the first in a series of BIPs under a QuBit soft fork. A qubit is a fundamental unit of quantum computing, and
+the capital B refers to Bitcoin. The name QuBit also rhymes to some extent with SegWit.
+
+It is proposed to use SegWit version 3. This results in addresses that start with bc1r, which could be a useful way to
+remember that these are quantum (r)esistant addresses (similar to how bc1q corresponds to Se(q)Wit and bc1p corresponds
+to Ta(p)root). This is referencing the lookup table under
+[https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32 BIP-173].
+
+The proposal above also leaves a gap in case it makes sense to use version 2, or bc1z, for implementation of other
+address formats such as those that employ Cross Input Signature Aggregation (CISA).
+
+P2QRH is meant to be implemented on top of P2TR, combining the security of classical Schnorr signatures along with
+post-quantum cryptography. This is a form of hybrid cryptography such that no regression in security is presented
+should a vulnerability exist in one of the signature algorithms used. One key distinction between P2QRH and P2TR
+however is that P2QRH will encode a hash of the public key. This is a significant deviation from how Taproot works by
+itself, but it is necessary to avoid exposing public keys on-chain where they are vulnerable to attack.
+
+P2QRH uses a 32-byte HASH256 (specifically SHA-256 twice-over, which is similar to that used in
+[https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#specification BIP-16]) of the public key to reduce the
+size of new outputs and also to increase security by not having the public key available on-chain. This hash serves as
+a minimal cryptographic commitment to a public key. It goes into the output spend script, which does not receive the
+witness discount.
+
+Post-quantum public keys are generally larger than those used by ECC, depending on the security level. To promote user
+adoption and general user-friendliness, the most secure variant (NIST Level V, 256-bit security) is proposed, despite
+the increase in key length and verification time.
+
+Support for FALCON signatures will be introduced first, with the intention of adding SQIsign and other post-quantum
+algorithms as they are approved. By way of comparison, FALCON signatures are roughly 4x larger than SQIsign signatures
+and 20x larger than Schnorr signatures. FALCON is a more conservative approach to applied lattice cryptography than
+SQIsign, and its use has recently been approved by NIST. NIST approval streamlines implementations through establishing
+consensus in the scientific and developer community. However, even SQIsign signatures are roughly 5x larger than
+Schnorr signatures. This means, to maintain present transaction throughput, an increase in the witness discount will
+likely be desired in a QuBit soft fork. That will be specified in a future QuBit BIP.
+
+An increase in the witness discount must not be taken lightly. It must be resistant to applications that might take
+advantage of this discount (e.g., storage of arbitrary data as seen with "inscriptions") without a corresponding
+increase in economic activity. An increase in the witness discount would not only impact node runners but those with
+inscriptions would also have the scarcity of their non-monetary assets affected. The only way to prevent these effects
+while also increasing the discount is to have a completely separate witness—a "quantum witness." Because it is meant
+only for public keys and signatures, we call this section of the transaction the attestation.
+
+To address the risk of arbitrary data being stored using P2QRH (QuBit) addresses, very specific rules will be applied
+to spending from the witness stack in SegWit v3 outputs. A fixed signature size will be necessary for spending the
+output, and the output must be spendable to be considered valid within node consensus. A fixed signature size will also
+be helpful to disambiguate between signature types without an additional version byte, as SQIsign signatures are
+substantially smaller than FALCON signatures. Consequently, the correct signature algorithm can be inferred through
+byte length. The public key and signature will be pushed separately to the attestation stack. Multiple signatures can
+be included in order to support multisig applications, and also for spending multiple inputs.
+
+Since only valid signatures can be committed to in a SegWit v3 attestation, arbitrary data cannot be added by miners,
+as that would affect the consensus of their block. A CRQC operator is economically disincentivized from computing a
+spendable public key that matched arbitrary signature data due to the cost of that computation. That is because the
+cost of such a computation could prove quite substantial, rather than simply putting the arbitrary data within a
+Taproot witness.
+
+Additionally, it should be noted, whether an output with a P2QRH spend script corresponds to a FALCON or SQIsign
+signature is not known until the output is spent.
+
+While it might be seen as a maintenance burden for Bitcoin ecosystem devs to go from a single cryptosystem
+implementation to four additional distinct PQC cryptosystems—and it most certainly is—the ramifications of a chain
+broken through extrinsic factors should provide sufficient motivation. An increase in software maintenance everywhere
+signatures are used should be seen as an acceptable compromise for maintained integrity of Bitcoin transfers during a
+regime of quantum advantage.
+
+The inclusion of these four cryptosystems: SPHINCS+, CRYSTALS-Dilithium, FALCON, and SQIsign have various advocates
+within the community due to their varying security assumptions. Hash-based cryptosystems are more conservative,
+time-tested, and well-reviewed. Lattice cryptography is relatively new and introduces novel security assumptions to
+Bitcoin, but their signatures are smaller and might be considered by some to be an adequate alternative to hash-based
+signatures. SQIsign is much smaller; however, it is based on a very novel form of cryptography known as supersingular
+elliptic curve quaternion isogeny, and at the time of writing, is not yet approved by NIST or the broader PQC community.
+
+In the distant future, following the implementation of the P2QRH address format in a QuBit soft fork, there will likely
+be a need for Pay to Quantum Secure (P2QS) addresses. These will require specialized quantum hardware for signing,
+while still [https://quantum-journal.org/papers/q-2023-01-19-901/ using public keys that are verifiable via classical
+means]. Additional follow-on BIPs will be needed to implement P2QS. However, until specialized quantum cryptography
+hardware is widespread, quantum resistant addresses should be an adequate intermediate solution.
 
 == Specification ==
 
@@ -120,17 +233,23 @@ We define the signature scheme and transaction structure as follows.
 
 === Descriptor Format ===
 
-To integrate P2QRH into existing wallet software and scripts, we introduce a new output descriptor function qrh(). This function represents a P2QRH output, similar to how wpkh() and tr() are used for P2WPKH and P2TR outputs, respectively.
+To integrate P2QRH into existing wallet software and scripts, we introduce a new output descriptor function
+qrh(). This function represents a P2QRH output, similar to how wpkh() and tr()
+are used for P2WPKH and P2TR outputs, respectively.
 
-The qrh() function takes the HASH256 of the concatenated HASH256 of the quantum-resistant public keys as its argument. For example:
+The qrh() function takes the HASH256 of the concatenated HASH256 of the quantum-resistant public keys as
+its argument. For example:
 
 qrh(HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ...))
 
-This function allows wallets to manage P2QRH addresses and outputs while accommodating multiple public keys of varying lengths, such as in multisig schemes, while keeping the public keys hidden until the time of spending.
+This function allows wallets to manage P2QRH addresses and outputs while accommodating multiple public keys of varying
+lengths, such as in multisig schemes, while keeping the public keys hidden until the time of spending.
 
 === Address Format ===
 
-P2QRH uses SegWit version 3 outputs, resulting in addresses that start with bc1r, following [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32 BIP-173]. Bech32 encoding maps version 3 to the prefix r.
+P2QRH uses SegWit version 3 outputs, resulting in addresses that start with bc1r, following
+[https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32 BIP-173]. Bech32 encoding maps version 3 to the
+prefix r.
 
 Example P2QRH address:
 
@@ -189,13 +308,16 @@ For each signature:
 * signature_length: VarInt encoded length of the signature.
 * signature: The signature bytes.
 
-This structure repeats for each input, in order, for flexibility in supporting multisig schemes and various quantum-resistant algorithms.
+This structure repeats for each input, in order, for flexibility in supporting multisig schemes and various
+quantum-resistant algorithms.
 
-For each input, a separate attestation field is used. To know how many attestation fields are present, implementations must count the number of inputs present in the transaction.
+For each input, a separate attestation field is used. To know how many attestation fields are present, implementations
+must count the number of inputs present in the transaction.
 
 === Signature Algorithm Identification ===
 
-The specific quantum-resistant signature algorithm used is inferred from the length of the public key and signature. Implementations must recognize the supported algorithms and validate accordingly.
+The specific quantum-resistant signature algorithm used is inferred from the length of the public key and signature.
+Implementations must recognize the supported algorithms and validate accordingly.
 
 Supported algorithms and their NIST Level V parameters:
 
@@ -226,14 +348,18 @@ OP_PUSHNUM_3 <32-byte hash>
 
 2. The attestation must include:
 
-* The quantum-resistant public key(s) whose HASH256 concatenated and hashed again matches the  in the scriptPubKey.
+* The quantum-resistant public key(s) whose HASH256 concatenated and hashed again matches the  in
+the scriptPubKey.
 * Valid signatures corresponding to the public key(s) and the transaction data.
 
-3. For multi-signature schemes, all required public keys and signatures must be provided for that input within the attestation. This includes classical Schnorr signatures.
+3. For multi-signature schemes, all required public keys and signatures must be provided for that input within the
+attestation. This includes classical Schnorr signatures.
 
 ==== Public Key Hashing ====
 
-All public keys included in the attestation are hashed using HASH256 (double SHA-256). The concatenation of these hashes is then hashed again using HASH256 before being included in the scriptPubKey. This ensures a fixed-size commitment to potentially multiple public keys of varying lengths.
+All public keys included in the attestation are hashed using HASH256 (double SHA-256). The concatenation of these
+hashes is then hashed again using HASH256 before being included in the scriptPubKey. This ensures a
+fixed-size commitment to potentially multiple public keys of varying lengths.
 
 ==== Hash Computation ====
 
@@ -307,27 +433,38 @@ Note: This contrasts with multisig inputs, where the attestation structure repea
 
 === Compatibility with BIP-141 ===
 
-By adhering to the SegWit transaction structure and versioning, P2QRH outputs are compatible with existing transaction processing rules. Nodes that do not recognize SegWit version 3 will treat these outputs as anyone-can-spend but, per BIP-141, will not relay or mine such transactions.
+By adhering to the SegWit transaction structure and versioning, P2QRH outputs are compatible with existing transaction
+processing rules. Nodes that do not recognize SegWit version 3 will treat these outputs as anyone-can-spend but, per
+BIP-141, will not relay or mine such transactions.
 
 === Usage Considerations ===
 
 ==== Transaction Size and Fees ====
 
-Quantum-resistant signatures are significantly larger than traditional signatures, increasing transaction size and the fees required. Users and wallet developers should be aware of this and plan accordingly.
+Quantum-resistant signatures are significantly larger than traditional signatures, increasing transaction size and the
+fees required. Users and wallet developers should be aware of this and plan accordingly.
 
-For example, for CRYSTALS-Dilithium Level V, a single signature is 4,595 bytes, a substantial increase over current ECDSA or Schnorr signatures.
+For example, for CRYSTALS-Dilithium Level V, a single signature is 4,595 bytes, a substantial increase over current
+ECDSA or Schnorr signatures.
 
 ==== Performance Impact ====
 
-Verification of quantum-resistant signatures will be computationally more intensive, and any attestation discount will also increase storage requirements. Node operators should consider the potential impact on resource usage in the long term. Developers may need to optimize signature verification implementations, especially by implementing caching for key generation.
+Verification of quantum-resistant signatures will be computationally more intensive, and any attestation discount will
+also increase storage requirements. Node operators should consider the potential impact on resource usage in the long
+term. Developers may need to optimize signature verification implementations, especially by implementing caching for
+key generation.
 
 ==== Algorithm Selection ====
 
-Introducing four quantum-resistant algorithms to the Bitcoin ecosystem provides users with the option to select an appropriate algorithm for their use case, generally based on the amount of value they wish to secure. Developers can choose to implement support for multiple algorithms in wallets and on nodes to offer quantum-resistant options.
+Introducing four quantum-resistant algorithms to the Bitcoin ecosystem provides users with the option to select an
+appropriate algorithm for their use case, generally based on the amount of value they wish to secure. Developers can
+choose to implement support for multiple algorithms in wallets and on nodes to offer quantum-resistant options.
 
 ==== Backward Compatibility ====
 
-Older wallets and nodes that have not been made compatible with SegWit version 3 and P2QRH will not recognize these outputs. Users should ensure they are using updated wallets and nodes to use P2QRH addresses and validate transactions using P2QRH outputs.
+Older wallets and nodes that have not been made compatible with SegWit version 3 and P2QRH will not recognize these
+outputs. Users should ensure they are using updated wallets and nodes to use P2QRH addresses and validate transactions
+using P2QRH outputs.
 
 == Security ==
 
@@ -336,30 +473,46 @@ Older wallets and nodes that have not been made compatible with SegWit version 3
 |-
 ! Signature Algorithm !! Year First Introduced !! Signature Size !! Public Key Size !! Cryptographic Assumptions
 |-
-| [https://en.wikipedia.org/wiki/Lamport_signature Lamport signature] || 1977 || 8,192 bytes || 16,384 bytes || Hash-based cryptography
+| [https://en.wikipedia.org/wiki/Lamport_signature Lamport signature] || 1977 || 8,192 bytes || 16,384 bytes ||
+Hash-based cryptography
 |-
-| [https://eprint.iacr.org/2011/191.pdf Winternitz signature] || 1982 || 2,368 bytesWinternitz signatures are much smaller than Lamport signatures due to efficient chunking, but computation is much higher, especially with high values for w. Winternitz values are for w of 4. || 2,368 bytes || Hash-based cryptography
+| [https://eprint.iacr.org/2011/191.pdf Winternitz signature] || 1982 || 2,368 bytesWinternitz
+signatures are much smaller than Lamport signatures due to efficient chunking, but computation is much higher,
+especially with high values for w. Winternitz values are for w of 4. || 2,368 bytes || Hash-based cryptography
 |-
-| [https://sphincs.org/data/sphincs+-r3.1-specification.pdf SPHINCS+ Rd. 3.1 (FIPS 205 - SLH-DSA)] || 2015 || 29,792 bytes || 64 bytes || Hash-based cryptography
+| [https://sphincs.org/data/sphincs+-r3.1-specification.pdf SPHINCS+ Rd. 3.1 (FIPS 205 - SLH-DSA)] || 2015 || 29,792
+bytes || 64 bytes || Hash-based cryptography
 |-
-| [https://eprint.iacr.org/2011/484.pdf XMSS]XMSS, which is based on Winternitz, uses a value of 108 for its most compact signature size, with only a 4.6x (2.34/0.51) increase in verification time. Signing and key generation are not considered a significant factor because they are not distributed throughout the entire Bitcoin network, which take place only inside of wallets one time. || 2011 || 15,384 bytes || 13,568 bytes || Hash-based cryptography (Winternitz OTS)
+| [https://eprint.iacr.org/2011/484.pdf XMSS]XMSS, which is based on Winternitz, uses a value of 108
+for its most compact signature size, with only a 4.6x (2.34/0.51) increase in verification time. Signing and key
+generation are not considered a significant factor because they are not distributed throughout the entire Bitcoin
+network, which take place only inside of wallets one time. || 2011 || 15,384 bytes || 13,568 bytes || Hash-based
+cryptography (Winternitz OTS)
 |-
-| [https://pq-crystals.org/dilithium/ CRYSTALS-Dilithium (FIPS 204 - ML-DSA)] || 2017 || 4,595 bytes || 2,592 bytes || Lattice cryptography
+| [https://pq-crystals.org/dilithium/ CRYSTALS-Dilithium (FIPS 204 - ML-DSA)] || 2017 || 4,595 bytes || 2,592 bytes ||
+Lattice cryptography
 |-
 | [https://eprint.iacr.org/2014/457.pdf pqNTRUsign] || 2016 || 1,814 bytes || 1,927 bytes || Lattice cryptography (NTRU)
 |-
-| [https://falcon-sign.info FALCON (FIPS 206 - FN-DSA)] || 2017 || 1,280 bytes || 1,793 bytes || Lattice cryptography (NTRU)
+| [https://falcon-sign.info FALCON (FIPS 206 - FN-DSA)] || 2017 || 1,280 bytes || 1,793 bytes || Lattice cryptography
+(NTRU)
 |-
 | [https://eprint.iacr.org/2022/1155.pdf HAWK] || 2022 || 1,261 bytes || 2,329 bytes || Lattice cryptography
 |-
 | [https://sqisign.org SQIsign] || 2023 || 335 bytes || 128 bytes || Supersingular Elliptic Curve Isogeny
 |-
-| [https://eprint.iacr.org/2024/760.pdf SQIsign2D-West] || 2024 || 294 bytes || 130 bytes || Supersingular Elliptic Curve Isogeny
+| [https://eprint.iacr.org/2024/760.pdf SQIsign2D-West] || 2024 || 294 bytes || 130 bytes || Supersingular Elliptic
+Curve Isogeny
 |-
-| [https://eprint.iacr.org/2023/436.pdf SQIsignHD] || 2023 || 109 bytes (NIST Level I) || Not provided || Supersingular Elliptic Curve Isogeny
+| [https://eprint.iacr.org/2023/436.pdf SQIsignHD] || 2023 || 109 bytes (NIST Level I) || Not provided || Supersingular
+Elliptic Curve Isogeny
 |}
 
-As shown, supersingular elliptic curve quaternion isogeny signature algorithms represent the state of the art in post-quantum cryptography, beyond lattice cryptography alone, especially when key and signature length are major constraints. This makes inclusion of SQIsign attractive, and support is planned, but it will be some time until it is approved for production use. Meanwhile, SPHINCS+ and CRYSTALS-Dilithium signatures are already approved and have achieved broader community consensus. FALCON signatures are also NIST approved.
+As shown, supersingular elliptic curve quaternion isogeny signature algorithms represent the state of the art in
+post-quantum cryptography, beyond lattice cryptography alone, especially when key and signature length are major
+constraints. This makes inclusion of SQIsign attractive, and support is planned, but it will be some time until it is
+approved for production use. Meanwhile, SPHINCS+ and CRYSTALS-Dilithium signatures are already approved and have
+achieved broader community consensus. FALCON signatures are also NIST approved.
 
 In comparison, the size of currently used signature algorithms are:
 
@@ -368,13 +521,25 @@ In comparison, the size of currently used signature algorithms are:
 
 In comparison to inception date, secp256k1 [https://www.secg.org/SEC1-Ver-1.0.pdf was originally specified in 2000].
 
-One consideration for choosing an algorithm is its maturity. secp256k1 was already 8 years old by the time it was chosen as Bitcoin's curve. Isogeny cryptography when it was first introduced was broken over a weekend.
+One consideration for choosing an algorithm is its maturity. secp256k1 was already 8 years old by the time it was
+chosen as Bitcoin's curve. Isogeny cryptography when it was first introduced was broken over a weekend.
 
-Ideally SQIsign also proves to be flexible enough to support [https://www.pierrickdartois.fr/homepage/wp-content/uploads/2022/04/Report_OSIDH_DARTOIS.pdf Isogeny Diffie-Hellman] to replace ECDH applications, and also provide methods for the key tweaking necessary to support TapScript for P2QR addresses. Additionally, isogeny-based post-quantum cryptography is based on higher-order elliptic curves, and so it might be possible to implement Isogeny Schnorr signatures.
+Ideally SQIsign also proves to be flexible enough to support
+[https://www.pierrickdartois.fr/homepage/wp-content/uploads/2022/04/Report_OSIDH_DARTOIS.pdf Isogeny Diffie-Hellman] to
+replace ECDH applications, and also provide methods for the key tweaking necessary to support TapScript for P2QR
+addresses. Additionally, isogeny-based post-quantum cryptography is based on higher-order elliptic curves, and so it
+might be possible to implement Isogeny Schnorr signatures.
 
-Signature verification speed as it compares to Schnorr or ECDSA isn't seen as high a consideration as signature size due to block space being the primary fee constraint. As a P2QRH implementation materializes, a benchmark will be added for performance comparison. Fortunately, SQIsign signatures are substantially faster to verify than it is to generate keys or to sign, which is a major consideration when a transaction need only be signed once, or a handful of times with PSBT, compared to being verified simultaneously on tens of thousands of nodes. Key generation may need to be cached in BIP-32 Hierarchical Deterministic wallets.
+Signature verification speed as it compares to Schnorr or ECDSA isn't seen as high a consideration as signature size
+due to block space being the primary fee constraint. As a P2QRH implementation materializes, a benchmark will be added
+for performance comparison. Fortunately, SQIsign signatures are substantially faster to verify than it is to generate
+keys or to sign, which is a major consideration when a transaction need only be signed once, or a handful of times with
+PSBT, compared to being verified simultaneously on tens of thousands of nodes. Key generation may need to be cached in
+BIP-32 Hierarchical Deterministic wallets.
 
-An additional consideration is security level. Longer signature sizes provide more security. NIST has standardized five security levels for post-quantum cryptography. NIST security level I provides security equivalent to 128-bit keys, and security level V provides 256-bit security.
+An additional consideration is security level. Longer signature sizes provide more security. NIST has standardized five
+security levels for post-quantum cryptography. NIST security level I provides security equivalent to 128-bit keys, and
+security level V provides 256-bit security.
 
 == Test Vectors and Reference Code ==
 
@@ -382,14 +547,20 @@ TBD
 
 == Related Work ==
 
-It is worth noting by way of comparison that [https://ethresear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/18901 Vitalik Buterin's proposed solution] in an Ethereum quantum emergency is quite different from the approach in this BIP. His plan involves a hard fork of the chain, reverting all blocks after a sufficient amount of theft, and using STARKs based on BIP-32 seeds to act as the authoritative secret when signing. These measures are deemed far too heavy-handed for Bitcoin.
+It is worth noting by way of comparison that
+[https://ethresear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/18901 Vitalik Buterin's
+proposed solution] in an Ethereum quantum emergency is quite different from the approach in this BIP. His plan involves
+a hard fork of the chain, reverting all blocks after a sufficient amount of theft, and using STARKs based on BIP-32
+seeds to act as the authoritative secret when signing. These measures are deemed far too heavy-handed for Bitcoin.
 
 == References ==
 
 * [https://groups.google.com/g/bitcoindev/c/Aee8xKuIC2s/m/cu6xej1mBQAJ Mailing list discussion]
-* [https://delvingbitcoin.org/t/proposing-a-p2qrh-bip-towards-a-quantum-resistant-soft-fork/956?u=cryptoquick Delving Bitcoin discussion]
+* [https://delvingbitcoin.org/t/proposing-a-p2qrh-bip-towards-a-quantum-resistant-soft-fork/956?u=cryptoquick Delving
+Bitcoin discussion]
 * [https://bitcoinops.org/en/newsletters/2024/06/14/ Bitcoin OpTech newsletter]
-* [https://bitcoinops.org/en/podcast/2024/06/18/#draft-bip-for-quantum-safe-address-format Bitcoin OpTech discussion transcript]
+* [https://bitcoinops.org/en/podcast/2024/06/18/#draft-bip-for-quantum-safe-address-format Bitcoin OpTech discussion
+transcript]
 
 == Footnotes ==
 
@@ -399,17 +570,23 @@ It is worth noting by way of comparison that [https://ethresear.ch/t/how-to-hard
 
 To help implementors understand updates to this BIP, we keep a list of substantial changes.
 
+* 2024-12-06 - Update title and formatting.
 * 2024-12-03 - MediaWiki formatting fixes.
 * 2024-12-01 - Add details on attestation structure and parsing.
 * 2024-11-20 - Clarifications based on feedback from Murch. Remove some sections that are not yet ready.
 * 2024-10-21 - Replace XMSS with CRYSTALS-Dilithium due to NIST approval and size constraints.
 * 2024-09-30 - Refactor the ECC vs PoW section. Swap quitness for attestation.
 * 2024-09-29 - Update section on PoW to include partial-preimage.
-* 2024-09-28 - Add Winternitz, XMSS signatures, and security assumption types to PQC table. Omit NIST Level I table. Add spend script specification. Add revealed public key scenario table.
+* 2024-09-28 - Add Winternitz, XMSS signatures, and security assumption types to PQC table. Omit NIST Level I table.
+Add spend script specification. Add revealed public key scenario table.
 * 2024-09-27 - Initial draft proposal
 
 == Acknowledgements ==
 
-This document is inspired by [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP-341], which introduced the design of the P2TR (Taproot) address type using Schnorr signatures.
+This document is inspired by [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP-341], which introduced
+the design of the P2TR (Taproot) address type using Schnorr signatures.
 
-Much gratitude to my co-founder, Kyle Crews for proofreading and editing, to David Croisant, who suggested the name "QuBit", and Guy Swann for pointing out the earlier name for the attestation, "quitness", was imperfect. Thank you as well to those who took the time to review and contribute, including Jeff Bride, Adam Borcany, Antoine Riard, Pierre-Luc Dallaire-Demers, Ethan Heilman, Jon Atack, Jameson Lopp, and Murchandamus.
+Much gratitude to my co-founder, Kyle Crews for proofreading and editing, to David Croisant, who suggested the name
+"QuBit", and Guy Swann for pointing out the earlier name for the attestation, "quitness", was imperfect. Thank you as
+well to those who took the time to review and contribute, including Jeff Bride, Adam Borcany, Antoine Riard, Pierre-Luc
+Dallaire-Demers, Ethan Heilman, Jon Atack, Jameson Lopp, and Murchandamus.

From 2e4ad811cfb048d8399730fde15f3f701969b4e1 Mon Sep 17 00:00:00 2001
From: Hunter Trujillo 
Date: Fri, 6 Dec 2024 10:49:01 -0700
Subject: [PATCH 14/32] More wrestling with MediaWiki formatting...

---
 bip-p2qrh.mediawiki | 47 ++++++++++++++++++++++++++++++---------------
 1 file changed, 32 insertions(+), 15 deletions(-)

diff --git a/bip-p2qrh.mediawiki b/bip-p2qrh.mediawiki
index 45f6427b24..8b9e0ba46d 100644
--- a/bip-p2qrh.mediawiki
+++ b/bip-p2qrh.mediawiki
@@ -10,6 +10,8 @@
   Created: 2024-06-08
 

 
+__TOC__
+
 == Introduction ==
 
 === Abstract ===
@@ -116,10 +118,11 @@ occurs when the public key is known well in advance. Short-range attacks require
 Should quantum advantage manifest, a convention is proposed in spending the full 65-byte P2PK key used by the coinbase
 output in Block 1 back to itself. It is proposed to call the address in Block 1 the
 [https://mempool.space/address/0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f81
-41781e62294721166bf621e73a82cbf2342c858ee Canary address] since it can only be spent from by others (assuming Satoshi's
-continued absence) if secp256k1 is broken. Should the Canary coins move, that will signal that reliance on secp256k1 is
-presently vulnerable. Without the Canary, or an address like it, there may be some doubt as to whether the coins were
-moved with keys belonging to the original owner.
+41781e62294721166bf621e73a82cbf2342c858ee
+Canary address] since it can only be spent from by others (assuming Satoshi's continued absence) if secp256k1 is
+broken. Should the Canary coins move, that will signal that reliance on secp256k1 is presently vulnerable. Without the
+Canary, or an address like it, there may be some doubt as to whether the coins were moved with keys belonging to the
+original owner.
 
 As an interesting aside, coinbase outputs to P2PK keys go as far as block 200,000, so there are 1,723,848 coins that
 are vulnerable from the first epoch at the time of writing in P2PK outputs alone. Since the majority of these have a
@@ -143,9 +146,9 @@ Although CRQCs could pose a threat to the signatures used in Bitcoin, a smaller
 In particular, while a CRQC could use [https://en.wikipedia.org/wiki/Grover's_algorithm Grover's algorithm] to gain a
 quadratic speedup on brute-force attacks on the hash functions used in Bitcoin, a significantly more powerful CRQC is
 needed for these attacks to meaningfully impact Bitcoin. For instance, a preimage attack on HASH160Used by P2PKH, P2SH, and P2WPKH addresses, though not P2WSH because it uses 256-bit hashes. using
-Grover's algorithm would require at least 1024 quantum operations. As for Grover's application to mining,
-see [https://quantumcomputing.stackexchange.com/a/12847 Sam Jaques’ post on this].
+name="hash160">Used by P2PKH, P2SH, and P2WPKH addresses, though not P2WSH because it uses 256-bit hashes.
+using Grover's algorithm would require at least 10^24 quantum operations. As for Grover's application to mining, see
+[https://quantumcomputing.stackexchange.com/a/12847 Sam Jaques’ post on this].
 
 === Rationale ===
 
@@ -240,7 +243,11 @@ are used for P2WPKH and P2TR outputs, respectively.
 The qrh() function takes the HASH256 of the concatenated HASH256 of the quantum-resistant public keys as
 its argument. For example:
 
-qrh(HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ...))
+
+
+qrh(HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ...))
+
+
 
 This function allows wallets to manage P2QRH addresses and outputs while accommodating multiple public keys of varying
 lengths, such as in multisig schemes, while keeping the public keys hidden until the time of spending.
@@ -260,7 +267,9 @@ Example P2QRH address:
 The scriptPubKey for a P2QRH output is:
 
 
+
 OP_PUSHNUM_3 OP_PUSHBYTES_32 
+
 

 
 Where:
@@ -271,7 +280,7 @@ Where:
 ==== Hash Computation ====
 
 
-hash = HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN))
+hash = HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN))
 

 
 This construction creates a cryptographic commitment to multiple public keys.
@@ -343,7 +352,9 @@ To spend a P2QRH output, the following conditions must be met:
 1. The scriptPubKey must be of the form:
 
 
+
 OP_PUSHNUM_3 <32-byte hash>
+
 

 
 2. The attestation must include:
@@ -388,13 +399,17 @@ Signature verification is as follows:
 * Compute hashed_pubkeys by concatenating the HASH256 of each provided public key:
 
 
-  hashed_pubkeys = HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN)
+
+  hashed_pubkeys = HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN)
+
 

 
 * Compute computed_hash:
 
 
+
   computed_hash = HASH256(hashed_pubkeys)
+
 

 
 * Compare the resulting hash to . If they do not match, the script fails.
@@ -408,6 +423,7 @@ Signature verification is as follows:
 Signing for a single input using both FALCON-1024 and secp256k1 Schnorr:
 
 
+
 [num_pubkeys]: 0x02
 
 Pubkey 1:
@@ -427,6 +443,7 @@ Signature 1:
 Signature 2:
   [signature_length]: 0x40 (64 bytes)
   [signature]: signature_secp256k1
+
 

 
 Note: This contrasts with multisig inputs, where the attestation structure repeats for each public key and signature.
@@ -486,8 +503,8 @@ bytes || 64 bytes || Hash-based cryptography
 | [https://eprint.iacr.org/2011/484.pdf XMSS]XMSS, which is based on Winternitz, uses a value of 108
 for its most compact signature size, with only a 4.6x (2.34/0.51) increase in verification time. Signing and key
 generation are not considered a significant factor because they are not distributed throughout the entire Bitcoin
-network, which take place only inside of wallets one time. || 2011 || 15,384 bytes || 13,568 bytes || Hash-based
-cryptography (Winternitz OTS)
+network, which take place only inside of wallets one time. || 2011 || 15,384 bytes || 13,568 bytes ||
+Hash-based cryptography (Winternitz OTS)
 |-
 | [https://pq-crystals.org/dilithium/ CRYSTALS-Dilithium (FIPS 204 - ML-DSA)] || 2017 || 4,595 bytes || 2,592 bytes ||
 Lattice cryptography
@@ -504,8 +521,8 @@ Lattice cryptography
 | [https://eprint.iacr.org/2024/760.pdf SQIsign2D-West] || 2024 || 294 bytes || 130 bytes || Supersingular Elliptic
 Curve Isogeny
 |-
-| [https://eprint.iacr.org/2023/436.pdf SQIsignHD] || 2023 || 109 bytes (NIST Level I) || Not provided || Supersingular
-Elliptic Curve Isogeny
+| [https://eprint.iacr.org/2023/436.pdf SQIsignHD] || 2023 || 109 bytes (NIST Level I) || Not provided ||
+Supersingular Elliptic Curve Isogeny
 |}
 
 As shown, supersingular elliptic curve quaternion isogeny signature algorithms represent the state of the art in
@@ -578,7 +595,7 @@ To help implementors understand updates to this BIP, we keep a list of substanti
 * 2024-09-30 - Refactor the ECC vs PoW section. Swap quitness for attestation.
 * 2024-09-29 - Update section on PoW to include partial-preimage.
 * 2024-09-28 - Add Winternitz, XMSS signatures, and security assumption types to PQC table. Omit NIST Level I table.
-Add spend script specification. Add revealed public key scenario table.
+  Add spend script specification. Add revealed public key scenario table.
 * 2024-09-27 - Initial draft proposal
 
 == Acknowledgements ==

From 9935005efb814b674b3146ea7fb1bb36982c9fb8 Mon Sep 17 00:00:00 2001
From: Hunter Trujillo 
Date: Fri, 6 Dec 2024 11:07:56 -0700
Subject: [PATCH 15/32] I give up. Removing code and pre blocks.

---
 bip-p2qrh.mediawiki | 42 ++++++------------------------------------
 1 file changed, 6 insertions(+), 36 deletions(-)

diff --git a/bip-p2qrh.mediawiki b/bip-p2qrh.mediawiki
index 8b9e0ba46d..456926a74b 100644
--- a/bip-p2qrh.mediawiki
+++ b/bip-p2qrh.mediawiki
@@ -243,11 +243,7 @@ are used for P2WPKH and P2TR outputs, respectively.
 The qrh() function takes the HASH256 of the concatenated HASH256 of the quantum-resistant public keys as
 its argument. For example:
 
-
-
 qrh(HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ...))
-
-
 
 This function allows wallets to manage P2QRH addresses and outputs while accommodating multiple public keys of varying
 lengths, such as in multisig schemes, while keeping the public keys hidden until the time of spending.
@@ -266,22 +262,16 @@ Example P2QRH address:
 
 The scriptPubKey for a P2QRH output is:
 
-
-
 OP_PUSHNUM_3 OP_PUSHBYTES_32 
-
-

 
 Where:
 
 - OP_PUSHNUM_3 (0x03) indicates SegWit version 3.
--  is the 32-byte HASH256 of the concatenated HASH256 of each public key.
+-  is the 32-byte HASH256 of the concatenated HASH256 of each public key.
 
 ==== Hash Computation ====
 
-
 hash = HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN))
-

 
 This construction creates a cryptographic commitment to multiple public keys.
 
@@ -289,9 +279,7 @@ This construction creates a cryptographic commitment to multiple public keys.
 
 Following BIP-141, the transaction serialization is modified to include a new attestation field after the witness field:
 
-
 [nVersion][marker][flag][txins][txouts][witness][attestation][nLockTime]
-

 
 - marker: 0x00 (same as SegWit)
 - flag: 0x02 (indicates the presence of both witness and attestation data)
@@ -351,15 +339,11 @@ To spend a P2QRH output, the following conditions must be met:
 
 1. The scriptPubKey must be of the form:
 
-
-
 OP_PUSHNUM_3 <32-byte hash>
-
-

 
 2. The attestation must include:
 
-* The quantum-resistant public key(s) whose HASH256 concatenated and hashed again matches the  in
+* The quantum-resistant public key(s) whose HASH256 concatenated and hashed again matches the  in
 the scriptPubKey.
 * Valid signatures corresponding to the public key(s) and the transaction data.
 
@@ -374,9 +358,7 @@ fixed-size commitment to potentially multiple public keys of varying lengths.
 
 ==== Hash Computation ====
 
-
 hash = HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN))
-

 
 ==== Sighash Calculation ====
 
@@ -392,27 +374,19 @@ The message to be signed includes these hashes, ensuring transaction malleabilit
 
 Signature verification is as follows:
 
-1. Extract the  from the scriptPubKey.
+1. Extract the  from the scriptPubKey.
 
 2. For each input:
 
 * Compute hashed_pubkeys by concatenating the HASH256 of each provided public key:
 
-
-
-  hashed_pubkeys = HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN)
-
-

+  hashed_pubkeys = HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN)
 
 * Compute computed_hash:
 
-
-
-  computed_hash = HASH256(hashed_pubkeys)
-
-

+computed_hash = HASH256(hashed_pubkeys)
 
-* Compare the resulting hash to . If they do not match, the script fails.
+* Compare the resulting hash to . If they do not match, the script fails.
 
 3. Verify each signature against the corresponding public key and the sighash.
 
@@ -422,8 +396,6 @@ Signature verification is as follows:
 
 Signing for a single input using both FALCON-1024 and secp256k1 Schnorr:
 
-
-
 [num_pubkeys]: 0x02
 
 Pubkey 1:
@@ -443,8 +415,6 @@ Signature 1:
 Signature 2:
   [signature_length]: 0x40 (64 bytes)
   [signature]: signature_secp256k1
-
-

 
 Note: This contrasts with multisig inputs, where the attestation structure repeats for each public key and signature.
 

From cc47f9e370b3df6eb6ad20592b5d3f738c53d532 Mon Sep 17 00:00:00 2001
From: Hunter Trujillo 
Date: Fri, 6 Dec 2024 11:13:29 -0700
Subject: [PATCH 16/32] More formatting fixes.

---
 bip-p2qrh.mediawiki | 35 +++++++++++++++++++++--------------
 1 file changed, 21 insertions(+), 14 deletions(-)

diff --git a/bip-p2qrh.mediawiki b/bip-p2qrh.mediawiki
index 456926a74b..b1c83e68ba 100644
--- a/bip-p2qrh.mediawiki
+++ b/bip-p2qrh.mediawiki
@@ -145,9 +145,9 @@ cryptography, which is the use of ECC and post-quantum algorithms together.
 Although CRQCs could pose a threat to the signatures used in Bitcoin, a smaller threat is to Bitcoin's hash algorithms.
 In particular, while a CRQC could use [https://en.wikipedia.org/wiki/Grover's_algorithm Grover's algorithm] to gain a
 quadratic speedup on brute-force attacks on the hash functions used in Bitcoin, a significantly more powerful CRQC is
-needed for these attacks to meaningfully impact Bitcoin. For instance, a preimage attack on HASH160Used by P2PKH, P2SH, and P2WPKH addresses, though not P2WSH because it uses 256-bit hashes.
-using Grover's algorithm would require at least 10^24 quantum operations. As for Grover's application to mining, see
+needed for these attacks to meaningfully impact Bitcoin. For instance, a preimage attack on HASH160 
+Used by P2PKH, P2SH, and P2WPKH addresses, though not P2WSH because it uses 256-bit hashes. using Grover's
+algorithm would require at least 10^24 quantum operations. As for Grover's application to mining, see
 [https://quantumcomputing.stackexchange.com/a/12847 Sam Jaques’ post on this].
 
 === Rationale ===
@@ -243,7 +243,7 @@ are used for P2WPKH and P2TR outputs, respectively.
 The qrh() function takes the HASH256 of the concatenated HASH256 of the quantum-resistant public keys as
 its argument. For example:
 
-qrh(HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ...))
+  qrh(HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ...))
 
 This function allows wallets to manage P2QRH addresses and outputs while accommodating multiple public keys of varying
 lengths, such as in multisig schemes, while keeping the public keys hidden until the time of spending.
@@ -262,16 +262,16 @@ Example P2QRH address:
 
 The scriptPubKey for a P2QRH output is:
 
-OP_PUSHNUM_3 OP_PUSHBYTES_32 
+  OP_PUSHNUM_3 OP_PUSHBYTES_32 
 
 Where:
 
 - OP_PUSHNUM_3 (0x03) indicates SegWit version 3.
--  is the 32-byte HASH256 of the concatenated HASH256 of each public key.
+-  is the 32-byte HASH256 of the concatenated HASH256 of each public key.
 
 ==== Hash Computation ====
 
-hash = HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN))
+  hash = HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN))
 
 This construction creates a cryptographic commitment to multiple public keys.
 
@@ -279,10 +279,12 @@ This construction creates a cryptographic commitment to multiple public keys.
 
 Following BIP-141, the transaction serialization is modified to include a new attestation field after the witness field:
 
-[nVersion][marker][flag][txins][txouts][witness][attestation][nLockTime]
+  [nVersion][marker][flag][txins][txouts][witness][attestation][nLockTime]
 
 - marker: 0x00 (same as SegWit)
+
 - flag: 0x02 (indicates the presence of both witness and attestation data)
+
 - attestation: Contains the quantum-resistant public keys and signatures.
 
 === Attestation Structure ===
@@ -343,8 +345,9 @@ OP_PUSHNUM_3 <32-byte hash>
 
 2. The attestation must include:
 
-* The quantum-resistant public key(s) whose HASH256 concatenated and hashed again matches the  in
+* The quantum-resistant public key(s) whose HASH256 concatenated and hashed again matches the  in
 the scriptPubKey.
+
 * Valid signatures corresponding to the public key(s) and the transaction data.
 
 3. For multi-signature schemes, all required public keys and signatures must be provided for that input within the
@@ -374,7 +377,7 @@ The message to be signed includes these hashes, ensuring transaction malleabilit
 
 Signature verification is as follows:
 
-1. Extract the  from the scriptPubKey.
+1. Extract the  from the scriptPubKey.
 
 2. For each input:
 
@@ -384,9 +387,9 @@ Signature verification is as follows:
 
 * Compute computed_hash:
 
-computed_hash = HASH256(hashed_pubkeys)
+  computed_hash = HASH256(hashed_pubkeys)
 
-* Compare the resulting hash to . If they do not match, the script fails.
+* Compare the resulting hash to . If they do not match, the script fails.
 
 3. Verify each signature against the corresponding public key and the sighash.
 
@@ -396,7 +399,9 @@ computed_hash = HASH256(hashed_pubkeys)
 
 Signing for a single input using both FALCON-1024 and secp256k1 Schnorr:
 
-[num_pubkeys]: 0x02
+Number of public keys:
+
+  [num_pubkeys]: 0x02
 
 Pubkey 1:
   [pubkey_length]: 0x0701 (1793 bytes)
@@ -406,7 +411,9 @@ Pubkey 2:
   [pubkey_length]: 0x20 (32 bytes)
   [pubkey]: public_key_secp256k1
 
-[num_signatures]: 0x02
+Number of signatures:
+
+  [num_signatures]: 0x02
 
 Signature 1:
   [signature_length]: 0x0500 (1280 bytes)

From ff4d2c28198fb363a91cfca91f456af6f81af049 Mon Sep 17 00:00:00 2001
From: Hunter Beast 
Date: Fri, 6 Dec 2024 11:27:08 -0700
Subject: [PATCH 17/32] Apply suggestions from code review

Co-authored-by: Mark "Murch" Erhardt 
---
 bip-p2qrh.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-p2qrh.mediawiki b/bip-p2qrh.mediawiki
index b1c83e68ba..b05093aa5b 100644
--- a/bip-p2qrh.mediawiki
+++ b/bip-p2qrh.mediawiki
@@ -1,16 +1,16 @@
 
-  BIP: TBD
+  BIP: ?
+  Layer: 
   Comments-Summary: No comments yet.
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-TBD
   Status: Draft
   Type: Standards Track
-  License: BSD-3-Clause
   Created: 2024-06-08
+  License: BSD-3-Clause
 

 
-__TOC__
 
 == Introduction ==
 

From f206b9745af582f9d649787ff872ca41a0683c71 Mon Sep 17 00:00:00 2001
From: Hunter Trujillo 
Date: Fri, 6 Dec 2024 11:28:05 -0700
Subject: [PATCH 18/32] Address Murch feedback.

---
 bip-p2qrh.mediawiki | 39 ++++++++++++++++++++-------------------
 1 file changed, 20 insertions(+), 19 deletions(-)

diff --git a/bip-p2qrh.mediawiki b/bip-p2qrh.mediawiki
index b1c83e68ba..2b8b49f878 100644
--- a/bip-p2qrh.mediawiki
+++ b/bip-p2qrh.mediawiki
@@ -25,21 +25,20 @@ This document is licensed under the 3-clause BSD license.
 
 === Motivation ===
 
-This proposal aims to improve the quantum resistance of Bitcoin's signature security should the Discrete Logarithm
-Problem (DLP), which secures Elliptic Curve Cryptography (ECC), no longer prove to be computationally hard, likely
-through quantum advantage by Cryptoanalytically-Relevant Quantum Computers (CRQCs).
-[https://arxiv.org/pdf/quant-ph/0301141 A variant of Shor's algorithm] is believed to be capable of deriving the
-private key from a public key exponentially faster than classical means. The application of this variant of Shor's
-algorithm is herein referred to as quantum key decryption. Note that doubling the public key length, such as with a
-hypothetical secp512k1 curve, would only make deriving the private key twice as hard. The computational complexity of
-this is investigated further in the paper,
+The primary threat to Bitcoin from Cryptoanalytically-Relevant Quantum Computers (CRQCs) is their potential to break
+the cryptographic assumptions of Elliptic Curve Cryptography (ECC), which secures Bitcoin's signatures and Taproot
+commitments. Specifically, [https://arxiv.org/pdf/quant-ph/0301141 Shor's algorithm] enables a CRQC to solve the
+Discrete Logarithm Problem (DLP) exponentially faster than classical methodsShor's algorithm is
+believed to need 10^8 operations to break a 256-bit elliptic curve public key., allowing the derivation of private
+keys from public keys—a process referred to as quantum key decryption. Importantly, simply increasing the public key
+length (e.g., using a hypothetical secp512k1 curve) would only make deriving the private key twice as hard, offering
+insufficient protection. The computational complexity of this attack is further explored in
 [https://pubs.aip.org/avs/aqs/article/4/1/013801/2835275/The-impact-of-hardware-specifications-on-reaching ''The impact
-of hardware specifications on reaching quantum advantage in the fault tolerant regime''].
+of hardware specifications on reaching quantum advantage in the fault-tolerant regime''].
 
-The primary threat to Bitcoin by CRQCs is [https://en.bitcoin.it/wiki/Quantum_computing_and_Bitcoin#QC_attacks
-generally considered to be their potential to break ECC, which is used in signatures and Taproot commitments], hence
-the focus on a new address format. Shor's algorithm enables a CRQC to break the cryptographic assumptions of ECC in
-roughly 10^8 quantum operations.
+This proposal aims to mitigate these risks by introducing a Pay to Quantum Resistant Hash (P2QRH) address type that
+relies on post-quantum cryptographic (PQC) signature algorithms. By adopting PQC, Bitcoin can enhance its quantum
+resistance without requiring a hard fork or block size increase.
 
 The vulnerability of existing Bitcoin addresses is investigated in
 [https://web.archive.org/web/20240715101040/https://www2.deloitte.com/nl/nl/pages/innovatie/artikelen/quantum-computers-
@@ -48,11 +47,12 @@ Bitcoin supply is held within addresses vulnerable to quantum attack. As of the
 closer to 20%. Additionally, cryptographer Pieter Wuille [https://x.com/pwuille/status/1108085284862713856 reasons]
 even more might be vulnerable.
 
-Ordinarily, when a transaction is signed, the public key can be recovered from the signature. This makes a transaction
-submitted to the mempool vulnerable to quantum attack until it's mined. One way to mitigate this is to submit the
-transaction directly to a mining pool, which bypasses the mempool. This process is known as an out-of-band transaction.
-The mining pool must be trusted not to reveal the transaction public key to attackers. The problem with this approach
-is that it requires a trusted third party, which is what this P2QRH proposal aims to avoid.
+Ordinarily, when a transaction is signed, the public key is explicitly stated in the input script. This means that the
+public key is exposed on the blockchain when the transaction is spent, making it vulnerable to quantum attack until
+it's mined. One way to mitigate this is to submit the transaction directly to a mining pool, bypassing the mempool.
+This process is known as an out-of-band transaction or a private mempool. In this case, the mining pool must be trusted
+not to reveal the transaction public key to attackers. The problem with this approach is that it requires a trusted
+third party, which the P2QRH proposal aims to avoid.
 
 Not having public keys exposed on-chain is an important step for quantum security. Otherwise, funds would need to be
 spent to new addresses on a regular basis in order to prevent the possibility of a "long-range CRQC attack" recovering
@@ -271,7 +271,8 @@ Where:
 
 ==== Hash Computation ====
 
-  hash = HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN))
+  hash = HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ... ||
+HASH256(pubkeyN))
 
 This construction creates a cryptographic commitment to multiple public keys.
 

From feff8477c0e1016370adfa93d3aecee0e53a2f33 Mon Sep 17 00:00:00 2001
From: Hunter Trujillo 
Date: Fri, 6 Dec 2024 11:30:30 -0700
Subject: [PATCH 19/32] MediaWiki formatting.

---
 bip-p2qrh.mediawiki | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/bip-p2qrh.mediawiki b/bip-p2qrh.mediawiki
index 7768f9c887..2441dedb83 100644
--- a/bip-p2qrh.mediawiki
+++ b/bip-p2qrh.mediawiki
@@ -266,13 +266,13 @@ The scriptPubKey for a P2QRH output is:
 
 Where:
 
-- OP_PUSHNUM_3 (0x03) indicates SegWit version 3.
--  is the 32-byte HASH256 of the concatenated HASH256 of each public key.
+* OP_PUSHNUM_3 (0x03) indicates SegWit version 3.
+*  is the 32-byte HASH256 of the concatenated HASH256 of each public key.
 
 ==== Hash Computation ====
 
   hash = HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ... ||
-HASH256(pubkeyN))
+  HASH256(pubkeyN))
 
 This construction creates a cryptographic commitment to multiple public keys.
 
@@ -282,11 +282,11 @@ Following BIP-141, the transaction serialization is modified to include a new at
 
   [nVersion][marker][flag][txins][txouts][witness][attestation][nLockTime]
 
-- marker: 0x00 (same as SegWit)
+* marker: 0x00 (same as SegWit)
 
-- flag: 0x02 (indicates the presence of both witness and attestation data)
+* flag: 0x02 (indicates the presence of both witness and attestation data)
 
-- attestation: Contains the quantum-resistant public keys and signatures.
+* attestation: Contains the quantum-resistant public keys and signatures.
 
 === Attestation Structure ===
 
@@ -511,8 +511,8 @@ achieved broader community consensus. FALCON signatures are also NIST approved.
 
 In comparison, the size of currently used signature algorithms are:
 
-- ECDSA: 70-72 bytes
-- Schnorr: 64 bytes
+* ECDSA: 70-72 bytes
+* Schnorr: 64 bytes
 
 In comparison to inception date, secp256k1 [https://www.secg.org/SEC1-Ver-1.0.pdf was originally specified in 2000].
 

From e186b52cff5344c789bc5996de86697e62244323 Mon Sep 17 00:00:00 2001
From: Hunter Trujillo 
Date: Mon, 9 Dec 2024 09:57:06 -0700
Subject: [PATCH 20/32] Swap layer and title.

---
 bip-p2qrh.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-p2qrh.mediawiki b/bip-p2qrh.mediawiki
index 2441dedb83..55a86443f3 100644
--- a/bip-p2qrh.mediawiki
+++ b/bip-p2qrh.mediawiki
@@ -1,7 +1,7 @@
 
   BIP: ?
-  Layer: 
   Comments-Summary: No comments yet.
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-TBD

From d5001241ba049e18a91cd2722b5e614ec939914f Mon Sep 17 00:00:00 2001
From: Hunter Beast 
Date: Fri, 13 Dec 2024 08:35:30 -0700
Subject: [PATCH 21/32] Apply suggestions from code review

Co-authored-by: Ethan Heilman 
---
 bip-p2qrh.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-p2qrh.mediawiki b/bip-p2qrh.mediawiki
index 55a86443f3..701a8307a1 100644
--- a/bip-p2qrh.mediawiki
+++ b/bip-p2qrh.mediawiki
@@ -69,7 +69,7 @@ algorithm. This new address type protects transactions submitted to the mempool
 preventing the need for private, out-of-band mempool transactions.
 
 The following table is non-exhaustive but intended to inform the average Bitcoin user whether their bitcoin is
-vulnerable to a long-range quantum attack.
+vulnerable to a long-range quantum attack:
 
 {| class="wikitable"
 |+ Vulnerable address types
@@ -316,7 +316,7 @@ must count the number of inputs present in the transaction.
 
 === Signature Algorithm Identification ===
 
-The specific quantum-resistant signature algorithm used is inferred from the length of the public key and signature.
+The specific quantum-resistant signature algorithm used is inferred from the length of the public key.
 Implementations must recognize the supported algorithms and validate accordingly.
 
 Supported algorithms and their NIST Level V parameters:

From 85a347b5a236efde76dd76f91768d7820b31e9e0 Mon Sep 17 00:00:00 2001
From: Hunter Trujillo 
Date: Fri, 13 Dec 2024 09:31:51 -0700
Subject: [PATCH 22/32] Update to use merkle tree for attestation commitment.
 Update LR & SR quantum attack scenarios.

---
 bip-p2qrh.mediawiki | 103 ++++++++++++++++++++++++--------------------
 1 file changed, 57 insertions(+), 46 deletions(-)

diff --git a/bip-p2qrh.mediawiki b/bip-p2qrh.mediawiki
index 701a8307a1..10b8c3fb2d 100644
--- a/bip-p2qrh.mediawiki
+++ b/bip-p2qrh.mediawiki
@@ -93,27 +93,25 @@ full public key can be reconstructed.
 If a key is recovered by a CRQC it can also be trivially checked to see if any child keys were produced using an
 unhardened [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-32] derivation path.
 
-The following table summarizes the scenarios in which public keys are revealed when using Bitcoin and what type of
-attack the underlying addresses are vulnerable to:
+==== Long Range and Short Range Quantum Attacks ====
 
-{| class="wikitable"
-|+ Scenarios for revealed public keys on Bitcoin
-|-
-! Scenario !! Type of attack
-|-
-| Early addresses (Satoshi's coins, CPU miners, starts with 04) || Long-range
-|-
-| Reused addresses (any type, except P2QRH) || Long-range
-|-
-| Taproot addresses (starts with bc1p) || Long-range
-|-
-| Any transaction in the mempool (except for P2QRH) || Short-range
-|-
-| Unhardened BIP-32 HD wallet keys || Both Long-range or Short-range
-|}
+Long Range Quantum Attack is an attack in which the public key has been exposed on the blockchain for an extended
+period of time, giving an attacker ample opportunity to break the cryptography. This affects:
+
+* Early addresses (Satoshi's coins, CPU miners, starts with 04)
+* Reused addresses (any type, except P2QRH)
+* Taproot addresses (starts with bc1p)
+* Unhardened BIP-32 HD wallet keys
+
+Short Range Quantum Attack is an attack that must be executed quickly while a transaction is still in the mempool,
+before it gets mined into a block. This affects:
 
-The only time a short-range attack can occur is when the transaction is in the mempool, whereas a long-range attack
-occurs when the public key is known well in advance. Short-range attacks require much larger, more expensive CRQCs.
+* Any transaction in the mempool (except for P2QRH)
+* Unhardened BIP-32 HD wallet keys
+
+Short-range attacks require much larger, more expensive CRQCs since they must be executed within the short window
+before a transaction is mined. Long-range attacks can be executed over a longer timeframe since the public key remains
+exposed on the blockchain indefinitely.
 
 Should quantum advantage manifest, a convention is proposed in spending the full 65-byte P2PK key used by the coinbase
 output in Block 1 back to itself. It is proposed to call the address in Block 1 the
@@ -124,11 +122,13 @@ broken. Should the Canary coins move, that will signal that reliance on secp256k
 Canary, or an address like it, there may be some doubt as to whether the coins were moved with keys belonging to the
 original owner.
 
-As an interesting aside, coinbase outputs to P2PK keys go as far as block 200,000, so there are 1,723,848 coins that
-are vulnerable from the first epoch at the time of writing in P2PK outputs alone. Since the majority of these have a
-block reward of 50 coins each, there are roughly 34,000 distinct P2PK addresses that are vulnerable. These coins can be
+Coinbase outputs to P2PK keys go as far as block 200,000, so there are, at the time of writing, 1,723,848 coins that
+are vulnerable from the first epoch at the time of writing in P2PK outputs alone. The majority of these have a
+block reward of 50 coins each, and there are roughly 34,000 distinct P2PK addresses that are vulnerable. These coins
+can be
 considered "Satoshi's Shield." Any addresses with a balance of less than the original block subsidy of 50 coins can be
-considered incentive incompatible to capture until all of these are mined, and these addresses serve to provide time to
+considered cryptoeconomically incentive incompatible to capture until all of these are mined, and these addresses serve
+to provide time to
 transition Bitcoin to implement post-quantum security.
 
 It's for the above reason that, for those who wish to be prepared for quantum emergency, it is recommended that no more
@@ -271,10 +271,34 @@ Where:
 
 ==== Hash Computation ====
 
-  hash = HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ... ||
-  HASH256(pubkeyN))
+The hash is computed as a merkle tree of public key hashes:
+
+1. For each public key, compute its HASH256
+2. Pair the hashes and compute HASH256 of their concatenation
+3. Continue pairing and hashing until reaching a single root hash
+4. The final hash is the merkle root
+
+For example with 4 public keys:
 
-This construction creates a cryptographic commitment to multiple public keys.
+  h1 = HASH256(pubkey1)
+  h2 = HASH256(pubkey2)
+  h3 = HASH256(pubkey3)
+  h4 = HASH256(pubkey4)
+
+  h12 = HASH256(h1 || h2)
+  h34 = HASH256(h3 || h4)
+
+  root = HASH256(h12 || h34)
+
+When spending, if a public key hash is provided in the attestation with an empty signature, that hash will be used
+directly in the merkle tree computation rather than hashing the full public key. This allows excluding unused public
+keys from the transaction while still proving they were part of the original commitment.
+
+This merkle tree construction creates an efficient cryptographic commitment to multiple public keys while enabling
+selective disclosure.
+
+This allows for inclusion of a Taproot MAST merkle root in the attestation, which makes P2QRH a quantum-resistant
+version of Taproot.
 
 === Transaction Serialization ===
 
@@ -319,7 +343,7 @@ must count the number of inputs present in the transaction.
 The specific quantum-resistant signature algorithm used is inferred from the length of the public key.
 Implementations must recognize the supported algorithms and validate accordingly.
 
-Supported algorithms and their NIST Level V parameters:
+Supported PQC algorithms and their NIST Level V parameters:
 
 * '''SPHINCS+-256f:'''
   * Public Key Length: 64 bytes
@@ -352,17 +376,8 @@ the scriptPubKey.
 * Valid signatures corresponding to the public key(s) and the transaction data.
 
 3. For multi-signature schemes, all required public keys and signatures must be provided for that input within the
-attestation. This includes classical Schnorr signatures.
-
-==== Public Key Hashing ====
-
-All public keys included in the attestation are hashed using HASH256 (double SHA-256). The concatenation of these
-hashes is then hashed again using HASH256 before being included in the scriptPubKey. This ensures a
-fixed-size commitment to potentially multiple public keys of varying lengths.
-
-==== Hash Computation ====
-
-hash = HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN))
+attestation. Public keys that are not needed can be excluded by including their hash in the attestation accompanied
+with an empty signature. This includes classical Schnorr signatures.
 
 ==== Sighash Calculation ====
 
@@ -382,19 +397,14 @@ Signature verification is as follows:
 
 2. For each input:
 
-* Compute hashed_pubkeys by concatenating the HASH256 of each provided public key:
-
-  hashed_pubkeys = HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN)
-
-* Compute computed_hash:
-
-  computed_hash = HASH256(hashed_pubkeys)
+* Compute hashed_pubkeys as specified in the Hash Computation section.
 
 * Compare the resulting hash to . If they do not match, the script fails.
 
 3. Verify each signature against the corresponding public key and the sighash.
 
-4. Ensure that the signature algorithm used matches the expected lengths for NIST Level V security and is supported.
+4. Ensure that the signature algorithm used matches the expected lengths for NIST Level V security, and is supported by
+the implementation.
 
 ==== Attestation Parsing Example ====
 
@@ -565,6 +575,7 @@ transcript]
 
 To help implementors understand updates to this BIP, we keep a list of substantial changes.
 
+* 2024-12-13 - Update to use merkle tree for attestation commitment. Update LR & SR quantum attack scenarios.
 * 2024-12-06 - Update title and formatting.
 * 2024-12-03 - MediaWiki formatting fixes.
 * 2024-12-01 - Add details on attestation structure and parsing.

From 85348c01ff840d77302013db0540897fafbd8e6d Mon Sep 17 00:00:00 2001
From: Hunter Trujillo 
Date: Wed, 18 Dec 2024 14:43:24 -0700
Subject: [PATCH 23/32] P2QRH assigned BIP number 360.

---
 README.mediawiki                          |  7 +++++++
 bip-p2qrh.mediawiki => bip-0360.mediawiki | 20 +++++++++-----------
 2 files changed, 16 insertions(+), 11 deletions(-)
 rename bip-p2qrh.mediawiki => bip-0360.mediawiki (98%)

diff --git a/README.mediawiki b/README.mediawiki
index d92cb78669..a5eeabd778 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -1148,6 +1148,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Matt Corallo, Bastien Teinturier
 | Standard
 | Draft
+|-
+| [[bip-0360.mediawiki|360]]
+| Consensus (soft fork)
+| QuBit: SegWit v3 spending rules (P2QRH)
+| Hunter Beast
+| Standard
+| Draft
 |- style="background-color: #cfffcf"
 | [[bip-0370.mediawiki|370]]
 | Applications
diff --git a/bip-p2qrh.mediawiki b/bip-0360.mediawiki
similarity index 98%
rename from bip-p2qrh.mediawiki
rename to bip-0360.mediawiki
index 10b8c3fb2d..7f2aaf910b 100644
--- a/bip-p2qrh.mediawiki
+++ b/bip-0360.mediawiki
@@ -1,13 +1,13 @@
 
-  BIP: ?
-  Title: QuBit: SegWit version 3 spending rules (P2QRH)
-  Layer: 
   Comments-Summary: No comments yet.
-  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-TBD
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0360
   Status: Draft
   Type: Standards Track
-  Created: 2024-06-08
+  Created: 2024-12-18
   License: BSD-3-Clause
 

 
@@ -561,11 +561,9 @@ seeds to act as the authoritative secret when signing. These measures are deemed
 == References ==
 
 * [https://groups.google.com/g/bitcoindev/c/Aee8xKuIC2s/m/cu6xej1mBQAJ Mailing list discussion]
-* [https://delvingbitcoin.org/t/proposing-a-p2qrh-bip-towards-a-quantum-resistant-soft-fork/956?u=cryptoquick Delving
-Bitcoin discussion]
+* [https://delvingbitcoin.org/t/proposing-a-p2qrh-bip-towards-a-quantum-resistant-soft-fork/956?u=cryptoquick Delving Bitcoin discussion]
 * [https://bitcoinops.org/en/newsletters/2024/06/14/ Bitcoin OpTech newsletter]
-* [https://bitcoinops.org/en/podcast/2024/06/18/#draft-bip-for-quantum-safe-address-format Bitcoin OpTech discussion
-transcript]
+* [https://bitcoinops.org/en/podcast/2024/06/18/#draft-bip-for-quantum-safe-address-format Bitcoin OpTech discussion transcript]
 
 == Footnotes ==
 
@@ -575,6 +573,7 @@ transcript]
 
 To help implementors understand updates to this BIP, we keep a list of substantial changes.
 
+* 2024-12-18 - Assigned BIP number.
 * 2024-12-13 - Update to use merkle tree for attestation commitment. Update LR & SR quantum attack scenarios.
 * 2024-12-06 - Update title and formatting.
 * 2024-12-03 - MediaWiki formatting fixes.
@@ -583,8 +582,7 @@ To help implementors understand updates to this BIP, we keep a list of substanti
 * 2024-10-21 - Replace XMSS with CRYSTALS-Dilithium due to NIST approval and size constraints.
 * 2024-09-30 - Refactor the ECC vs PoW section. Swap quitness for attestation.
 * 2024-09-29 - Update section on PoW to include partial-preimage.
-* 2024-09-28 - Add Winternitz, XMSS signatures, and security assumption types to PQC table. Omit NIST Level I table.
-  Add spend script specification. Add revealed public key scenario table.
+* 2024-09-28 - Add Winternitz, XMSS signatures, and security assumption types to PQC table. Omit NIST Level I table. Add spend script specification. Add revealed public key scenario table.
 * 2024-09-27 - Initial draft proposal
 
 == Acknowledgements ==

From a4f3dc688394a614fb300defe120c3d6a66f68c7 Mon Sep 17 00:00:00 2001
From: Hunter Beast 
Date: Fri, 20 Dec 2024 10:08:23 -0700
Subject: [PATCH 24/32] Apply suggestions from code review
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Vojtěch Strnad <43024885+vostrnad@users.noreply.github.com>
---
 bip-0360.mediawiki | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/bip-0360.mediawiki b/bip-0360.mediawiki
index 7f2aaf910b..d7b5febcec 100644
--- a/bip-0360.mediawiki
+++ b/bip-0360.mediawiki
@@ -36,7 +36,7 @@ insufficient protection. The computational complexity of this attack is further
 [https://pubs.aip.org/avs/aqs/article/4/1/013801/2835275/The-impact-of-hardware-specifications-on-reaching ''The impact
 of hardware specifications on reaching quantum advantage in the fault-tolerant regime''].
 
-This proposal aims to mitigate these risks by introducing a Pay to Quantum Resistant Hash (P2QRH) address type that
+This proposal aims to mitigate these risks by introducing a Pay to Quantum Resistant Hash (P2QRH) output type that
 relies on post-quantum cryptographic (PQC) signature algorithms. By adopting PQC, Bitcoin can enhance its quantum
 resistance without requiring a hard fork or block size increase.
 
@@ -72,9 +72,9 @@ The following table is non-exhaustive but intended to inform the average Bitcoin
 vulnerable to a long-range quantum attack:
 
 {| class="wikitable"
-|+ Vulnerable address types
+|+ Vulnerable output types
 |-
-! Address type !! Vulnerable !! Prefix !! Example
+! Type !! Vulnerable !! Prefix !! Example
 |-
 | P2PK || Yes || 04 ||
 0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f8141781e62294721166bf621e73a82cbf
@@ -87,7 +87,7 @@ vulnerable to a long-range quantum attack:
 | P2TR || Yes || bc1p || bc1p92aslsnseq786wxfk3ekra90ds9ku47qttupfjsqmmj4z82xdq4q3rr58u
 |}
 
-It should be noted that Taproot addresses are vulnerable in that they encode a 32-byte x-only public key, from which a
+It should be noted that Taproot outputs are vulnerable in that they encode a 32-byte x-only public key, from which a
 full public key can be reconstructed.
 
 If a key is recovered by a CRQC it can also be trivially checked to see if any child keys were produced using an
@@ -98,7 +98,7 @@ unhardened [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-3
 Long Range Quantum Attack is an attack in which the public key has been exposed on the blockchain for an extended
 period of time, giving an attacker ample opportunity to break the cryptography. This affects:
 
-* Early addresses (Satoshi's coins, CPU miners, starts with 04)
+* P2PK outputs (Satoshi's coins, CPU miners, starts with 04)
 * Reused addresses (any type, except P2QRH)
 * Taproot addresses (starts with bc1p)
 * Unhardened BIP-32 HD wallet keys
@@ -124,7 +124,7 @@ original owner.
 
 Coinbase outputs to P2PK keys go as far as block 200,000, so there are, at the time of writing, 1,723,848 coins that
 are vulnerable from the first epoch at the time of writing in P2PK outputs alone. The majority of these have a
-block reward of 50 coins each, and there are roughly 34,000 distinct P2PK addresses that are vulnerable. These coins
+block reward of 50 coins each, and there are roughly 34,000 distinct P2PK scripts that are vulnerable. These coins
 can be
 considered "Satoshi's Shield." Any addresses with a balance of less than the original block subsidy of 50 coins can be
 considered cryptoeconomically incentive incompatible to capture until all of these are mined, and these addresses serve
@@ -139,7 +139,7 @@ cryptography by this time.
 
 The Commercial National Security Algorithm Suite (CNSA) 2.0 has a timeline for software and networking equipment to be
 upgraded by 2030, with browsers and operating systems fully upgraded by 2033. According to NIST IR 8547, Elliptic Curve
-Cryptography is planned to be disallowed within the US Federal government after 2035. An exception is made for hybrid
+Cryptography is planned to be disallowed within the US federal government after 2035. An exception is made for hybrid
 cryptography, which is the use of ECC and post-quantum algorithms together.
 
 Although CRQCs could pose a threat to the signatures used in Bitcoin, a smaller threat is to Bitcoin's hash algorithms.
@@ -194,7 +194,7 @@ inscriptions would also have the scarcity of their non-monetary assets affected.
 while also increasing the discount is to have a completely separate witness—a "quantum witness." Because it is meant
 only for public keys and signatures, we call this section of the transaction the attestation.
 
-To address the risk of arbitrary data being stored using P2QRH (QuBit) addresses, very specific rules will be applied
+To address the risk of arbitrary data being stored using P2QRH (QuBit) outputs, very specific rules will be applied
 to spending from the witness stack in SegWit v3 outputs. A fixed signature size will be necessary for spending the
 output, and the output must be spendable to be considered valid within node consensus. A fixed signature size will also
 be helpful to disambiguate between signature types without an additional version byte, as SQIsign signatures are
@@ -224,7 +224,7 @@ Bitcoin, but their signatures are smaller and might be considered by some to be
 signatures. SQIsign is much smaller; however, it is based on a very novel form of cryptography known as supersingular
 elliptic curve quaternion isogeny, and at the time of writing, is not yet approved by NIST or the broader PQC community.
 
-In the distant future, following the implementation of the P2QRH address format in a QuBit soft fork, there will likely
+In the distant future, following the implementation of the P2QRH output type in a QuBit soft fork, there will likely
 be a need for Pay to Quantum Secure (P2QS) addresses. These will require specialized quantum hardware for signing,
 while still [https://quantum-journal.org/papers/q-2023-01-19-901/ using public keys that are verifiable via classical
 means]. Additional follow-on BIPs will be needed to implement P2QS. However, until specialized quantum cryptography
@@ -302,7 +302,7 @@ version of Taproot.
 
 === Transaction Serialization ===
 
-Following BIP-141, the transaction serialization is modified to include a new attestation field after the witness field:
+Following BIP-141, a new transaction serialization format is introduced to include an attestation field after the witness field:
 
   [nVersion][marker][flag][txins][txouts][witness][attestation][nLockTime]
 
@@ -532,7 +532,7 @@ chosen as Bitcoin's curve. Isogeny cryptography when it was first introduced was
 Ideally SQIsign also proves to be flexible enough to support
 [https://www.pierrickdartois.fr/homepage/wp-content/uploads/2022/04/Report_OSIDH_DARTOIS.pdf Isogeny Diffie-Hellman] to
 replace ECDH applications, and also provide methods for the key tweaking necessary to support TapScript for P2QR
-addresses. Additionally, isogeny-based post-quantum cryptography is based on higher-order elliptic curves, and so it
+outputs. Additionally, isogeny-based post-quantum cryptography is based on higher-order elliptic curves, and so it
 might be possible to implement Isogeny Schnorr signatures.
 
 Signature verification speed as it compares to Schnorr or ECDSA isn't seen as high a consideration as signature size
@@ -588,7 +588,7 @@ To help implementors understand updates to this BIP, we keep a list of substanti
 == Acknowledgements ==
 
 This document is inspired by [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP-341], which introduced
-the design of the P2TR (Taproot) address type using Schnorr signatures.
+the design of the P2TR (Taproot) output type using Schnorr signatures.
 
 Much gratitude to my co-founder, Kyle Crews for proofreading and editing, to David Croisant, who suggested the name
 "QuBit", and Guy Swann for pointing out the earlier name for the attestation, "quitness", was imperfect. Thank you as

From 2b641b899e3d06344a01282cc27460eb09a16d04 Mon Sep 17 00:00:00 2001
From: Hunter Trujillo 
Date: Fri, 20 Dec 2024 11:43:24 -0700
Subject: [PATCH 25/32] Address feedback from vostrnad.

---
 bip-0360.mediawiki | 66 +++++++++++++++++++++++++++-------------------
 1 file changed, 39 insertions(+), 27 deletions(-)

diff --git a/bip-0360.mediawiki b/bip-0360.mediawiki
index d7b5febcec..aa841f5855 100644
--- a/bip-0360.mediawiki
+++ b/bip-0360.mediawiki
@@ -60,31 +60,45 @@ the key behind high-value addresses. A long-range quantum attack can be consider
 as that from a used address or one encoded in a spend script. This is likely to be more common early on, as early
 quantum computers must be run for longer in order to overcome errors caused by noise. A "short-range quantum attack"
 would be one performed on keys in the mempool, which is seen as much more difficult given the block time, and so it
-requires more sophisticated CRQCs. As the value being sent increases, so too should the fee in order to commit the
-transaction to the chain as soon as possible. Once the transaction is mined, it makes useless the public key revealed
-by spending a UTXO, so long as it is never reused.
+requires more sophisticated CRQCs.
+In the paper
+[https://arxiv.org/pdf/2306.08585 How to compute a 256-bit elliptic curve private key with only 50 million Toffoli gates]
+the authors estimate that CRQC with 28 million superconducting physical qubits would take 8.3 seconds to calculate a
+256-bit key, while a CRQC with 6.9 million physical qubits would take 58 seconds. This implies that a CRQC with 4x as
+many qubits would be roughly 7 times faster.
+
+
+As the value being sent increases, so too should the fee in order to commit the transaction to the chain as soon as
+possible. Once the transaction is mined, it makes useless the public key revealed by spending a UTXO, so long as it is
+never reused.
 
 It is proposed to implement a Pay to Quantum Resistant Hash (P2QRH) address type that relies on a PQC signature
 algorithm. This new address type protects transactions submitted to the mempool and helps preserve the free market by
 preventing the need for private, out-of-band mempool transactions.
 
-The following table is non-exhaustive but intended to inform the average Bitcoin user whether their bitcoin is
-vulnerable to a long-range quantum attack:
+The following table is intended to inform the average Bitcoin user whether their bitcoin is vulnerable to a long-range
+quantum attack:
 
 {| class="wikitable"
 |+ Vulnerable output types
 |-
 ! Type !! Vulnerable !! Prefix !! Example
 |-
-| P2PK || Yes || 04 ||
-0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f8141781e62294721166bf621e73a82cbf
-2342c858ee
+| P2PK || Yes || Varies || 2103203b768951584fe9af6d9d9e6ff26a5f76e453212f19ba163774182ab8057f3eac
 |-
 | P2PKH || No || 1 || 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
 |-
+| P2MS || Yes || Varies || 52410496ec45f878b62c46c4be8e336dff7cc58df9b502178cc240e...
+|-
+| P2SH || No || 5 || 3FkhZo7sGNue153xhgqPBcUaBsYvJW6tTx
+|-
 | P2WPKH || No || bc1q || bc1qsnh5ktku9ztqeqfr89yrqjd05eh58nah884mku
 |-
+| P2WSH || No || bc1q || bc1qvhu3557twysq2ldn6dut6rmaj3qk04p60h9l79wk4lzgy0ca8mfsnffz65
+|-
 | P2TR || Yes || bc1p || bc1p92aslsnseq786wxfk3ekra90ds9ku47qttupfjsqmmj4z82xdq4q3rr58u
+|-
+| P2QRH || No || bc1r || bc1r8rt68aze8tek87cnz4ndnvfzk6tk93jv39n4lmpu5a4yw453rcpszsft3z
 |}
 
 It should be noted that Taproot outputs are vulnerable in that they encode a 32-byte x-only public key, from which a
@@ -113,14 +127,13 @@ Short-range attacks require much larger, more expensive CRQCs since they must be
 before a transaction is mined. Long-range attacks can be executed over a longer timeframe since the public key remains
 exposed on the blockchain indefinitely.
 
-Should quantum advantage manifest, a convention is proposed in spending the full 65-byte P2PK key used by the coinbase
-output in Block 1 back to itself. It is proposed to call the address in Block 1 the
+Should quantum advantage manifest, a convention is proposed in spending the 65-byte P2PK output used by the coinbase
+output in Block 1. It is proposed to call the address in Block 1 the
 [https://mempool.space/address/0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f81
-41781e62294721166bf621e73a82cbf2342c858ee
-Canary address] since it can only be spent from by others (assuming Satoshi's continued absence) if secp256k1 is
-broken. Should the Canary coins move, that will signal that reliance on secp256k1 is presently vulnerable. Without the
-Canary, or an address like it, there may be some doubt as to whether the coins were moved with keys belonging to the
-original owner.
+41781e62294721166bf621e73a82cbf2342c858ee Canary address] since it can only be spent from by others (assuming Satoshi's
+ continued absence) if secp256k1 is broken. Should the Canary coins move, that will signal that reliance on secp256k1
+is presently vulnerable. Without the Canary, or an address like it, there may be some doubt as to whether the coins were
+moved with keys belonging to the original owner.
 
 Coinbase outputs to P2PK keys go as far as block 200,000, so there are, at the time of writing, 1,723,848 coins that
 are vulnerable from the first epoch at the time of writing in P2PK outputs alone. The majority of these have a
@@ -156,8 +169,7 @@ This is the first in a series of BIPs under a QuBit soft fork. A qubit is a fund
 the capital B refers to Bitcoin. The name QuBit also rhymes to some extent with SegWit.
 
 It is proposed to use SegWit version 3. This results in addresses that start with bc1r, which could be a useful way to
-remember that these are quantum (r)esistant addresses (similar to how bc1q corresponds to Se(q)Wit and bc1p corresponds
-to Ta(p)root). This is referencing the lookup table under
+remember that these are quantum (r)esistant addresses. This is referencing the lookup table under
 [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32 BIP-173].
 
 The proposal above also leaves a gap in case it makes sense to use version 2, or bc1z, for implementation of other
@@ -169,11 +181,9 @@ should a vulnerability exist in one of the signature algorithms used. One key di
 however is that P2QRH will encode a hash of the public key. This is a significant deviation from how Taproot works by
 itself, but it is necessary to avoid exposing public keys on-chain where they are vulnerable to attack.
 
-P2QRH uses a 32-byte HASH256 (specifically SHA-256 twice-over, which is similar to that used in
-[https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#specification BIP-16]) of the public key to reduce the
-size of new outputs and also to increase security by not having the public key available on-chain. This hash serves as
-a minimal cryptographic commitment to a public key. It goes into the output spend script, which does not receive the
-witness discount.
+P2QRH uses a 32-byte HASH256 (specifically SHA-256 twice-over) of the public key to reduce the size of new outputs and
+also to increase security by not having the public key available on-chain. This hash serves as a minimal cryptographic
+commitment to a public key. It goes into the scriptPubKey, which does not receive the witness discount.
 
 Post-quantum public keys are generally larger than those used by ECC, depending on the security level. To promote user
 adoption and general user-friendliness, the most secure variant (NIST Level V, 256-bit security) is proposed, despite
@@ -316,20 +326,21 @@ Following BIP-141, a new transaction serialization format is introduced to inclu
 
 The attestation field consists of:
 
-* num_pubkeys: The number of public keys (VarInt encoded).
+* num_pubkeys: The number of public keys
+([https://learnmeabitcoin.com/technical/general/compact-size/ compact size]).
 
 For each public key:
 
-* pubkey_length: VarInt encoded length of the public key.
+* pubkey_length: compact size length of the public key.
 * pubkey: The public key bytes.
 
 Then:
 
-* num_signatures: The number of signatures (VarInt encoded).
+* num_signatures: The number of signatures (compact size).
 
 For each signature:
 
-* signature_length: VarInt encoded length of the signature.
+* signature_length: compact size length of the signature.
 * signature: The signature bytes.
 
 This structure repeats for each input, in order, for flexibility in supporting multisig schemes and various
@@ -573,6 +584,7 @@ seeds to act as the authoritative secret when signing. These measures are deemed
 
 To help implementors understand updates to this BIP, we keep a list of substantial changes.
 
+* 2024-12-20 - Address feedback from vostrnad.
 * 2024-12-18 - Assigned BIP number.
 * 2024-12-13 - Update to use merkle tree for attestation commitment. Update LR & SR quantum attack scenarios.
 * 2024-12-06 - Update title and formatting.
@@ -593,4 +605,4 @@ the design of the P2TR (Taproot) output type using Schnorr signatures.
 Much gratitude to my co-founder, Kyle Crews for proofreading and editing, to David Croisant, who suggested the name
 "QuBit", and Guy Swann for pointing out the earlier name for the attestation, "quitness", was imperfect. Thank you as
 well to those who took the time to review and contribute, including Jeff Bride, Adam Borcany, Antoine Riard, Pierre-Luc
-Dallaire-Demers, Ethan Heilman, Jon Atack, Jameson Lopp, and Murchandamus.
+Dallaire-Demers, Ethan Heilman, Jon Atack, Jameson Lopp, Murchandamus, and Vojtěch Strnad.

From 4b8b6470e6e46a22a50595b060875f12bc17cb99 Mon Sep 17 00:00:00 2001
From: Hunter Trujillo 
Date: Fri, 20 Dec 2024 11:46:31 -0700
Subject: [PATCH 26/32] Update typos list.

---
 .typos.toml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.typos.toml b/.typos.toml
index 4f9fbef9af..8ff6f5309d 100644
--- a/.typos.toml
+++ b/.typos.toml
@@ -16,6 +16,7 @@ extend-ignore-re = [
     "prefix.*",
     "value: .*",
     "pqNTRUsign",
+    "Strnad",
 ]
 
 [default.extend-words]

From 990d8a87b5181fd4f0d50a1b65b53fbc02bc6330 Mon Sep 17 00:00:00 2001
From: Hunter Trujillo 
Date: Fri, 20 Dec 2024 13:02:33 -0700
Subject: [PATCH 27/32] Fixes, typos, formatting.

---
 bip-0360.mediawiki | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/bip-0360.mediawiki b/bip-0360.mediawiki
index aa841f5855..6d859cba7e 100644
--- a/bip-0360.mediawiki
+++ b/bip-0360.mediawiki
@@ -90,7 +90,7 @@ quantum attack:
 |-
 | P2MS || Yes || Varies || 52410496ec45f878b62c46c4be8e336dff7cc58df9b502178cc240e...
 |-
-| P2SH || No || 5 || 3FkhZo7sGNue153xhgqPBcUaBsYvJW6tTx
+| P2SH || No || 3 || 3FkhZo7sGNue153xhgqPBcUaBsYvJW6tTx
 |-
 | P2WPKH || No || bc1q || bc1qsnh5ktku9ztqeqfr89yrqjd05eh58nah884mku
 |-
@@ -131,7 +131,7 @@ Should quantum advantage manifest, a convention is proposed in spending the 65-b
 output in Block 1. It is proposed to call the address in Block 1 the
 [https://mempool.space/address/0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f81
 41781e62294721166bf621e73a82cbf2342c858ee Canary address] since it can only be spent from by others (assuming Satoshi's
- continued absence) if secp256k1 is broken. Should the Canary coins move, that will signal that reliance on secp256k1
+continued absence) if secp256k1 is broken. Should the Canary coins move, that will signal that reliance on secp256k1
 is presently vulnerable. Without the Canary, or an address like it, there may be some doubt as to whether the coins were
 moved with keys belonging to the original owner.
 
@@ -326,8 +326,7 @@ Following BIP-141, a new transaction serialization format is introduced to inclu
 
 The attestation field consists of:
 
-* num_pubkeys: The number of public keys
-([https://learnmeabitcoin.com/technical/general/compact-size/ compact size]).
+* num_pubkeys: The number of public keys ([https://learnmeabitcoin.com/technical/general/compact-size/ compact size]).
 
 For each public key:
 

From 0fdd8c3edc9e563bcf5a7cb0cc93e6f428b948d8 Mon Sep 17 00:00:00 2001
From: Hunter Trujillo 
Date: Fri, 20 Dec 2024 16:12:31 -0700
Subject: [PATCH 28/32] Updates based on Murch and vostrnad feedback.

---
 bip-0360.mediawiki | 119 +++++++++++++++++++++++++++------------------
 1 file changed, 71 insertions(+), 48 deletions(-)

diff --git a/bip-0360.mediawiki b/bip-0360.mediawiki
index 6d859cba7e..49cd27a2ff 100644
--- a/bip-0360.mediawiki
+++ b/bip-0360.mediawiki
@@ -1,6 +1,6 @@
 
   BIP: 360
-  Title: QuBit: SegWit v3 spending rules (P2QRH)
+  Title: Pay to Quantum Resistant Hash
   Layer: Consensus (soft fork)
   Author: Hunter Beast 
   Comments-Summary: No comments yet.
@@ -29,12 +29,11 @@ The primary threat to Bitcoin from Cryptoanalytically-Relevant Quantum Computers
 the cryptographic assumptions of Elliptic Curve Cryptography (ECC), which secures Bitcoin's signatures and Taproot
 commitments. Specifically, [https://arxiv.org/pdf/quant-ph/0301141 Shor's algorithm] enables a CRQC to solve the
 Discrete Logarithm Problem (DLP) exponentially faster than classical methodsShor's algorithm is
-believed to need 10^8 operations to break a 256-bit elliptic curve public key., allowing the derivation of private
-keys from public keys—a process referred to as quantum key decryption. Importantly, simply increasing the public key
-length (e.g., using a hypothetical secp512k1 curve) would only make deriving the private key twice as hard, offering
-insufficient protection. The computational complexity of this attack is further explored in
-[https://pubs.aip.org/avs/aqs/article/4/1/013801/2835275/The-impact-of-hardware-specifications-on-reaching ''The impact
-of hardware specifications on reaching quantum advantage in the fault-tolerant regime''].
+believed to need 10^8 operations to break a 256-bit elliptic curve public key., allowing the derivation of
+private keys from public keys—a process referred to as quantum key decryption. Importantly, simply doubling the public
+key length (e.g., using a hypothetical secp512k1 curve) would only make deriving the private key twice as hard,
+offering insufficient protection. The computational complexity of this attack is further explored in
+[https://pubs.aip.org/avs/aqs/article/4/1/013801/2835275/The-impact-of-hardware-specifications-on-reaching ''The impact of hardware specifications on reaching quantum advantage in the fault-tolerant regime''].
 
 This proposal aims to mitigate these risks by introducing a Pay to Quantum Resistant Hash (P2QRH) output type that
 relies on post-quantum cryptographic (PQC) signature algorithms. By adopting PQC, Bitcoin can enhance its quantum
@@ -44,7 +43,7 @@ The vulnerability of existing Bitcoin addresses is investigated in
 [https://web.archive.org/web/20240715101040/https://www2.deloitte.com/nl/nl/pages/innovatie/artikelen/quantum-computers-
 and-the-bitcoin-blockchain.html this Deloitte report]. The report estimates that in 2020 approximately 25% of the
 Bitcoin supply is held within addresses vulnerable to quantum attack. As of the time of writing, that number is now
-closer to 20%. Additionally, cryptographer Pieter Wuille [https://x.com/pwuille/status/1108085284862713856 reasons]
+closer to 20%. Independently, Bitcoin developer Pieter Wuille [https://x.com/pwuille/status/1108085284862713856 reasons]
 even more might be vulnerable.
 
 Ordinarily, when a transaction is signed, the public key is explicitly stated in the input script. This means that the
@@ -72,8 +71,8 @@ As the value being sent increases, so too should the fee in order to commit the
 possible. Once the transaction is mined, it makes useless the public key revealed by spending a UTXO, so long as it is
 never reused.
 
-It is proposed to implement a Pay to Quantum Resistant Hash (P2QRH) address type that relies on a PQC signature
-algorithm. This new address type protects transactions submitted to the mempool and helps preserve the free market by
+It is proposed to implement a Pay to Quantum Resistant Hash (P2QRH) output type that relies on a PQC signature
+algorithm. This new output type protects transactions submitted to the mempool and helps preserve the free market by
 preventing the need for private, out-of-band mempool transactions.
 
 The following table is intended to inform the average Bitcoin user whether their bitcoin is vulnerable to a long-range
@@ -101,11 +100,13 @@ quantum attack:
 | P2QRH || No || bc1r || bc1r8rt68aze8tek87cnz4ndnvfzk6tk93jv39n4lmpu5a4yw453rcpszsft3z
 |}
 
+Note: Funds are only safe in P2PKH, P2SH, P2WPKH, and P2WSH outputs if they haven't used the address before.
+
 It should be noted that Taproot outputs are vulnerable in that they encode a 32-byte x-only public key, from which a
 full public key can be reconstructed.
 
-If a key is recovered by a CRQC it can also be trivially checked to see if any child keys were produced using an
-unhardened [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-32] derivation path.
+Derivation of child keys (whether hardened or not) requires the chain code, so this is only a concern if the attacker
+has access to the extended public key (in which case they can just directly convert it to an extended private key).
 
 ==== Long Range and Short Range Quantum Attacks ====
 
@@ -115,13 +116,12 @@ period of time, giving an attacker ample opportunity to break the cryptography.
 * P2PK outputs (Satoshi's coins, CPU miners, starts with 04)
 * Reused addresses (any type, except P2QRH)
 * Taproot addresses (starts with bc1p)
-* Unhardened BIP-32 HD wallet keys
+* Wallet descriptor extended public keys, commonly known as "xpubs"
 
 Short Range Quantum Attack is an attack that must be executed quickly while a transaction is still in the mempool,
 before it gets mined into a block. This affects:
 
 * Any transaction in the mempool (except for P2QRH)
-* Unhardened BIP-32 HD wallet keys
 
 Short-range attacks require much larger, more expensive CRQCs since they must be executed within the short window
 before a transaction is mined. Long-range attacks can be executed over a longer timeframe since the public key remains
@@ -147,7 +147,7 @@ transition Bitcoin to implement post-quantum security.
 It's for the above reason that, for those who wish to be prepared for quantum emergency, it is recommended that no more
 than 50 bitcoin are kept under a single, distinct, unused Native SegWit (P2WPKH, "bc1q") address at a time. This is
 assuming that the attacker is financially motivated instead of, for example, a nation state looking to break confidence
-in Bitcoin. Additionally, this assumes that other vulnerable targets such as central banks have upgraded their
+in Bitcoin. Independently, this assumes that other vulnerable targets such as central banks have upgraded their
 cryptography by this time.
 
 The Commercial National Security Algorithm Suite (CNSA) 2.0 has a timeline for software and networking equipment to be
@@ -172,9 +172,6 @@ It is proposed to use SegWit version 3. This results in addresses that start wit
 remember that these are quantum (r)esistant addresses. This is referencing the lookup table under
 [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32 BIP-173].
 
-The proposal above also leaves a gap in case it makes sense to use version 2, or bc1z, for implementation of other
-address formats such as those that employ Cross Input Signature Aggregation (CISA).
-
 P2QRH is meant to be implemented on top of P2TR, combining the security of classical Schnorr signatures along with
 post-quantum cryptography. This is a form of hybrid cryptography such that no regression in security is presented
 should a vulnerability exist in one of the signature algorithms used. One key distinction between P2QRH and P2TR
@@ -183,7 +180,9 @@ itself, but it is necessary to avoid exposing public keys on-chain where they ar
 
 P2QRH uses a 32-byte HASH256 (specifically SHA-256 twice-over) of the public key to reduce the size of new outputs and
 also to increase security by not having the public key available on-chain. This hash serves as a minimal cryptographic
-commitment to a public key. It goes into the scriptPubKey, which does not receive the witness discount.
+commitment to a public key in the style of a
+[https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#user-content-Witness_program BIP-141 witness program].
+Because it goes into the scriptPubKey, it does not receive a witness or attestation discount.
 
 Post-quantum public keys are generally larger than those used by ECC, depending on the security level. To promote user
 adoption and general user-friendliness, the most secure variant (NIST Level V, 256-bit security) is proposed, despite
@@ -204,22 +203,8 @@ inscriptions would also have the scarcity of their non-monetary assets affected.
 while also increasing the discount is to have a completely separate witness—a "quantum witness." Because it is meant
 only for public keys and signatures, we call this section of the transaction the attestation.
 
-To address the risk of arbitrary data being stored using P2QRH (QuBit) outputs, very specific rules will be applied
-to spending from the witness stack in SegWit v3 outputs. A fixed signature size will be necessary for spending the
-output, and the output must be spendable to be considered valid within node consensus. A fixed signature size will also
-be helpful to disambiguate between signature types without an additional version byte, as SQIsign signatures are
-substantially smaller than FALCON signatures. Consequently, the correct signature algorithm can be inferred through
-byte length. The public key and signature will be pushed separately to the attestation stack. Multiple signatures can
-be included in order to support multisig applications, and also for spending multiple inputs.
-
-Since only valid signatures can be committed to in a SegWit v3 attestation, arbitrary data cannot be added by miners,
-as that would affect the consensus of their block. A CRQC operator is economically disincentivized from computing a
-spendable public key that matched arbitrary signature data due to the cost of that computation. That is because the
-cost of such a computation could prove quite substantial, rather than simply putting the arbitrary data within a
-Taproot witness.
-
-Additionally, it should be noted, whether an output with a P2QRH spend script corresponds to a FALCON or SQIsign
-signature is not known until the output is spent.
+Additionally, it should be noted, whether an output with a P2QRH spend script corresponds to a PQC signature is not
+known until the output is spent.
 
 While it might be seen as a maintenance burden for Bitcoin ecosystem devs to go from a single cryptosystem
 implementation to four additional distinct PQC cryptosystems—and it most certainly is—the ramifications of a chain
@@ -234,10 +219,17 @@ Bitcoin, but their signatures are smaller and might be considered by some to be
 signatures. SQIsign is much smaller; however, it is based on a very novel form of cryptography known as supersingular
 elliptic curve quaternion isogeny, and at the time of writing, is not yet approved by NIST or the broader PQC community.
 
+The inclusion of these four PQC cryptosystems is in the interest of supporting hybrid cryptography, especially for
+high value outputs, such as cold wallets used by exchanges. To improve the viability of the activation client, and
+adoption by wallets and libraries, a library akin to libsecp256k1 will be developed to support the new PQC
+cryptosystems.
+
 In the distant future, following the implementation of the P2QRH output type in a QuBit soft fork, there will likely
-be a need for Pay to Quantum Secure (P2QS) addresses. These will require specialized quantum hardware for signing,
-while still [https://quantum-journal.org/papers/q-2023-01-19-901/ using public keys that are verifiable via classical
-means]. Additional follow-on BIPs will be needed to implement P2QS. However, until specialized quantum cryptography
+be a need for Pay to Quantum Secure (P2QS) addresses. A distinction is made between cryptography that's merely resistant
+to quantum attack, and cryptography that's secured by specialized quantum hardware. P2QRH is resistant to quantum
+attack, while P2QS is quantum secure. These will require specialized quantum hardware for signing, while still
+[https://quantum-journal.org/papers/q-2023-01-19-901/ using public keys that are verifiable via classical means].
+Additional follow-on BIPs will be needed to implement P2QS. However, until specialized quantum cryptography
 hardware is widespread, quantum resistant addresses should be an adequate intermediate solution.
 
 == Specification ==
@@ -256,7 +248,9 @@ its argument. For example:
   qrh(HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ...))
 
 This function allows wallets to manage P2QRH addresses and outputs while accommodating multiple public keys of varying
-lengths, such as in multisig schemes, while keeping the public keys hidden until the time of spending.
+lengths, such as in multisig schemes, while keeping the public keys hidden until the time of spending. At a minimum,
+there should be two public keys in a P2QRH output, one that makes use of classical cryptography and one that makes use
+of a PQC algorithm chosen within the wallet.
 
 === Address Format ===
 
@@ -277,11 +271,32 @@ The scriptPubKey for a P2QRH output is:
 Where:
 
 * OP_PUSHNUM_3 (0x03) indicates SegWit version 3.
-*  is the 32-byte HASH256 of the concatenated HASH256 of each public key.
+*  is the 32-byte HASH256 of the merkle root of a tree of public key hashes, as defined in the
+Hash Computation section.
+
+=== Output Mechanics ===
+
+To address the risk of arbitrary data being stored using P2QRH (QuBit) outputs, very specific rules will be applied
+to spending from the witness stack in SegWit v3 outputs. A fixed signature size will be necessary for spending the
+output, and the output must be spendable to be considered valid within node consensus. A fixed signature size will also
+be helpful to disambiguate between signature types without an additional version byte, as SQIsign signatures are
+substantially smaller than FALCON signatures. Consequently, the correct signature algorithm can be inferred through
+byte length. The public key and signature will be pushed separately to the attestation stack. Multiple signatures can
+be included in order to support multisig applications, and also for spending multiple inputs.
+
+Since only valid signatures can be committed to in a SegWit v3 attestation, arbitrary data cannot be added by miners,
+as that would affect the consensus of their block. A CRQC operator is economically disincentivized from computing a
+spendable public key that matched arbitrary signature data due to the cost of that computation. That is because the
+cost of such a computation could prove quite substantial, rather than simply putting the arbitrary data within a
+Taproot witness.
 
 ==== Hash Computation ====
 
-The hash is computed as a merkle tree of public key hashes:
+If there is only a single public key, the hash is computed as the HASH256 of the public key, as if it were a
+merkle root.
+
+In order to support multiple keys, as in the context of multisig or singlesig hybrid cryptography, the hash is
+computed as a merkle tree of multiple public key hashes:
 
 1. For each public key, compute its HASH256
 2. Pair the hashes and compute HASH256 of their concatenation
@@ -318,10 +333,19 @@ Following BIP-141, a new transaction serialization format is introduced to inclu
 
 * marker: 0x00 (same as SegWit)
 
-* flag: 0x02 (indicates the presence of both witness and attestation data)
+* flag:
+
+** 0x02 (indicates the presence of attestation data only)
+** 0x03 (indicates the presence of both witness and attestation data)
 
 * attestation: Contains the quantum-resistant public keys and signatures.
 
+=== Transaction ID ===
+
+The transaction ID is computed as the HASH256 of the serialized transaction, including the attestation and witness
+(if a witness is present). When decoded, this is called the qtxid, which will differ from the txid and wtxid if an
+attestation is present.
+
 === Attestation Structure ===
 
 The attestation field consists of:
@@ -370,6 +394,9 @@ Supported PQC algorithms and their NIST Level V parameters:
 
 Implementations must reject public keys and signatures that do not match expected lengths for supported algorithms.
 
+If there a new algorithm is added, and one of the byte sizes overlaps, then an additional byte should be prepended to the
+new algorithm's public key length that indicates the specific algorithm used.
+
 === Script Validation ===
 
 To spend a P2QRH output, the following conditions must be met:
@@ -572,8 +599,8 @@ seeds to act as the authoritative secret when signing. These measures are deemed
 
 * [https://groups.google.com/g/bitcoindev/c/Aee8xKuIC2s/m/cu6xej1mBQAJ Mailing list discussion]
 * [https://delvingbitcoin.org/t/proposing-a-p2qrh-bip-towards-a-quantum-resistant-soft-fork/956?u=cryptoquick Delving Bitcoin discussion]
-* [https://bitcoinops.org/en/newsletters/2024/06/14/ Bitcoin OpTech newsletter]
-* [https://bitcoinops.org/en/podcast/2024/06/18/#draft-bip-for-quantum-safe-address-format Bitcoin OpTech discussion transcript]
+* [https://bitcoinops.org/en/newsletters/2024/06/14/ Bitcoin Optech newsletter]
+* [https://bitcoinops.org/en/podcast/2024/06/18/#draft-bip-for-quantum-safe-address-format Bitcoin Optech discussion transcript]
 
 == Footnotes ==
 
@@ -583,13 +610,9 @@ seeds to act as the authoritative secret when signing. These measures are deemed
 
 To help implementors understand updates to this BIP, we keep a list of substantial changes.
 
-* 2024-12-20 - Address feedback from vostrnad.
 * 2024-12-18 - Assigned BIP number.
 * 2024-12-13 - Update to use merkle tree for attestation commitment. Update LR & SR quantum attack scenarios.
-* 2024-12-06 - Update title and formatting.
-* 2024-12-03 - MediaWiki formatting fixes.
 * 2024-12-01 - Add details on attestation structure and parsing.
-* 2024-11-20 - Clarifications based on feedback from Murch. Remove some sections that are not yet ready.
 * 2024-10-21 - Replace XMSS with CRYSTALS-Dilithium due to NIST approval and size constraints.
 * 2024-09-30 - Refactor the ECC vs PoW section. Swap quitness for attestation.
 * 2024-09-29 - Update section on PoW to include partial-preimage.

From 208a987f2fbff9be180df7188ccea8ede558ff98 Mon Sep 17 00:00:00 2001
From: Hunter Trujillo 
Date: Fri, 20 Dec 2024 16:18:44 -0700
Subject: [PATCH 29/32] Fix title change in README.

---
 README.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.mediawiki b/README.mediawiki
index a5eeabd778..b8ea337472 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -1151,7 +1151,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 |-
 | [[bip-0360.mediawiki|360]]
 | Consensus (soft fork)
-| QuBit: SegWit v3 spending rules (P2QRH)
+| Pay to Quantum Resistant Hash
 | Hunter Beast
 | Standard
 | Draft

From 8eb35c89a33c3e5e6b44c72cb905778aa3b23a99 Mon Sep 17 00:00:00 2001
From: Hunter Beast 
Date: Mon, 23 Dec 2024 15:22:54 -0700
Subject: [PATCH 30/32] Apply suggestions from code review

Co-authored-by: Mark "Murch" Erhardt 
---
 bip-0360.mediawiki | 21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/bip-0360.mediawiki b/bip-0360.mediawiki
index 49cd27a2ff..57c36dace5 100644
--- a/bip-0360.mediawiki
+++ b/bip-0360.mediawiki
@@ -85,28 +85,28 @@ quantum attack:
 |-
 | P2PK || Yes || Varies || 2103203b768951584fe9af6d9d9e6ff26a5f76e453212f19ba163774182ab8057f3eac
 |-
-| P2PKH || No || 1 || 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
+| P2PKH || No¹ || 1 || 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
 |-
 | P2MS || Yes || Varies || 52410496ec45f878b62c46c4be8e336dff7cc58df9b502178cc240e...
 |-
-| P2SH || No || 3 || 3FkhZo7sGNue153xhgqPBcUaBsYvJW6tTx
+| P2SH || No¹ || 3 || 3FkhZo7sGNue153xhgqPBcUaBsYvJW6tTx
 |-
-| P2WPKH || No || bc1q || bc1qsnh5ktku9ztqeqfr89yrqjd05eh58nah884mku
+| P2WPKH || No¹ || bc1q || bc1qsnh5ktku9ztqeqfr89yrqjd05eh58nah884mku
 |-
-| P2WSH || No || bc1q || bc1qvhu3557twysq2ldn6dut6rmaj3qk04p60h9l79wk4lzgy0ca8mfsnffz65
+| P2WSH || No¹ || bc1q || bc1qvhu3557twysq2ldn6dut6rmaj3qk04p60h9l79wk4lzgy0ca8mfsnffz65
 |-
 | P2TR || Yes || bc1p || bc1p92aslsnseq786wxfk3ekra90ds9ku47qttupfjsqmmj4z82xdq4q3rr58u
 |-
 | P2QRH || No || bc1r || bc1r8rt68aze8tek87cnz4ndnvfzk6tk93jv39n4lmpu5a4yw453rcpszsft3z
 |}
 
-Note: Funds are only safe in P2PKH, P2SH, P2WPKH, and P2WSH outputs if they haven't used the address before.
+¹ Funds in P2PKH, P2SH, P2WPKH, and P2WSH outputs become vulnerable to long-range quantum attacks when their input script is revealed. An address is no longer safe against long-range quantum attacks after funds from it have been spent.
 
 It should be noted that Taproot outputs are vulnerable in that they encode a 32-byte x-only public key, from which a
 full public key can be reconstructed.
 
-Derivation of child keys (whether hardened or not) requires the chain code, so this is only a concern if the attacker
-has access to the extended public key (in which case they can just directly convert it to an extended private key).
+If an extended public key’s (xPub’s) parent private key of is recovered by CRQC, the attacker also recovers
+the entire extended private key, whether it uses hardened or unhardened derivation.
 
 ==== Long Range and Short Range Quantum Attacks ====
 
@@ -116,7 +116,8 @@ period of time, giving an attacker ample opportunity to break the cryptography.
 * P2PK outputs (Satoshi's coins, CPU miners, starts with 04)
 * Reused addresses (any type, except P2QRH)
 * Taproot addresses (starts with bc1p)
-* Wallet descriptor extended public keys, commonly known as "xpubs"
+* Extended public keys, commonly known as "xpubs"
+* Wallet descriptors
 
 Short Range Quantum Attack is an attack that must be executed quickly while a transaction is still in the mempool,
 before it gets mined into a block. This affects:
@@ -276,8 +277,8 @@ Hash Computation section.
 
 === Output Mechanics ===
 
-To address the risk of arbitrary data being stored using P2QRH (QuBit) outputs, very specific rules will be applied
-to spending from the witness stack in SegWit v3 outputs. A fixed signature size will be necessary for spending the
+To prevent storage of arbitrary data using P2QRH (QuBit) outputs,
+the witness stack for inputs spending segwit v3 outputs is limited to the fixed-size signatures necessary for spending the
 output, and the output must be spendable to be considered valid within node consensus. A fixed signature size will also
 be helpful to disambiguate between signature types without an additional version byte, as SQIsign signatures are
 substantially smaller than FALCON signatures. Consequently, the correct signature algorithm can be inferred through

From d9bb0ffef13e0daf603dcd36bc8dbbf7769f58fc Mon Sep 17 00:00:00 2001
From: Hunter Trujillo 
Date: Mon, 23 Dec 2024 15:26:24 -0700
Subject: [PATCH 31/32] Fix broken link.

---
 bip-0360.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0360.mediawiki b/bip-0360.mediawiki
index 57c36dace5..c339ebef4e 100644
--- a/bip-0360.mediawiki
+++ b/bip-0360.mediawiki
@@ -130,8 +130,8 @@ exposed on the blockchain indefinitely.
 
 Should quantum advantage manifest, a convention is proposed in spending the 65-byte P2PK output used by the coinbase
 output in Block 1. It is proposed to call the address in Block 1 the
-[https://mempool.space/address/0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f81
-41781e62294721166bf621e73a82cbf2342c858ee Canary address] since it can only be spent from by others (assuming Satoshi's
+[https://mempool.space/address/0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f8141781e62294721166bf621e73a82cbf2342c858ee Canary address]
+since it can only be spent from by others (assuming Satoshi's
 continued absence) if secp256k1 is broken. Should the Canary coins move, that will signal that reliance on secp256k1
 is presently vulnerable. Without the Canary, or an address like it, there may be some doubt as to whether the coins were
 moved with keys belonging to the original owner.

From 0ae69db70a4a28f202d441b7131cd5b2169e7afe Mon Sep 17 00:00:00 2001
From: Hunter Trujillo 
Date: Mon, 23 Dec 2024 15:47:26 -0700
Subject: [PATCH 32/32] Remove Canary section.

---
 bip-0360.mediawiki | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/bip-0360.mediawiki b/bip-0360.mediawiki
index c339ebef4e..143dddf857 100644
--- a/bip-0360.mediawiki
+++ b/bip-0360.mediawiki
@@ -128,14 +128,6 @@ Short-range attacks require much larger, more expensive CRQCs since they must be
 before a transaction is mined. Long-range attacks can be executed over a longer timeframe since the public key remains
 exposed on the blockchain indefinitely.
 
-Should quantum advantage manifest, a convention is proposed in spending the 65-byte P2PK output used by the coinbase
-output in Block 1. It is proposed to call the address in Block 1 the
-[https://mempool.space/address/0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f8141781e62294721166bf621e73a82cbf2342c858ee Canary address]
-since it can only be spent from by others (assuming Satoshi's
-continued absence) if secp256k1 is broken. Should the Canary coins move, that will signal that reliance on secp256k1
-is presently vulnerable. Without the Canary, or an address like it, there may be some doubt as to whether the coins were
-moved with keys belonging to the original owner.
-
 Coinbase outputs to P2PK keys go as far as block 200,000, so there are, at the time of writing, 1,723,848 coins that
 are vulnerable from the first epoch at the time of writing in P2PK outputs alone. The majority of these have a
 block reward of 50 coins each, and there are roughly 34,000 distinct P2PK scripts that are vulnerable. These coins