diff --git a/bip-0360.mediawiki b/bip-0360.mediawiki index ff700e567b..06e44ab196 100644 --- a/bip-0360.mediawiki +++ b/bip-0360.mediawiki @@ -11,698 +11,396 @@ Type: Standards Track Created: 2024-12-18 License: BSD-3-Clause + Requires: 340, 341, 342 -== Introduction == +==Introduction== -=== Abstract === +===Abstract=== -This document proposes the introduction of a new output type, Pay to Quantum Resistant Hash (P2QRH), via a soft fork. -P2QRH provides the same tapscript functionality as Pay to Taproot (P2TR) but removes the quantum-vulnerable -key path spend in P2TR. By itself, P2QRH provides protection against long-exposure quantum attacks, -but requires PQ signatures to provide full security against Cryptographically Relevant Quantum Computers (CRQCs). -P2QRH is designed to provide the foundation necessary for a future soft fork activating PQ signature verification -in tapscript. +This document proposes a new output type: Pay-to-Tapscript-Hash (P2TSH), via a soft fork. P2TSH outputs operate with nearly the same functionality as P2TR (Pay-to-Taproot) outputs, but with the key path spend removed. -=== Copyright === +Through this modification, P2TSH outputs allow developers to use tapscript in a manner that is: + +# resistant to long exposure attacks by Cryptographically Relevant Quantum Computers (CRQCs), and +# resistant to future cryptanalytic approaches that may compromise the elliptic curve cryptography (ECC) used by Bitcoin. + +It is worth noting that proposed P2TSH outputs are only resistant to "long exposure attacks" on elliptic curve cryptography; that is, attacks on keys exposed for time periods longer than needed to confirm a spending transaction. + +Protection against more sophisticated quantum attacks, including protection against private key recovery from public keys exposed in the mempool while a transaction is waiting to be confirmed (a.k.a. "short exposure attacks"), may require the introduction of post-quantum signatures in Bitcoin. We believe it's worth considering this path in the future and intend to offer a separate proposal for this purpose upon further research. + +This document additionally defines "long exposure" and "short exposure" attacks, and other new terminology in the Glossary. + +===Copyright=== This document is licensed under the 3-clause BSD license. -=== Motivation === - -The primary threat to Bitcoin from Cryptographically Relevant Quantum Computers (CRQCs) -A Cryptographically Relevant Quantum Computer is an ''object'' which is only loosely defined by ''characteristics'' in quantum physics as of today. It could be understood in the context of this BIP and in Bitcoin that it's a ''hardware-agnostic'' computer supposed to have the architecture to keep ''coherent'' a sufficient number of logical qubits to be able to run the Shor algorithm in an efficient fashion. -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 here as quantum key decryption. -Meaning, deriving private keys from public keys via Shor's algorithm -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 -makes tapscript quantum resistant and enables the use of PQ 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 addressesA vulnerable Bitcoin address is any -''scriptPubKey'' type that exposes an elliptic curve public key as ''raw bytes'' in a ''block'', making it susceptible -to private key derivation through Shor's algorithm. This includes P2PK outputs and any script that contains an -unprotected or reused public key. is detailed 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%. Independently, Bitcoin developer Pieter -Wuille [https://web.archive.org/web/20220531184542/https://twitter.com/pwuille/status/1108085284862713856 reasons] even -more addresses might be vulnerable, representing 5M to 10M bitcoins. - -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. It also doesn't account for block reorg attacks, which would -reveal public keys in blocks that were once mined but are now orphaned and must be mined again. Additionally, -it depends on the mining pool whether they reveal their block template to either the public or to miners. - -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-exposure CRQC attack" recovering -the key behind high-value addresses. A long-exposure 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-exposure 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. -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 a 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. - -As the first step to address these issues we propose Pay to Quantum Resistant Hash (P2QRH), an output type that allows -tapscript to be used in a quantum resistant manner. -This new output type protects transactions submitted to the mempool and helps preserve the fee 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-exposure -quantum attack: +===Motivation=== + +The primary threat to Bitcoin from Cryptographically Relevant Quantum Computers (CRQCs) is their potential to break the key cryptographic assumption which secures the digital signatures used in Bitcoin.A Cryptographically Relevant Quantum Computer is an ''object'' which is only loosely defined by ''characteristics'' in quantum physics as of today. It could be understood in the context of this BIP and in Bitcoin that it's a ''hardware-agnostic'' computer supposed to have the architecture to keep ''coherent'' a sufficient number of logical qubits to be able to run Shor's algorithm in an efficient fashion. More 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 methods.Shor's algorithm is believed to need 10^8 operations to break a 256-bit elliptic curve public key. This allows the derivation of private keys from public keys - a process referred to here as quantum key recovery.Meaning, deriving private keys from public keys via Shor's algorithm While it is unclear when or if CRQCs will become viable in the future, we propose the addition of a quantum-resistant, tapscript-native output type for those interested in this level of protection. + +While some may balk at the potential threat of quantum computers to Bitcoin given their limited functionality to date, some others - including governments, corporations and some existing and potential Bitcoin users - are concerned about their potential for advancement. The Commercial National Security Algorithm Suite (CNSA) 2.0, for instance, has mandated software and networking equipment to be upgraded to post-quantum schemes by 2030, with browsers and operating systems fully upgraded by 2033. Additionally, according to NIST IR 8547, Elliptic Curve Cryptography (ECC) is planned to be disallowed within the US federal government after 2035 (with an exception made for hybrid cryptography, or the use of ECC and post-quantum algorithms together). These kinds of mandates have triggered concern by some ECC users, including some Bitcoin users who prefer to be prepared out of an abundance of caution. + +In the most optimistic case, wherein quantum computers never pose a significant risk to ECC, we understand that the possibility of quantum advancement alone may be influencing adoption and broad confidence in the Bitcoin network. In other words, we believe users' fear of quantum computers may be worth addressing regardless of CRQC viability. Given these concerns, we think it's worth considering simple low risk changes that create options for using Bitcoin in a quantum-resistant way. + +As a conservative first step in this effort, we propose Pay-to-Tapscript-Hash (P2TSH), a tapscript-native output type that can be used in a quantum resistant manner. + +===Long Exposure vs Short Exposure Attacks=== + +For clarity, this proposal specifically mitigates against the risk of long exposure attacks on tapscript-native outputs. While other Bitcoin output types already mitigate against this risk, Tapscript outputs (P2TR output types) are vulnerable to long exposure quantum attacks. + +A long exposure attack is an attack performed on exposed blockchain data, such as exposed public keys or the spend scripts of spent outputs. These are likely to be the earliest quantum attacks made possible on Bitcoin, because attackers will have ample time - as much time as vulnerable keys are exposed - to carry out quantum key recovery. + +Short exposure attacks, however, require faster quantum computers, because they must occur within the relatively short time that a transaction is unconfirmed in the mempool. + +Bitcoin outputs are generally vulnerable to short exposure attacks, as most Bitcoin transactions require revealing the associated public key when spending. Full protection of outputs from short exposure attacks may require the use of post-quantum signature schemes. + +Since long exposure attacks on public keys are likely to be the first quantum-enabled threat to Bitcoin, we propose a tapscript-native output type that is resistant to long exposure attacks as a first step in hardening Bitcoin against the potential threat of quantum computers. + +The following list of output types describes their long exposure attack vulnerability: {| class="wikitable" -|+ Output types vulnerable to long-exposure attacks on unspent addresses |- -! Type !! Vulnerable !! Prefix !! Example +! Type +! Vulnerable +! Prefix +! Example |- -| P2PK || Yes || Varies || 2103203b768951584fe9af6d9d9e6ff26a5f76e453212f19ba163774182ab8057f3eac +| P2PK +| Yes +| Varies +| 02103203b768951584fe9af6d9d9e6ff26a5f76e453212f19ba163774182ab8057f3eac |- -| P2PKH || No¹ || 1 || 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa +| P2PKH +| No* +| 1 +| 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa |- -| P2MS || Yes || Varies || 52410496ec45f878b62c46c4be8e336dff7cc58df9b502178cc240e... +| 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 +| P2TR +| Yes +| bc1p +| bc1p92aslsnseq786wxfk3ekra90ds9ku47qttupfjsqmmj4z82xdq4q3rr58u |- -| P2QRH || No || bc1z || bc1zzmv50jjgxxhww6ve4g5zpewrkjqhr06fyujpm20tuezdlxmfphcqfc80ve +| P2TSH +| No* +| bc1z +| bc1zzmv50jjgxxhww6ve4g5zpewrkjqhr06fyujpm20tuezdlxmfphcqfc80ve |} -¹ Funds in P2PKH, P2SH, P2WPKH, and P2WSH outputs become vulnerable to long-exposure quantum attacks when their input script is revealed. An address is no longer safe against long-exposure 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. - -If a CRQC recovers an extended public key (xpub), including its chain code, it can derive all non-hardened child public -keys by guessing or iterating through child indexes, as allowed by BIP 32's non-hardened derivation. With Shor's -algorithm, the CRQC could then compute the corresponding non-hardened child private keys directly from those public keys, -without needing the extended private key (xprv) or an exposed child private key. Hardened child keys remain secure since -they cannot be derived from the xpub alone. However, if the xprv is exposed, then all child private keys--both hardened -and non-hardened--become vulnerable. Thus, in a quantum context, the xpub alone is sufficient to expose all non-hardened -child private keys. - -==== Long Exposure and Short Exposure Quantum Attacks ==== +The following output types are fundamentally vulnerable to long exposure attacks: -A Long Exposure 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: +* P2PK outputs (e.g. Satoshi's coins, CPU miners) +* Reused outputs* +* Tapscript outputs (starts with bc1p) -* P2PK outputs (Satoshi's coins, CPU miners, starts with 04) -* Reused addresses (any type, except P2QRH) -* Taproot addresses (starts with bc1p) -* Extended public keys, commonly known as "xpubs" -* Wallet descriptors +* Funds in P2PKH, P2SH, P2WPKH, P2WSH, and P2TSH outputs can become vulnerable to long exposure quantum attacks anytime their script reveals a public key. -A Short Exposure Quantum Attack is an attack that must be executed quickly while a transaction is still in the mempool, -before it is mined into a block. This affects: +Note: Extended public keys, commonly known as "xpubs," and wallet descriptors also reveal quantum vulnerable public key information. For further clarification on quantum attack vectors, please refer to the [[#Glossary|Glossary of Terms]]. -* Any transaction in the mempool (except for P2QRH) +==Design== -Short-exposure attacks require much larger, more expensive CRQCs since they must be executed within the short window -before a transaction is mined. Long-exposure attacks can be executed over a longer timeframe since the public key remains -exposed on the blockchain indefinitely. +Pay-to-Tapscript-Hash (P2TSH) is a proposed new output type that commits to the root of a tapscript tree. It operates with nearly the same functionality as P2TR (Pay-to-Taproot) outputs, but with the quantum vulnerable key path spend removed. -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 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 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 to provide -time to transition Bitcoin to implement post-quantum security. +In other words, P2TSH outputs commit to the Merkle root of a tapscript tree without committing to an internal key. The script(s) being committed to, however, may contain a key or key-hash. -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. Independently, this assumes that other vulnerable targets such as central banks have upgraded their -cryptography by this time. +This output type is designed to offer tapscript users protection against long exposure quantum attacks as well as a practical output type with which post-quantum signatures may be used if such signatures are adopted in the future. -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. +Since P2TSH outputs have no key path spend, they omit the Taproot internal key. Instead, a P2TSH output includes the 32-byte root of the taptree as defined in [[bip-0341.mediawiki|BIP 341]] hashed with the tag "TapBranch" as shown below. -Although the main threat posed by CRQCs is 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 -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]. +[[File:bip-0360/media/merkletree.png|thumb|Construction of P2TSH Taptree root, scriptPubkey, and Witness]] -=== Design === - -This BIP proposes a new output type called P2QRH (Pay to Quantum Resistant Hash). This output type is designed to -support post-quantum signature algorithms but those algorithms will be specified in future BIPs. - -P2QRH (Pay to Quantum Resistant Hash) is a new output type that commits to the root of a tapleaf Merkle tree. It is functionally -the same as a P2TR (Pay to Taproot) output with the quantum vulnerable key path spend removed. Since P2QRH has no key path spend, P2QRH omits the -Taproot internal key, as it is not needed. Instead, a P2QRH output is just the 32-byte root of the tapleaf Merkle tree as defined -in [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP 341] and hashed with the tag "QuantumRoot" as shown below. - -[[File:bip-0360/merkletree.png|center|550px|thumb|]] - -To construct a P2QRH output we follow the same process as [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP 341] -to compute the tapscript Merkle root. However, instead of the root of the Merkle tree being hashed together with the internal -key in P2QRH the root is hashed by itself using the tag "QuantumRoot". +To construct a P2TSH output, we follow the process outlined in [[bip-0341.mediawiki|BIP 341]] to compute the final tapbranch hash, which is the merkle root of the tapleaves; however, instead of tweaking the internal key with the root of the Merkle tree (as is the case with P2TR outputs), P2TSH outputs commit only to final tapbranch hash, which is tagged, "TapBranch". D = tagged_hash("TapLeaf", bytes([leaf_version]) + ser_script(script)) CD = tagged_hash("TapBranch", C + D) -CDE = tagged_hash("TapBranch", E + CD) +CDE = tagged_hash("TapBranch", CD + E) ABCDE = tagged_hash("TapBranch", AB + CDE) -Root = tagged_hash("QuantumRoot", ABCDE) -A P2QRH input witness provides the following: +A P2TSH input witness provides the following: initial stack element 0, ..., initial stack element N, tapleaf script, -control block = [control byte, 32 * m byte Merkle path] # m is the depth of the Merkle tree +control block = [control byte, 32*m byte Merkle path] # m is the depth of the script in the Merkle tree -The initial stack elements provide the same functionality as they do in P2TR. That is, they place elements on the stack to -be evaluated by the script, a.k.a. the redeem script. - -The control block is a 1 + 32 * m byte array, where the first byte is the control byte and the next 32*m bytes are the -Merkle path to the script. The control byte is the same as the control byte in a P2TR control block, -including the 7 bits which are used to specify the tapleaf version. The parity bit of the control byte is always 1 -since P2QRH does not have a key path spend. We omit the public key from the control block as it is not needed in P2QRH. -We maintain support for the optional annex in the witness (see specification for more details). - -=== Rationale === - -Our design to augment Bitcoin with quantum resistance is guided by the following principles: - -'''Minimize changes.''' We should reuse existing Bitcoin code and preserve -existing software behavior, workflows, user expectations and compatibility whenever possible. - -'''Gradual upgrade path.''' We should provide an upgrade path for wallets and exchanges which can be -carried out gradually and iteratively rather than all at once. This is critical as the earlier the ecosystem -begins upgrading to quantum resistance, the lower the number of coins at risk when quantum attacks become practical. - -'''Use standardized post-quantum signature algorithms.''' Standardized algorithms have undergone the most scrutiny and -are likely to be most well supported and well studied going forward. The entire Bitcoin ecosystem will benefit -from using the most popular post-quantum signature algorithms, including leveraging hardware acceleration -instructions, commodity trusted hardware, software libraries and cryptography research. - -'''Provide security against unexpected cryptanalytic breakthroughs.''' Consider the risk -if Bitcoin only supported one PQ signature algorithm, and then following the widespread rollout of CRQCs, a critical -weakness is unexpectedly discovered in this signature algorithm. There would be no safe algorithm available. We believe that -prudence dictates we take such risks seriously and ensure that Bitcoin always has at least two secure signature algorithms built -on orthogonal cryptographic assumptions. In the event one algorithm is broken, an alternative will be available. An added benefit -is that parties seeking to securely store Bitcoin over decades can lock their coins under multiple algorithms, -ensuring their coins will not be stolen even in the face of a catastrophic break in one of those signature algorithms. - -Based on these principles, we propose two independent changes that together provide Bitcoin with -full quantum resistance. In this BIP, we introduce a new output type called P2QRH (Pay to Quantum Resistant Hash) so that tapscript -can be used in a quantum resistant manner. In a future BIP, we enable tapscript programs to verify two Post-Quantum (PQ) signature -algorithms, ML-DSA (CRYSTALS-Dilithium) and SLH-DSA (SPHINCS+). It is important to consider these two changes together because P2QRH must -be designed to support the addition of these PQ signature algorithms. The full description of these signatures will be provided in a future BIP. - -==== P2QRH ==== - -P2QRH is simply P2TR with the quantum vulnerable key path spend removed so that it commits to the root of -the tapleaf Merkle tree in the output. This allows P2QRH to reuse the mature and battle tested P2TR, tapleaf -and tapscript code already in Bitcoin. This reduces the implementation burden on wallets, exchanges, and -libraries since they can reuse code they already have. - -Both P2WSH (Pay 2 Witness Script Hash) and P2QRH protect against long-exposure quantum attacks and both provide -the same 256-bit security level. One may ask why not use the existing output type P2WSH instead of add a new one? -The problem with P2WSH is that it only works with pre-tapscript Script and cannot work with tapscript Script. -New protocols and programs in the Bitcoin ecosystem have largely moved to tapscript. Using P2WSH would require turning -back the clock and forcing projects to move from tapscript to pre-tapscript. More importantly, tapscript provides a far -easier and safer upgrade path for adding PQ signatures. Changes to pre-tapscript to enable it to support PQ signatures would likely -require adding tapscript features to pre-tapscript. Even if this was possible, it would represent far more work and -risk than adding a new output type like P2QRH. Tapscript, and thereby a tapscript compatible output such as P2QRH, -is the most plausible and convenient upgrade path to full quantum resistance. - -==== PQ signatures ==== - -By separating P2QRH from the introduction of PQ signatures, relying parties can move from P2TR to P2QRH -without simultaneously having to change from Schnorr signatures to PQ signatures. Simply moving coins from -P2TR to P2QRH protects those coins from long-exposure quantum attacks. Then to gain full quantum resistance, -verification of PQ signatures can be added as an additional leaf alongside Schnorr signaturesMatt Corallo, [https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/rTrpeFjWDAAJ Trivial QC signatures with clean upgrade path], (2024). -When quantum attacks become practical, users would then be fully protected as the P2QRH output would allow -them to switch to sending their coins using the PQ signature algorithms. This allows the upgrade to quantum -resistance to be largely invisible to users. - -Consider the P2QRH output with three tapscripts: - -* Spend requires a Schnorr signature -* Spend requires a ML-DSA signature -* Spend requires a SLH-DSA signature - -In the event that Schnorr signatures are broken, users can spend their coins using ML-DSA. -If both Schnorr and ML-DSA are broken, the user can still rely on SLH-DSA. -While this pattern allows users to spend their coins securely without revealing the public -keys associated with vulnerable algorithms, the user can compromise their own security if -they leak these public keys in other contexts, e.g. key reuse. - -One intent in supporting Schnorr, ML-DSA, and SLH-DSA in tapscript, is to allow parties to construct outputs such that funds -are still secure even if two of the three signature algorithms are completely broken. This is motivated by the use case -of securely storing Bitcoin in a cold wallet for very long periods of time (50 to 100 years). - -For PQ signatures we considered the NIST approved SLH-DSA (SPHINCS+), ML-DSA (CRYSTALS-Dilithium), -FN-DSA (FALCON). Of these three algorithms, SLH-DSA has the largest signature size, but is the most conservative -choice from a security perspective because SLH-DSA is based on well studied and time-tested hash-based cryptography. -Both FN-DSA and ML-DSA signatures are significantly smaller than SLH-DSA signatures but are based on newer lattice-based -cryptography. Since ML-DSA and FN-DSA are both similar lattice-based designs, we choose to only support one of them as the -additional value in diversity of cryptographic assumptions would be marginal. It should be noted that ML-DSA and FN-DSA do -rely on different lattice assumptions and it may be that case that a break in one algorithm's assumptions would not necessarily -break the assumptions used by the other algorithm. - -We also considered SQIsign. While it outperforms the three other PQ signature algorithms by having the smallest signatures, -it has the worst verification performance and requires a much more complex implementation. We may revisit SQIsign separately in the -future as recent research shows massive performance improvements to SQIsign in version 2.0. "[SQIsign] signing is now nearly 20× faster, at 103.0 Mcycles, and verification is more than 6× faster, at 5.1 Mcycles" [https://csrc.nist.gov/csrc/media/Projects/pqc-dig-sig/documents/round-2/spec-files/sqisign-spec-round2-web.pdf SQIsign: Algorithm specifications and supporting documentation Version 2.0 (February 5 2025)]. - -ML-DSA is intended as the main PQ signature algorithm in Bitcoin. It provides a good balance of security, performance -and signature size and is likely to be the most widely supported PQ signature algorithm on the internet. SLH-DSA has a radically -different design and set of cryptographic assumptions than ML-DSA. As such SLH-DSA provides an effective -hedge against an unexpected cryptanalytic breakthrough. - -P2QRH, ML-DSA, and SLH-DSA could be activated simultaneously in a single soft fork or P2QRH could be activated first and then -ML-DSA and SLH-DSA could be independently activated. If at some future point another signature -algorithm was desired it could follow this pattern. - -We consider two different paths for activating PQ signatures in Bitcoin. The first approach is to redefine OP_SUCCESSx opcodes for each -signature algorithm. For ML-DSA this would give us OP_CHECKMLSIG, OP_CHECKMLSIGVERIFY and OP_CHECKMLSIGADD. The second approach is to use a new tapleaf version that changes the OP_CHECKSIG opcodes to support the -new PQ signature algorithms. In both cases, we would need to include as part of the soft fork an increase in the tapscript stack element -size to accommodate the larger signatures and public keys sizes of the PQ signature algorithms. - -The OP_SUCCESSx approach has the advantage of providing a straightforward path to add new signature algorithms in the future. Simply redefine -a set of five OP_SUCCESSx opcodes for the new signature algorithm. This would allow us to activate a single PQ signature at a time, adding -new ones as needed. Additionally this approach allows developers to be very explicit in the signature algorithm type that they wish to verify. -The main disadvantage is that it uses five OP_SUCCESSx opcodes per signature algorithm. Supporting ML-DSA and SLH-DSA would require ten new opcodes. - -Adding PQ signatures via a tapleaf version increase does not introduce any new opcodes and allows previously written tapscript programs to be used with PQ signatures -by simply using the new tapleaf version. Instead of developers explicitly specifying the intended signature algorithm through an opcode, the algorithm -to use must be indicated within the public key or public key hash'''Why not have CHECKSIG infer the algorithm based on signature size?''' Each of the three signature algorithms, Schnorr, ML-DSA, and SLH-DSA, have unique signature sizes. The problem with using signature size to infer algorithm is that spender specifies the signature. This would allow a public key which was intended to be verified by Schnorr to be verified using ML-DSA as the spender specified a ML-DSA signature. Signature algorithms are often not secure if you can mix and match public key and signature across algorithms.. -The disadvantage of this approach is that it requires a new tapleaf version each time we want to add a new signature algorithm. - -Both approaches must raise the stack element size limit. In the OP_SUCCESSx case, the increased size limit would only be effect for transaction outputs -that use of the new opcodes. Otherwise this stack element size limit increase would be a soft fork. If the tapleaf version is used, then the stack -element size limit increase would apply to any tapscript program with the new tapleaf version. - -To improve the viability of the activation client and adoption by wallets and libraries, a library akin to -libsecp256k1 will be developed. This library, [https://github.com/cryptoquick/libbitcoinpqc libbitcoinpqc], will support the new PQ signature algorithms -and can be used as a reference for other language-native implementations. - -==== PQ signature size ==== - -Post-quantum public keys are generally larger than those used by ECC, depending on the security level. Originally, BIP 360 -proposed NIST Level V, 256-bit security, but this was changed to NIST Level I, 128-bit security due to concerns over the -size of the public keys, the time it would take to verify signatures, and being generally deemed "overkill". - -We recognize that the size of ML-DSA (CRYSTALS-Dilithium) and SLH-DSA (SPHINCS+) signatures + public key pairs is a significant concern. -By way of comparison with Schnorr public key + signature pairs, SLH-DSA is roughly 80x larger and ML-DSA is roughly 40x larger. This means to -maintain present transaction throughput, an increase in the witness discount may be desired. - -An increase in the witness discount must not be taken lightly. Parties may take advantage of this discount for purposes other than -authorizing transactions (e.g., storage of arbitrary data as seen with "inscriptions"). - -There was some hope of designing P2QRH such that discounted public keys and signatures could not be repurposed for the storage of -arbitrary data by requiring that they successfully be verified before being written to Bitcoin's blockchain, a.k.a. "JPEG resistance". -Later research Bas Westerbaan (2025), [https://groups.google.com/g/bitcoindev/c/5Ff0jdQPofo jpeg resistance of various post-quantum signature schemes] -provided strong evidence that this was not a feasible approach for the NIST approved Post-Quantum signature algorithms. -It is an open question if Post-Quantum signature algorithms can be designed to provide JPEG resistance. - -==== Raising tapscript's stack element size ==== - -A problem faced by any attempt to add PQ signatures to tapscript is that the stack elements in tapscript cannot be larger than 520 bytes -because the MAX_SCRIPT_ELEMENT_SIZE=520. This is problematic because PQ signature algorithms often have signatures and -public keys in excess of 520 bytes. For instance: - -* ML-DSA public keys are 1,312 bytes and signatures are 2,420 bytes -* SLH-DSA public keys are 32 bytes and signatures are 7,856 bytes +The initial stack elements of P2TSH provide the same functionality as they do in P2TR. That is, they place elements on the stack to be evaluated by the script. -We will first look at our approach to the problem of PQ signatures and then give our solution for public keys larger than 520 bytes. +The control block is a ''1 + 32 * m'' byte array, where the first byte is the control byte and the next ''32 * m'' bytes are the Merkle path to the tapleaf script. The control byte is the same as the control byte in a P2TR control block, including the 7 bits which are used to specify the tapleaf version. The parity bit of the control byte is always 1, since P2TSH does not have a key path spend. Unlike P2TR, we omit the public key from the control block as it is not needed in P2TSH. We maintain support for the optional annex in the witness (see Specification section below for more details). -To keep P2QRH small and simple, we have opted not to raise the stack element size limit as part of P2QRH, but instead make this change when -adding PQ signatures. That said, we are not strongly opposed to putting this increase in P2QRH. - -We propose a stack element size limit of 8,000 bytes. We arrive at 8,000 by rounding up from the needed 7,856 bytes. +==Rationale== -OP_DUP will duplicate any stack element. Thus, if we allowed OP_DUP to duplicate stack elements of size 8,000 bytes, it would be possible -to write a tapscript which will duplicate stack elements until it reaches the maximum number of elements on stack, i.e. 1000 elements. -An increase from 520 bytes to 8,000 bytes would increase the memory footprint from 520 KB to 8 MB. +Design of the P2TSH output type is guided by the following intentions: -To prevent OP_DUP from creating an 8 MB stack by duplicating stack elements larger than 520 bytes we define OP_DUP to fail on stack -elements larger than 520 bytes. Note this change to OP_DUP is not consensus critical and does not require any sort of fork. This is -because currently there is no way to get a stack element larger than 520 bytes onto the stack so triggering this rule is currently -impossible and would only matter if the stack element size limit was raised. +1. Minimize changes to the network. We should reuse existing Bitcoin code and preserve existing software behavior, workflows, user expectations and compatibility whenever possible. -==== Public keys larger than 520 bytes ==== +P2TSH leverages the battle tested P2TR, tapleaf and tapscript code already in Bitcoin, reducing the implementation burden on wallets, exchanges, and libraries that can reuse code they already have. This approach reduces complexity and minimizes implementation risks. -Turning our attention to public keys larger than 520 bytes. This is not needed for SLH-DSA as its public key is only 32 bytes. -This is a different problem than signatures as public keys are typically pushed onto -the stack by the script (redeem script) to commit to public keys in the output. The OP_PUSHDATA opcode in tapscript fails if asked to push -more than 520 bytes onto the stack. +2. Create the safest possible path for the addition of post-quantum signature integrations, in the event that they are used in the future. -To solve this issue, for signature schemes with public keys greater than 520 bytes, we use the hash of the public key in the script. -We then package the public key and signature together as the same stack element on the input stack. Since the hash of the public key is -only 32 bytes, the script can push it on the stack as it does today. Consider the following example with a -OP_CHECKMLSIG opcode for ML-DSA: +Importantly, we are proposing a tapscript-native output type that is resistant to long exposure attacks. While some existing output types are already resistant to long exposure attacks (e.g. P2WSH), no such output type supports tapscript - a feature that may be required for practical implementation of post-quantum signature opcodes. - -stack = [pubkey||signature] -tapscript = [OP_PUSHDATA HASH256(expected_pubkey), OP_CHECKMLSIG] - +P2WSH, for instance, is not tapscript-native and as such does not support the OP_SUCCESSx opcode update path that will be critical for the integration of post-quantum OP_CHECKSIG opcodes into Bitcoin.OP_SUCCESSx is a mechanism to upgrade tapscript -1. OP_PUSHDATA HASH256(expected_pubkey) updates the stack to [HASH256(expected_pubkey), pubkey||signature] -2. OP_CHECKMLSIG pops HASH256(expected_pubkey) and pubkey||signature, checks HASH256(expected_pubkey) == pubkey and verifies signature against pubkey. +3. Facilitate gradual integration of quantum resistant features that can be carried out iteratively as quantum computers evolve. This approach encourages responsiveness to the current threat-level, while avoiding heavy-handedness in our reactions to a potential threat. -==== Future considerations ==== +We designed P2TSH with an eye towards integrating post-quantum signatures in the future, without proposing more complex changes while CRQCs are still in their infancy. -Additional follow-on BIPs will be needed to implement PQ signature algorithms, signature aggregation, and full BIP 32 compatibility -(if possible) BIP 32 relies on elliptic curve operations to derive keys from xpubs to support -watch-only wallets, which PQC schemes may not support.. However, until specialized quantum cryptography hardware -is widespread and signature aggregation schemes are thoroughly vetted, P2QRH addresses are an intermediate solution -to quantum threats. +===P2TSH Trade-Offs=== -== Specification == +While P2TR outputs (and the use of key path spend) will remain an option for folks wishing to use them, we aim to be clear about the tradeoffs of using P2TSH outputs, which disable the key path spend for the benefit of quantum resistance. -We define the Pay to Quantum Resistant Hash (P2QRH) output structure as follows. +The witness to a P2TSH spend is always larger than the witness to a P2TR key path spend. This is because a P2TR key path spend requires only a Schnorr signature in the witness. For P2TSH, the witness must include your chosen leaf script, its inputs, and a control block consisting of the control byte and Merkle path (if any). -=== Pay to Quantum Resistant Hash (P2QRH) === +That said, the witness to a P2TSH spend will always be smaller than the witness to an equivalent P2TR script path spend, because there is no longer any internal key in P2TSH that must be revealed in the control block. For a more complete comparison of output type transaction sizes, the "Transaction Size and Fees" section may be reviewed later in this proposal. -A P2QRH output is simply the root of the tapleaf Merkle tree defined in [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP 341] -and used as an internal value in P2TR. +Additionally, there is a privacy tradeoff when comparing P2TSH and P2TR, which is that users reveal they are spending to a script tree whenever they are using P2TSH outputs, since P2TSH outputs can only be spent via script path spend. In P2TR when you spend an output as a key path spend, you don't reveal if you have any script path spends. This trade-off only exists when comparing P2TR key path spends to P2TSH script path spends; P2TR and P2TSH provide the same level of privacy when both are script path spends. -To construct a P2QRH output we follow the same process as [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP 341] -to compute the tapscript Merkle root. However, instead of the root of the Merkle tree being hashed together with the internal -key in P2QRH the root is hashed by itself using the tag "QuantumRoot" and then set as the witness program. +'''Note:''' P2TSH and P2TR both provide greater script privacy than P2SH [[bip-0016.mediawiki|BIP 16]] because unused script paths are not revealed. -=== Address Format === +==Specification== -P2QRH uses SegWit version 2 outputs, resulting in addresses that start with bc1z, following -[https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32 BIP 173]. Bech32 encoding maps version 2 to the -prefix z. +We define the Pay-to-Tapscript-Hash (P2TSH) output structure as follows: -Example P2QRH address: +A P2TSH output is similar to a P2TR output that uses the root of a taptree (as defined in [[bip-0341.mediawiki|BIP 341]]); however, unlike P2TR outputs, we disable the key path spend for the benefit of quantum resistance by omitting the internal key and the tap tweak step. The root of the Merkle tree is then set as the witness program, prepended with a SegWit version 2 byte, and committed to in the output scriptPubKey. -bc1zzmv50jjgxxhww6ve4g5zpewrkjqhr06fyujpm20tuezdlxmfphcqfc80ve (32-byte Bech32m-encoded tapleaf Merkle root) +===Address Format=== -=== ScriptPubKey === +P2TSH outputs use SegWit version 2, resulting in mainnet addresses that start with bc1z, following [[bip-0173.mediawiki|BIP 173]]. Bech32m encoding maps version 2 to the prefix z. -The scriptPubKey for a P2QRH output is: +Example P2TSH address: - OP_2 OP_PUSHBYTES_32 + +bc1zzmv50jjgxxhww6ve4g5zpewrkjqhr06fyujpm20tuezdlxmfphcqfc80ve + -Where: +This commits to a 32-byte tapscript tree hash. -* OP_2 (0x52) indicates SegWit version 2. -* is the 32-byte tapleaf Merkle root. +===ScriptPubKey=== -==== Script Validation ==== +The scriptPubKey for a P2TSH output is: -A P2QRH output is a native SegWit output (see [[bip-0141.mediawiki|BIP141]]) with version number 2, and a 32-byte witness program. -Unlike Taproot this witness program is the tapleaf Merkle root. For the sake of comparison we have, as much as possible, copied the -language verbatim from the [[bip-0341.mediawiki|BIP341]] script validation section. + +OP_2 OP_PUSHBYTES_32 + + +Where: +* OP_2 indicates SegWit version 2. +* is the 32-byte Merkle root of the taptree. + +===Script Validation=== + +A P2TSH output is a native SegWit output (see [[bip-0141.mediawiki|BIP 141]]) with version 2 and a 32-byte witness program. The witness program is the root of the tapscript tree. For the sake of comparison, we have - as much as possible - copied the language verbatim from the script validation section of [[bip-0341.mediawiki|BIP 341]]. -* Let ''q'' be the 32-byte array containing the witness program (the second push in the scriptPubKey) which represents root of tapleaf Merkle tree. +* Let ''q'' be the 32-byte array containing the witness program (the second push in the scriptPubKey) which represents the root of the tapleaf Merkle tree (also known as a taptree). * Fail if the witness stack does not have two or more elements. -* If there are at least three witness elements, and the first byte of the last element is 0x50, this last element is called ''annex'' ''a'' and is removed from the witness stack. The annex (or the lack thereof) is always covered by the signature and contributes to transaction weight, but is otherwise ignored during Taproot validation. +* If there are at least three witness elements, and the first byte of the last element is 0x50, this last element is called ''annex a'' and is removed from the witness stack. The annex (or the lack thereof) is always covered by the signature and contributes to transaction weight, but is otherwise ignored during P2TSH validation. * There must be at least two witness elements left. ** Call the second-to-last stack element ''s'', the script (as defined in [[bip-0341.mediawiki|BIP 341]]) ** The last stack element is called the control block ''c'', and must have length ''1 + 32 * m'', for a value of ''m'' that is an integer between 0 and 128, inclusive. Fail if it does not have such a length. -** Let ''v = c[0] & 0xfe'' be the ''leaf version'' (as defined in [[bip-0341.mediawiki|BIP 341]]). To maintain ''leaf version'' encoding compatibility the last bit of c[0] is unused and must be 1 '''Why set the last bit of c[0] to one?''' Consider a faulty implementation that deserializes the ''leaf version'' as c[0] rather than c[0] & 0xfe for both P2TR and P2QRH. If they test against P2QRH outputs and require that last bit is 1, this deserialization bug will cause an immediate error.. +** Let ''v = c[0] & 0xfe'' be the ''leaf version'' (as defined in [[bip-0341.mediawiki|BIP 341]]). To maintain ''leaf version'' encoding compatibility the last bit of c[0] is unused and must be 1.Why set the last bit of c[0] to one? Consider a faulty implementation that deserializes the ''leaf version'' as c[0] rather than c[0] & 0xfe for both P2TR and P2TSH. If they test against P2TSH outputs and require that last bit is 1, this deserialization bug will cause an immediate error. ** Let ''k0 = hashTapLeaf(v || compact_size(size of s) || s)''; also call it the ''tapleaf hash''. ** For ''j'' in ''[0,1,...,m-1]'': *** Let ''ej = c[33+32j:65+32j]''. -*** Let ''kj+1 depend on whether ''kj < ej'' (lexicographically): +*** Let ''kj+1'' depend on whether ''kj < ej'' (lexicographically): **** If ''kj < ej'': ''kj+1 = hashTapBranch(kj || ej)''. **** If ''kj ≥ ej'': ''kj+1 = hashTapBranch(ej || kj)''. -** Let ''r = hashQuantumRoot(km)''. +** Let ''r = km''. ** If ''q ≠ r'', fail. ** Execute the script, according to the applicable script rules, using the witness stack elements excluding the script ''s'', the control block ''c'', and the annex ''a'' if present, as initial stack. This implies that for the future leaf versions (non-''0xC0'') the execution must succeed. The steps above follow the script path spend logic from [[bip-0341.mediawiki|BIP 341]] with the following changes: -* The witness program is the tapleaf Merkle root and not a public key. This means that we skip directly to the BIP 341 spend path tapleaf Merkle tree validation. -* We compute the tagged tapleaf Merkle root r and compare it directly to the witness program q. -* The control block is 1 + 32*m bytes, instead of 33 + 32*m bytes. -==== Sighash Calculation ==== +* The witness program is the taptree Merkle root and not a tweaked public key. This means that we skip directly to the BIP 341 spend path taptree Merkle tree validation. +* We compute the taptree Merkle root ''r'' and compare it directly to the witness program ''q''. +* The control block is ''1 + 32*m'' bytes, instead of ''33 + 32*m'' bytes. -The sighash for P2QRH outputs follows the same procedure as defined in [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP 341] for Taproot transactions: +===Common Signature Message Construction=== -* '''Signature Message:''' A single-SHA256 of a tagged hash with the tag "TapSighash", containing transaction data. -* '''Tagged Hash:''' Computed as H(tag || tag || data) where H is SHA256 and tag is the SHA256 of the tag name. -* '''Key Data:''' In addition to transaction data, the sighash includes the spent output's scriptPubKey. -* '''Extension Fields:''' Specific data is included or excluded from the sighash based on the sighash flag. - -This signature hash construction ensures transaction malleability is prevented while providing flexibility through -different sighash types (DEFAULT, ALL, NONE, SINGLE, and ANYONECANPAY variants). The exact computation follows the -procedure specified in BIP 341 to maintain compatibility with Taproot signatures. - -If a sighash flag other than DEFAULT is needed, it can be placed in the transaction witness. In this case, it will be -the only field in the witness. +The [https://learnmeabitcoin.com/technical/upgrades/taproot/#common-signature-message common signature message] construction for P2TSH outputs is exactly the same procedure as defined in [[bip-0341.mediawiki|BIP 341]] for Taproot transactions. === 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 2 will treat these outputs as anyone-can-spend but, per -[https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP 141], will not relay or mine such transactions. +By adhering to the SegWit transaction structure and versioning, P2TSH outputs are compatible with existing transaction processing rules. Nodes that do not recognize SegWit version 2 will treat these outputs as anyone-can-spend but, per [[bip-0141.mediawiki|BIP 141]], will not relay or mine such transactions. +===Transaction Size and Fees=== -=== Transaction Size and Fees === +Equivalent P2TSH and P2TR outputs are always the same size. P2TSH inputs can be slightly larger or smaller than their equivalent P2TR inputs, depending on the use of key path vs script path spend in the case of P2TR. Let's consider the cases. -Equivalent P2QRH and P2TR outputs are always the same size. P2QRH inputs can be slightly larger or smaller than -their equivalent P2TR inputs. Let's consider the cases: +====Comparison with P2TR key path spend==== -'''P2TR key path spend''' P2QRH inputs will be larger than P2TR inputs when the P2TR output would have been spent via the key path spend. -P2QRH quantum resistance comes from removing the P2TR key path spend. Consequently, it cannot make use of Taproot's optimization -where P2TR key path spends do not require including a Merkle path in the P2TR input. If the Merkle tree only has a single leaf script, -no Merkle path is needed in the control block, giving us a 1-byte control block. +A P2TSH witness will be larger than a P2TR witness when the P2TR output is spent via the key path spend. A witness to a P2TR key path spend is simply a signature. P2TSH quantum resistance comes from removing the P2TR key path spend. Every P2TSH spend is a P2TR script path spend and so requires a script, its input stack and a control block. Consequently, P2TSH loses this size advantage of P2TR key path spends in order to gain quantum resistance. If the taptree only has a single leaf script, no Merkle path is needed in the control block, giving us a minimal size control block of 1 byte. + +P2TSH witness for depth-0 tree (103 bytes): -P2QRH witness (103 bytes): [count] (1 byte), # Number of elements in the witness -[size] signature (1 + 64 bytes = 65 bytes), +[size] signature (1 + 64 bytes = 65 bytes), tapleaf script = [size] [OP_PUSHBYTES_32, 32-byte public key, OP_CHECKSIG] (1 + 1 + 32 + 1 bytes = 35 bytes), -control block = [size] [control byte] (1 + 1 = 2 bytes) +control block = [size] [control byte] [merkle path (empty)] (1 + 1 + 0 bytes = 2 bytes) P2TR key path spend witness (66 bytes): + [count] (1 byte), # Number of elements in the witness [size] signature (1 + 64 bytes = 65 bytes) -Thus, the P2QRH input would be 103 - 66 = 37 bytes larger than a P2TR key path spend input. +Thus, the P2TSH witness would be 103 - 66 = 37 bytes larger than a P2TR key path spend witness. + +If the Merkle tree has more than a single leaf, then the Merkle path must be included in the control block, increasing the size by ''32 * m'' bytes, where m is the depth of the Merkle tree. This would make such witness 37 + 32 * m bytes larger than a P2TR key path spend witness.If ''m >= 8'', then the compact size will use 3 bytes rather than 1 byte + +P2TSH witness ''(103 + 32*m bytes)'': -If the Merkle tree has more than a single leaf, then the Merkle path must be included in -the control block. -P2QRH witness (103+32*m bytes) [count] (1 byte), # Number of elements in the witness -[size] signature (64 + 1 bytes = 65 bytes), +[size] signature (64 + 1 bytes = 65 bytes), tapleaf script = [size] [OP_PUSHBYTES_32, 32-byte public key, OP_CHECKSIG] (34 + 1 bytes = 35 bytes), -control block = [size] [control byte, 32 * m byte Merkle path] (1 + 1 + 32 * m = 2 + 32 * m bytes) +control block = [size] [control byte] [Merkle path] (1 + 1 + 32*m = 2 + 32*m bytes) -For a Merkle path of length m, it would add an additional ~32 * m bytes to the P2QRH input. This would -make it 37 + 32 * m bytes larger than a P2TR key path spend inputIf m >= 8, then the compact size will use 3 bytes rather than 1 byte. +====Comparison with P2TR script path spend==== -Considering a P2QRH output that has a PQ signature leaf and a Schnorr leaf. The P2QRH witness to spend the Schnorr path -would be 103 + 32 * 1 = 135 bytes. It is unfortunate that we can not use the key path spend optimization for P2QRH inputs, but the key path spend optimization is -exactly what makes P2TR vulnerable to quantum attacks. If key path spend was quantum resistant we wouldn't need P2QRH at all. +A P2TSH witness will be smaller than the witness to an equivalent P2TR script path spend. This is because P2TSH does not require inclusion of any internal public key in the control block to unlock and spend an output. For this reason, a P2TSH witness will always be 32 bytes smaller than an equivalent P2TR script path spend witness. -'''P2TR script path spend''' P2QRH inputs will be smaller than equivalent script path spend P2TR inputs. This is because P2QRH inputs -do not require that the input includes a public key in the control block to open the commitment to the Merkle root. -An equivalent P2QRH input will be 32 bytes smaller than a P2TR script path spend input. +==Performance Impact== -=== Performance Impact === +P2TSH is slightly more computationally performant than P2TR script path spends, as the operations to spend a P2TSH output is a strict subset of the operations needed to perform a script path spend on a P2TR output. -P2QRH is slightly more computationally performant than P2TR, as the operations to spending a P2QRH output is a strict -subset of the operations needed to spend a P2TR output. +==Backward Compatibility== -=== Backward Compatibility === +Older wallets and nodes that have not been made compatible with SegWit version 2 and P2TSH will not recognize these outputs. Users should ensure they are using updated wallets and nodes to use P2TSH outputs and validate transactions using P2TSH outputs. P2TSH is fully compatible with tapscript and existing tapscript programs can be used in P2TSH outputs without modification. -Older wallets and nodes that have not been made compatible with SegWit version 2 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== -P2QRH is fully compatible with tapscript and existing tapscript programs can be used in P2QRH outputs without modification. +P2TSH outputs provide the same tapscript functionality as P2TR outputs, but with the quantum-vulnerable key path spend removed. The similarity between these output types enables users to easily migrate coins from P2TR outputs to P2TSH outputs for protection against long exposure quantum attacks. -== Security == +Protection from long exposure quantum attacks does not depend on the activation of post-quantum signatures in Bitcoin, but requires that users do not expose their public keys to attackers via public key reuse or other unsafe practices. -P2QRH outputs provide the same tapscript functionality as P2TR outputs, but without the quantum-vulnerable key path spend. -This enables users, exchanges and other hodlers to easily move their coins from Taproot outputs to P2QRH outputs -and thereby protect their coins from long-exposure quantum attacks. The protection from long-exposure quantum attacks -does not depend on the activation of post-quantum signatures in Bitcoin but does require that users do not expose their -quantum vulnerable public keys to attackers via address reuse or other unsafe practices. +P2TSH uses a 256-bit hash output, providing 128 bits of collision resistance and 256 bits of preimage resistance. This is the same level of security as P2WSH specified in [[bip-0141.mediawiki|BIP 141]], which also uses a 256-bit hash output. -P2QRH uses a 256-bit hash output, providing 128 bits of collision resistance and 256 bits of preimage resistance. -This is the same level of security as P2WSH, which also uses a 256-bit hash output. +P2TSH does not, by itself, protect against short exposure quantum attacks, but these attacks can be mitigated by future activation of post-quantum signatures. -P2QRH does not, by itself, protect against short-exposure quantum attacks, but such attacks can be mitigated by the future -activation of post-quantum signatures in Bitcoin. With P2QRH, these would provide full quantum resistance to P2QRH outputs in Bitcoin. -That said, the protection offered by resistance to long-exposure quantum attacks should not be underestimated. It is likely -that the first CRQCs (Cryptographically Relevant Quantum Computers) will not be able to perform short-exposure quantum -attacks. +Combined with P2TSH, post-quantum signature schemes can provide comprehensive quantum resistance to P2TSH outputs, including protection from short exposure attacks. +That said, protection against long exposure quantum attacks alone should not be underestimated. It's unlikely that early CRQCs will be fast enough to perform short exposure attacks, making preparedness against long exposure attacks more time-critical. -{| 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. It's worth noting that Winternitz signatures can -only safely be used one time per public key. If addresses are reused, private key information might be leaked, allowing -attackers to spend future outputs assigned to the same address. || 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 -|} +==Security Considerations for Post-Quantum Signature Schemes== + +While this proposal does not include the introduction of post-quantum signature schemes, we think it's worth commenting on security considerations related to this possibility. + +Quantum-resistant signature algorithms (e.g. ML-DSA or SLH-DSA) offer different levels of protection and should be scrutinized before use. We are currently researching options for the potential proposal of post-quantum signatures into Bitcoin and encourage others to engage in this research as well. + +We also imagine the possibility of introducing multiple post-quantum signatures for redundancy. Balancing the risks of additional complexity with the benefits of signature-type redundancy will be the challenge here. -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, however its performance is roughly 100,000 times slower than ECC, -which is prohibitive in the context of Bitcoin. Meanwhile, SPHINCS+ and CRYSTALS-Dilithium signatures are already approved -and have achieved broader community consensus. FALCON signatures are also NIST approved. +==Test Vectors and Reference Code== -In comparison, the size of currently used signature algorithms are: +Test vector data for creation of P2TSH UTXOs can be found [https://github.com/bitcoin/bips/blob/master/bip-0360/ref-impl/common/tests/data/p2tsh_construction.json here]. -* ECDSA: 70-72 bytes -* Schnorr: 64 bytes +These test vectors build off of the test vectors for [[bip-0341.mediawiki|BIP 341]] (Taproot). One important distinction is that the P2TSH test vectors do not include keypath spend scenarios. -In comparison to inception date, secp256k1 [https://www.secg.org/SEC1-Ver-1.0.pdf was originally specified in 2000]. +Also included are test vectors in [https://github.com/bitcoin/bips/tree/master/bip-0360/ref-impl/rust rust implementation] and [https://github.com/bitcoin/bips/tree/master/bip-0360/ref-impl/python python implementation]. One of these tests demonstrates a tapleaf tapscript that requires a secp256k1 signature to spend the P2TSH UTXO (modeled after one of the extremely valuable examples provided by [https://learnmeabitcoin.com/technical/upgrades/taproot/#example-3-script-path-spend-signature this Taproot script path spend example]. Similar to BIP 341 test vectors, all signatures are created with an all-zero (0x0000...0000) [[bip-0340.mediawiki|BIP 340]] auxiliary randomness array. -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. +==Related Work== -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. +Below we attempt to summarize some of the ideas discussed on the Bitcoin Development Mailing List that relate to P2TSH. -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. +The idea of Taproot with key path spend removed has been discussed a number of times in the Bitcoin community. -== Test Vectors and Reference Code == +For instance, [https://gnusha.org/pi/bitcoindev/CAD5xwhgzR8e5r1e4H-5EH2mSsE1V39dd06+TgYniFnXFSBqLxw@mail.gmail.com/ OP_CAT Makes Bitcoin Quantum Secure] notes that if we disable the key path spend in Taproot and activate OP_CAT [[bip-0347.mediawiki|BIP 347]], we could achieve quantum resistance by using Lamport signatures with OP_CAT. -TBD +Lamport and WOTS (Winternitz One-Time Signatures) built from CAT are quantum resistant, but are one-time signatures - meaning, if you sign twice for the same public key, you risk leaking your private key, which is a significant security concern for everyday users. -== Related Work == +This would require major changes to wallet behavior and would represent a significant security downgrade. Common practices, such as RBF and CPFP, could risk revealing private keys if no stateless signature scheme is used. -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. +[https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/rTrpeFjWDAAJ Trivial QC signatures with clean upgrade path] and [https://groups.google.com/g/bitcoindev/c/oQKezDOc4us/m/T1vSMkZNAAAJ Re: P2QRH / BIP 360 Update] also discuss the possibility of Taproot with key path spend removed. The design of P2TSH was partly inspired by these discussions. -P2QRH and MAST (Merkelized Abstract Syntax Tree) [https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki BIP 114], -and related BIPs [https://github.com/bitcoin/bips/blob/master/bip-0116.mediawiki BIP 116], [https://github.com/bitcoin/bips/blob/master/bip-0117.mediawiki BIP 117], -share the idea of committing to a Merkle tree of scripts. While MAST was never activated, Taproot -[https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP 341] incorporated this idea of a Merkle tree of -scripts into its design. P2QRH inherits this capability from Taproot because P2QRH is simply Taproot with the key path -spend removed. As a result, P2QRH does not have the Taproot internal key or tweak key, instead P2QRH commits directly to the -Merkle tree of scripts. +Commit-reveal schemes such as [https://gnusha.org/pi/bitcoindev/1518710367.3550.111.camel@mmci.uni-saarland.de/ Re: Transition to post-quantum (2018)] and [https://groups.google.com/g/bitcoindev/c/LpWOcXMcvk8/m/YEiH-kTHAwAJ Post-Quantum commit / reveal Fawkescoin variant as a soft fork (2025)] have been proposed as a way to create cryptocurrencies without public key cryptography. The ideas in this paper were more recently expanded upon by Tadge Dryja in his "[https://www.youtube.com/watch?v=4bzOwYPf1yo Lifeboat]" proposal, which effectively quantum-proofs Bitcoin transactions through a similar pre-commitment scheme designed for Bitcoin. -Below we attempt to summarize some of the ideas discussed on the Bitcoin Development Mailing List that relate to P2QRH. +==Other Methods of Addressing Quantum Vulnerabilities for Cryptocurrencies== -The idea of Taproot but with the key path spend removed has been discussed a number of times in the Bitcoin community. -[https://gnusha.org/pi/bitcoindev/CAD5xwhgzR8e5r1e4H-5EH2mSsE1V39dd06+TgYniFnXFSBqLxw@mail.gmail.com/ OP_CAT Makes Bitcoin Quantum Secure] -notes that if we disable the key path spend in Taproot and activated CAT [https://github.com/bitcoin/bips/blob/master/bip-0347.mediawik BIP 347], -we could achieve quantum resistance by using Lamport signatures with CAT. Lamport and WOTS (Winternitz One-Time Signatures) built from CAT -are quantum resistant but are one-time signatures. This means that if you sign twice for the same public key, you leak your secret key. -This would require major changes to wallet behavior and would represent a significant security downgrade. -[https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/rTrpeFjWDAAJ Trivial QC signatures with clean upgrade path] and -[https://groups.google.com/g/bitcoindev/c/oQKezDOc4us/m/T1vSMkZNAAAJ Re: P2QRH / BIP 360 Update] discusses the idea of -Taproot but with the future ability to disable the key path spend. -The design of P2QRH is partly inspired by these discussions as P2QRH can be understood as P2TR without the key path spend. +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] to Ethereum's quantum vulnerability is quite different from the approach in this BIP. -Commit-reveal schemes such as -[https://gnusha.org/pi/bitcoindev/1518710367.3550.111.camel@mmci.uni-saarland.de/ Re: Transition to post-quantum (2018)] -and [https://groups.google.com/g/bitcoindev/c/LpWOcXMcvk8/m/YEiH-kTHAwAJ Post-Quantum commit / reveal Fawkescoin variant as a soft fork (2025)] -have been proposed as a way to safely spend Bitcoin if CRQCs become practical prior to Bitcoin adopting achieving quantum resistance. -The essential idea is to leverage the fact that a CRQC can only learn your private key after a user has revealed their public key. -Thus, Bitcoin could fork in an alternative way to spend an output that would leverage this property. -Spending via commit-reveal would require two steps, first the user's commits on-chain to their public key along with a set of outputs the user wishes -to spend to. Then, in reveal, the user sign and reveals their public key. While CRQC might be able to generate competing signatures it can not produce -a commitment to the user's public key earlier than the user's commitment as it does not learn it until the reveal step. +His plan involves a hard fork of the chain, reverting all blocks after some sufficient amount of theft, and using STARKs based on BIP 32 seeds to act as the authoritative secret when signing. We believe rollbacks of any kind are an untenable approach for Bitcoin and would likely be impractical to implement. -Commit-reveal schemes can only be spent from and to outputs that are not vulnerable to long-exposure quantum attacks, such as -P2PKH, P2SK, P2WPKH, etc... To use tapscript outputs with this system either a soft fork could disable the key path spend of P2TR outputs -or P2QRH could be used here as it does not have a key path spend and thus is not vulnerable to long-exposure quantum attacks. +That said, we believe the use of STARKs (which are quantum-resistant) may prove useful as a method of proving access to external private keys, in the event that the community chooses to burn vulnerable coins as proposed by Jameson Lopp and others in [https://qbip.org/ QBIP]. -== References == +Discussions related to the burning of coins, and other attempts to slow a potential supply shock caused by quantum-retrieval of vulnerable coins, are out of scope for this proposal. That said, members of our team have separately proposed [https://github.com/cryptoquick/bips/blob/hourglass/bip-hourglass.mediawiki Hourglass] to address this concern and are continuing research on this subject. -* [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] +==Conclusion== -== Footnotes == +In this proposal, we adopt a "prepared not scared" approach to the possible advancement of quantum computing and offer Bitcoin users an option for increased protection if they so choose. This BIP does not take a position on any specific quantum computing timeline, but rather proposes a flexible and unobtrusive option for users that wish to mitigate this risk according to their own estimate of the timeline. - +This is an issue that has been discussed with some regularity in [https://bitcointalk.org/index.php?topic=133425.0 Bitcoin forums] since at least 2012, and there is clearly user demand for increased quantum protection. -== Changelog == +==Glossary== -To help implementors understand updates to this BIP, we keep a list of substantial changes. +'''Quantum Key Recovery''' +The derivation of private keys from public keys in elliptic curve cryptography (ECC), made possible by solving the discrete logarithm problem (DLP). + +Shor's algorithm, developed by Peter Shor in 1994, is a quantum algorithm that efficiently solves the discrete logarithm problem - potentially made possible by the future viability of cryptographically relevant quantum computers (CRQCs). + +'''Long Exposure Attacks''' + +Attempts to derive private keys from public keys that are exposed for an extended period of time; that is, longer than the window of time that a public key is generally exposed in the mempool while waiting to be confirmed. + +Long exposure attacks give attackers an unlimited amount of time to perform quantum key recovery, as long as funds remain in the output. Poor wallet hygiene (e.g. from address reuse) or use of outputs with exposed public keys (e.g. P2TR outputs) increases vulnerability to long exposure attacks. + +'''Short Exposure Attacks''' + +Attempts to derive private keys from public keys during the brief period when funds are unconfirmed in the mempool. These attacks cannot be prevented through wallet hygiene, as revealing a public key is necessary for spending. + +Protection against short exposure attacks may require post-quantum signature schemes; that said, executing these attacks requires faster CRQCs than those capable of executing long exposure attacks and are therefore viewed as lower-risk than long exposure attacks in the nearer term. + +'''Tapscript-Native Output Type''' + +Tapscript-native output types are the category of output types that support tapscript (including Schnorr signatures) and taptrees. + +'''Pay-to-Tapscript-Hash (P2TSH)''' + +A tapscript-native output type, similar to to Pay-to-Taproot (P2TR), but with the quantum-vulnerable key path spend removed. + +==Footnotes== + + + +==Changelog== + +To help implementers understand updates to this BIP, we keep a list of substantial changes. + +* 2025-09-17 - Rewrote BIP for clarity and renamed from P2QRH to P2TSH * 2025-07-20 - Changed the Witness Version from 3 to 2. -* 2025-07-07 - P2QRH is now a P2TR with the vulnerable key path spend disabled. Number of PQ signature algorithms supported reduced from three to two. PQ signature algorithm support is now added via opcodes or tapleaf version. +* 2025-07-07 - P2QRH is now a P2TR with the vulnerable key path spend removed. Number of PQ signature algorithms supported reduced from three to two. PQ signature algorithm support is now added via opcodes or tapleaf version. * 2025-03-18 - Correct inconsistencies in commitment and attestation structure. Switch from Merkle tree commitment to sorted vector hash commitment. Update descriptor format. -* 2025-03-12 - Add verification times for each algorithm. 256 -> 128 (NIST V -> NIST I). Add key type bitmask. Clarify multisig semantics. +* 2025-03-12 - Add verification times for each algorithm. 256 to 128 (NIST V to NIST I). Add key type bitmask. Clarify multisig semantics. * 2025-02-23 - More points of clarification from review. Update dead link. -* 2025-01-20 - Remove SQIsign from consideration due to significant performance concerns. Refactor language from long-range attack to long-exposure so as to not be confused with the language around block re-org attacks. +* 2025-01-20 - Remove SQIsign from consideration due to significant performance concerns. Refactor language from long range attack to long exposure so as to not be confused with the language around block re-org attacks. * 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-01 - Add details on attestation structure and parsing. @@ -712,14 +410,12 @@ To help implementors understand updates to this BIP, we keep a list of substanti * 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 == +==Acknowledgements== + +This document is inspired by [[bip-0341.mediawiki|BIP 341]], which introduced the design of the P2TR (Taproot) output type using Schnorr signatures. + +I'm incredibly grateful to Ethan Heilman for joining as co-author and transforming this BIP into something far more congruent with existing Bitcoin design. Additionally, much gratitude to our most recent co-author, Isabel Foxen Duke, for her thoughtful editing and crafting much of the language in this proposal. I am likewise indebted to those on the Anduro Quantum Working Group who took the time to contribute including Jeff Bride, Michael Casey, and notmike. -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) output type using Schnorr signatures. +Thank you as well to those who took the time to review and contribute, including Jon Atack, Adam Borcany, Ava Chow, Kyle Crews, Pierre-Luc Dallaire-Demers, D++, Mark Erhardt, Jameson Lopp, Antoine Riard, Armin Sabouri, Vojtěch Strnad, Guy Swann, and Joey Yandle. -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. The -attestation was later discarded when Ethan Heilman joined as co-author, whom I'm incredibly grateful to for -transforming this BIP into something far more congruent with existing Bitcoin design. 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, D++ (dplusplus1024), Mark Erhardt, Joey Yandle, Jon Atack, Armin Sabouri, Jameson Lopp, and Vojtěch Strnad. +Whatever inaccuracies may remain are attributable solely to the authors. diff --git a/bip-0360/bip360.org b/bip-0360/bip360.org deleted file mode 100644 index 4f5fd99bed..0000000000 --- a/bip-0360/bip360.org +++ /dev/null @@ -1,485 +0,0 @@ -* Abstract - -This document proposes the introduction of a new output type: Pay-to-Tapscript-Hash (P2TSH), via a soft fork. - -Proposed P2TSH addresses are nearly identical to Pay-to-Taproot (P2TR) addresses --- with the quantum-vulnerable key path spend removed. - -Through this modification, P2TSH addresses create the option of using -Taproot in a manner that is: - - - resistant to potential attacks by cryptographically relevant - quantum computers (CRQCs) in the event that such technology - becomes viable - - - resistant to any pending technology --- for that matter --- that - could potentially threaten ECDSA cryptography over time - -It is worth noting that proposed P2TSH addresses are only resistant to so-called “long exposure attacks” on ECDSA cryptography; that is, attacks on keys exposed for time periods longer than needed to confirm a spending transaction (~10 minutes). - -This is currently the highest degree of quantum protection offered by any existing Bitcoin output type (e.g. P2PKH or other output types with hashed public keys). - -Higher levels of quantum protection, including protection against retrieval of keys exposed in the mempool while a transaction is waiting to be confirmed (a.k.a. “short exposure attacks”), will require the introduction of post-quantum signature schemes in Bitcoin addresses. - -Since the risk of short exposure attacks is lesser than long-exposure attacks in the nearer term—and protecting against short exposure attacks requires more complex changes to the network—we are not recommending the introduction of post-quantum signatures into Bitcoin at this time. - -That said, for maximum protection of funds against potential quantum attacks, we believe it’s worth considering this path in the future and intend to offer a separate proposal for this purpose upon further research. - -Additionally, we believe proposed P2TSH addresses will be the strongest base address type with which to use post-quantum signatures in the future. - -If or when the community chooses to implement them, we believe post-quantum signatures will be most safely added to Bitcoin as Tapscript opcodes—which carry less risk of triggering a hard fork when compared to adding opcodes to Bitcoin script. - -For emphasis, this proposal does not address the full scope of Bitcoin’s broader quantum vulnerabilities. We believe these issues should be addressed individually by separate proposals—to ensure community consensus around each of the varying challenges quantum advancements could pose to Bitcoin over time. - -Lastly, this document defines the specific quantum attack-vectors and -new terms that we are concerned with in this proposal. - -* Motivation - -The primary threat to Bitcoin from Cryptographically Relevant Quantum Computers (CRQCs)[1] is their potential to break the cryptographic assumptions of Elliptic Curve Cryptography (ECC), which secures Bitcoin's signatures (ECDSA) and Taproot commitments (Schnorr). - -More specifically, Shor's algorithm enables a CRQC to solve the Discrete Logarithm Problem (DLP) exponentially faster than classical methods[2], allowing the derivation of private keys from public keys --- a process referred to here as quantum key recovery. [3] - -While it is unclear when or if this technology will become viable in the future, we propose the addition of a quantum-resistant, tapscript-supportive output type—for optional use by taproot-users wanting quantum-grade protection. - -While some may balk at the potential threat of quantum computers to Bitcoin given their limited functionality to date, some others are concerned about their potential for advancement—including governments, corporations and some existing and potential Bitcoin users. - -The Commercial National Security Algorithm Suite (CNSA) 2.0, for instance, has mandated software and networking equipment to be upgraded to post-quantum schemes by 2030, with browsers and operating systems fully upgraded by 2033. - -Additionally, according to NIST IR 8547, Elliptic Curve Cryptography is planned to be disallowed within the US federal government after 2035 (with an exception made for hybrid cryptography, or the use of ECC and post-quantum algorithms together). - -These kinds of mandates have triggered concern by some ECC users --- including some Bitcoin users who prefer to be prepared out of an abundance of caution. - -In the most optimistic case --- wherein quantum computers never pose a significant risk to ECC --- we understand that the possibility of advancement alone may be influencing adoption and broad confidence in the network. - -In other words, we believe users’ fear of quantum computers may be worth addressing regardless of CRQC viability, which is difficult to assess. - -Given these concerns, we think it’s worth considering changes that are -minimal in complexity and risk, and which create new options for using Bitcoin in a quantum-resistant way. - -As a conservative first step in this effort, we propose Pay-to-Tapscript-Hash (P2TSH) --- a tapscript-supportive output type that can be used in a quantum resistant manner. - -* Long Exposure vs Short Exposure Quantum Vulnerability - -For clarity, this proposal specifically mitigates against the risk of long exposure attacks on taproot addresses. While other Bitcoin output types already mitigate against this risk, Taproot addresses (P2TR output types) are currently vulnerable to long-exposure quantum attacks. - -A long-exposure attack may be considered one performed with chain data, such as that from a used address or one encoded in a spend script, or any other attack on keys that are made vulnerable through knowledge transfer that is not inherently time-sensitive. - -These are likely to be the earliest quantum attacks made possible on Bitcoin, because attackers will have ample time—as much time as vulnerable keys are exposed—to carry out quantum key recovery. - -Short exposure attacks, on the other hand, require faster quantum computers—because they must occur within the relatively short time that a transaction is being confirmed in the mempool (~10 minutes). - -At present, Taproot addresses are fundamentally vulnerable to long-exposure attacks, because they encode a 32-byte x-only public key, from which a full public key can be reconstructed. - -All Bitcoin addresses are currently vulnerable to short exposure attacks—and will likely remain so unless or until Bitcoin integrates post-quantum signatures. These types of attacks, however, are less likely in the nearer term. - -Since long-exposure attacks on public keys are likely to be the first quantum-enabled threat to Bitcoin, we propose a tapscript-supportive output type that is resistant to long-exposure attacks as a first step in hardening Bitcoin against the potential threat of quantum computers. - -Many will point out accurately that most non-Taproot addresses already protect against long-exposure attacks; however, we believe that the development of a tapscript-supportive output type that is resistant to long exposure attacks is a critical first step in addressing a potential quantum threat. - -The following list of output types describes their long-exposure attack vulnerability: - -Note: funds in P2PKH, P2SH, P2WPKH, and P2WSH outputs become vulnerable to long-exposure quantum attacks anytime their input script is revealed. For instance, an address is no longer safe against long-exposure attacks after funds from that address have been spent. - -A complete list of addresses that are vulnerable to long-exposure attacks includes: - - - P2PK outputs (Satoshi's coins, CPU miners, starts with 04) - - - Reused addresses (any type, except P2QRH) - - - Taproot addresses (starts with bc1p) - - - Extended public keys, commonly known as "xpubs" - - - Wallet descriptors - -By comparison, short exposure attacks may affect any Bitcoin address with unconfirmed transactions currently in the mempool—as all Bitcoin transactions require revealing the associated public key. - -The only way to fully protect addresses from short-exposure attacks is through the use of post-quantum signature schemes (or the use of private mempools, which is not ideal). - -For further clarification on quantum attack vectors, please refer to the Glossary of Terms. - -* Design - -P2TSH (Pay-to-Tapscript-Hash) is a proposed new output type that commits to the root of a tapleaf Merkle tree. It operates with nearly the same functionality as P2TR (Pay-to-Taproot) addresses—but with the quantum vulnerable key path spend removed. - -In other words, P2TSH addresses commit to the root of a tapleaf merkle tree without commitment to an internal key. The script(s) being committed to, however, may contain a key or key-hash. - -This output type is designed to offer taproot users a quantum-resistant method of operation—as well as a practical output type with which post-quantum signatures may be useable in the future. - -Since P2TSH has no key path spend, P2TSH omits the Taproot internal key. Instead, a P2TSH output includes only the 32-byte root of the tapleaf Merkle tree as defined in BIP 341 hashed with the tag "MerkleRoot" as shown below. - -To construct a P2TSH output, we follow the process outlined in BIP 341 to compute the tapscript Merkle root; however, instead of hashing the root of the Merkle tree with an internal key (as is the case with P2TR addresses), P2TSH addresses commit only to a hash of the Merkle root, combined with the tag "MerkleRoot". - -A P2TSH input witness provides the following: - -The initial stack elements provide the same functionality as they do in P2TR. That is, they place elements on the stack to be evaluated by the script, a.k.a. the redeem script. - -The control block is a 1 + 32 * m byte array, where the first byte is the control byte and the next 32*m bytes are the Merkle path to the script. The control byte is the same as the control byte in a P2TR control block, including the 7 bits which are used to specify the tapleaf version. The parity bit of the control byte is always 1, since P2TSH does not have a key path spend. - -Additionally, we omit the public key from the control block as it is not needed in P2TSH. Lastly, we maintain support for the optional annex in the witness (see specification for more details). - -** Architecture Rationale - -Design of the P2TSH output type is guided by the following intentions: - - 1) Minimize changes to the network—we should reuse existing Bitcoin code and preserve existing software behavior, workflows, user expectations and compatibility whenever possible. - -P2TSH leverages the mature and battle tested P2TR, tapleaf and tapscript code already in Bitcoin --- reducing the implementation burden on wallets, exchanges, and libraries, which can reuse code they already have. This approach reduces complexity and minimizes implementation risks. - - - 2) Create the safest possible path for the addition of post-quantum signature integrations --- in the event they are used in the future. - - -Importantly, we are proposing a tapscript-functional output type that is resistant to long-exposure attacks. While some existing output types are already resistant to long-exposure attacks (e.g. P2WSH), no such output type supports tapscript --- which may be required for practical implementation of post-quantum signature opcodes. - - -More specifically, Bitcoin script does not support OP_SUCCESSx opcode upgrades, which may prove critical for the integration of post-quantum signatures into Bitcoin addresses. - - 3) Facilitate gradual integration of quantum resistant features that can be carried out iteratively as quantum computers evolve. This approach encourages responsiveness to the current threat-level, while avoiding heavy-handedness in our reactions to a potential threat. - -We designed P2TSH with an eye towards integrating post-quantum signatures in the future, without proposing more complex changes while CRQCs are still in their infancy. - -** P2TSH Benefits for Long-Term Wallet Safety - -Because tapscript-supportive outputs enable commitments to a MAST, it is possible to create P2TSH wallets with post-quantum signature scripts—before activating post-quantum signatures within consensus rules. - -Wallets, for instance, may create addresses with scripts including post-quantum signatures—that only become useable after a soft-fork activation. - -This approach enables us to prepare for a potential threat without activating a post-quantum soft fork until “Q Day” arises. - -Consider, for instance, a P2TSH output with three possible tapscripts: - - - Spend requires a Schnorr signature - - - Spend requires a ML-DSA signature - - - Spend requires a SLH-DSA signature - -In the event that Schnorr signatures are broken by quantum computers, we can activate ML-DSA or SLH-DSA signatures on the network—allowing users to spend their coins with these quantum-resistant signatures when needed. - -In other words, P2TSH enables signature-type redundancies that may prove critical on a long enough time horizon. Through this architecture, one could safe-guard their Bitcoin in a single wallet for 20, 50, or 100 years and beyond—without worrying about potential risks to ECDSA security. - -** P2TSH Trade-Offs for Consideration - -While P2TR addresses (and the use of key path spend) will remain an option for folks wishing to use them—we aim to be clear about the tradeoffs of using P2TSH addresses, which disable the key path spend for the benefit of quantum protection. - -First off, P2TSH script path spends are slightly larger than P2TR key path spends. We estimate this to be [??]. That said, script path spends from P2TSH addresses will be slightly smaller than script path spends from P2TR addresses. - -Additionally, users will functionally reveal they are spending to a script tree whenever they are using P2TSH addresses—since P2TSH addresses can only spend via script path spend. - -* Specification - -We define the Pay-to-Tapscript-Hash (P2TSH) output structure as follows: - -A P2TSH output is equivalent to a P2TR output that uses the root of a tapleaf Merkle tree [as defined in BIP 341] in conjunction with the tag “MerkleTree” for its internal value. For benefit of quantum resistance, no internal key is referenced in this value. - -To construct a P2TSH output, we follow the same process as outlined in BIP341 to compute a tapscript Merkle root; however, instead of using the root of a Merkle tree hashed with an internal key—the root is hashed without any key data and includes the tag "MerkleRoot." This hash is then set as the witness program. - -* Address Format - -P2TSH uses SegWit version 2 outputs, resulting in addresses that start with bc1z, following BIP 173. Bech32 encoding maps version 2 to the prefix z. - -Sample P2TSH address: - -bc1zzmv50jjgxxhww6ve4g5zpewrkjqhr06fyujpm20tuezdlxmfphcqfc80ve - -This is 32-byte Bech32m-encoded tapleaf Merkle root. - -* ScriptPubKey - - -The scriptPubKey for a P2TSH output is: - - OP_2 OP_PUSHBYTES_32 - -Where: - - OP_2 (0x52) indicates SegWit version 2. - - is the 32-byte tapleaf Merkle root. - -* Script Validation - -A P2TSH output is a native SegWit output (see BIP141) with version 2 and a 32-byte witness program. Unlike Taproot, this witness program is the tapleaf Merkle root. For the sake of comparison, we have - as much as possible - copied the language verbatim from script validation section of BIP341. - - Let q be the 32-byte array containing the witness program (the second push in the scriptPubKey) which represents root of tapleaf Merkle tree. - - Fail if the witness stack does not have two or more elements. - - If there are at least three witness elements, and the first byte of the last element is 0x50, this last element is called annex a and is removed from the witness stack. - The annex (or the lack thereof) is always covered by the signature and contributes to transaction weight, but is otherwise ignored during Taproot validation. - - There must be at least two witness elements left. - - Call the second-to-last stack element s, the script (as defined in BIP 341) - - The last stack element is called the control block c, and must have length 1 + 32 * m, for a value of m that is an integer between 0 and 128, inclusive. Fail if it does not have such a length. - - Let v = c[0] & 0xfe be the leaf version (as defined in BIP 341). To maintain leaf version encoding compatibility the last bit of c[0] is unused and must be 1 [12]. - - Let k0 = hashTapLeaf(v || compact_size(size of s) || s); also call it the tapleaf hash. - - For j in [0,1,...,m-1]: - - Let ej = c[33+32j:65+32j]. - - Let kj+1 depend on whether kj < ej (lexicographically): - - If kj < ej: kj+1 = hashTapBranch(kj || ej). - - If kj ≥ ej: kj+1 = hashTapBranch(ej || kj). - - Let r = hashQuantumRoot(km). - - If q ≠ r, fail. - - Execute the script, according to the applicable script rules, using the witness stack elements excluding the script s, the control block c, and the annex a if present, as initial stack. This implies that for the future leaf versions (non-0xC0) the execution must succeed. - -The steps above follow the script path spend logic from BIP 341 with the following changes: - - The witness program is the tapleaf Merkle root and not a public key. This means that we skip directly to the BIP 341 spend path tapleaf Merkle tree validation. - - We compute the tagged tapleaf Merkle root r and compare it directly to the witness program q. - - The control block is 1 + 32*m bytes, instead of 33 + 32*m bytes. - -* Sighash Calculation - -The sighash for P2TSH outputs follows the same procedure as defined in BIP 341 for - -Taproot transactions: - - Signature Message: A single-SHA256 of a tagged hash with the tag "TapSighash", containing transaction data. - - Tagged Hash: Computed as H(tag || tag || data) where H is SHA256 and tag is the SHA256 of the tag name. - - Key Data: In addition to transaction data, the sighash includes the spent output's scriptPubKey. - - Extension Fields: Specific data is included or excluded from the sighash based on the sighash flag. - -This signature hash construction ensures transaction malleability is prevented while providing flexibility through different sighash types (DEFAULT, ALL, NONE, SINGLE, and ANYONECANPAY variants). The exact computation follows the procedure specified in BIP 341 to maintain compatibility with Taproot signatures. - -If a sighash flag other than DEFAULT is needed, it can be placed in the transaction witness. In this case, it will be the only field in the witness. - -* Compatibility with BIP 141 - -By adhering to the SegWit transaction structure and versioning, P2TSH outputs are compatible with existing transaction processing rules. Nodes that do not recognize SegWit version 2 will treat these outputs as anyone-can-spend but, per BIP 141, will not relay or mine such transactions. - -** Transaction Size and Fees - - Equivalent P2TSH and P2TR outputs are always the same size. P2TSH - inputs can be slightly larger or smaller than their equivalent P2TR - inputs --- depending on the use of key-path or script-path spend in - the case of P2TR. - -Let's consider the cases. - -** Comparison with P2TR key path spend: - -P2TSH inputs will be larger than P2TR inputs when the P2TR output -would have been spent via the key path spend. P2TSH quantum resistance -comes from removing the P2TR key path spend. Consequently, it cannot -make use of Taproot's optimization where P2TR key path spends do not -require inclusion of a Merkle path in the P2TR input. If the Merkle -tree only has a single leaf script, no Merkle path is needed in the -control block, giving us a 1-byte control block. - -** P2TSH witness (103 bytes): - -[count] (1 byte), # Number of elements in the witness - -[size] signature (1 + 64 bytes = 65 bytes), tapleaf script = [size] [OP_PUSHBYTES_32, 32-byte public key, OP_CHECKSIG] (1 + 1 + 32 + 1 bytes = 35 bytes), control block = [size] [control byte] (1 + 1 = 2 bytes) - -** P2TR key path spend witness (66 bytes): - -[count] (1 byte), # Number of elements in the witness [size] signature (1 + 64 bytes = 65 bytes) - -Thus, the P2TSH input would be 103 - 66 = 37 bytes larger than a P2TR key path spend input. - -If the Merkle tree has more than a single leaf, then the Merkle path must be included in the control block. P2TSH witness (103+32*m bytes) - -[count] (1 byte), # Number of elements in the witness [size] signature (64 + 1 bytes = 65 bytes), - -tapleaf script = [size] [OP_PUSHBYTES_32, 32-byte public key, OP_CHECKSIG] (34 + 1 bytes = 35 bytes), - -control block = [size] [control byte, 32 * m byte Merkle path] (1 + 1 + 32 * m = 2 + 32 * m bytes) - -For a Merkle path of length m, an additional ~32 * m bytes would be added to the P2TSH input. This would make such input 37 + 32 * m bytes larger than a P2TR key path spend input[13]. - -** Comparison with P2TR script path spend: - -A P2TSH input will be smaller than an equivalent script path spend for P2TR inputs. This is because P2TSH inputs do not require inclusion of a public key in the control block to open the commitment to the Merkle root. A P2TSH input will be 32 bytes smaller than an equivalent P2TR script path spend input. - -** Consider a P2TSH output with a post-quantum signature leaf and a Schnorr leaf: - -The P2TSH witness to spend the Schnorr path would be 103 + 32 * 1 = 135 bytes. While it is unfortunate that we cannot use the key path spend optimization for P2TSH inputs—the key path spend optimization is exactly what makes P2TR vulnerable to quantum attacks. If the key path spend was quantum resistant, we wouldn't need P2TSH in the first place. - -** Performance Impact - -P2TSH is slightly more computationally performant than P2TR, as the operations to spending a P2TSH output is a strict subset of the operations needed to spend a P2TR output. - -** Backward Compatibility - -Older wallets and nodes that have not been made compatible with SegWit version 2 and P2TSH will not recognize these outputs. Users should ensure they are using updated wallets and nodes to use P2TSH addresses and validate transactions using P2TSH outputs. P2TSH is fully compatible with tapscript and existing tapscript programs can be used in P2TSH outputs without modification. - -** Security - -P2TSH outputs provide the same tapscript functionality as P2TR outputs, but without the quantum-vulnerable key path spend. This enables users, exchanges and other users to easily move their coins from Taproot outputs to P2TSH outputs and thereby protect their coins from long-exposure quantum attacks. - -Protection from long-exposure quantum attacks does not depend on the activation of post-quantum signatures in Bitcoin, but does require that users do not expose their quantum vulnerable public keys to attackers via address reuse or other unsafe practices. - -P2TSH uses a 256-bit hash output, providing 128 bits of collision resistance and 256 bits of preimage resistance. This is the same level of security as P2WSH, which also uses a 256-bit hash output. - -P2TSH does not, by itself, protect against short-exposure quantum attacks, but such attacks can be mitigated by the future activation of post-quantum signatures in Bitcoin. - -Combined with P2TSH, the introduction of post-quantum signature schemes would provide more comprehensive quantum resistance to P2TSH outputs—including protection from short exposure attacks. - -That said, the protection offered by resistance to long-exposure attacks alone should not be underestimated. It is likely that the first CRQCs (Cryptographically Relevant Quantum Computers) will not be able to perform short-exposure attacks - as such, defense against long-exposure attacks is more time sensitive than prevention against short-exposure attacks. - -** Security Considerations for Post-Quantum Signature Schemes - -While this proposal does not include the introduction of post-quantum signature schemes, we think it’s worth commenting on security considerations related to this possibility. - -Quantum-resistant signature algorithms (e.g. ML-DSA or SLH-DSA) offer different theorized levels of protection—and should be scrutinized as such before use. We are currently researching options for the potential proposal of post-quantum signatures into Bitcoin—and encourage others to engage in this research as well. - -We also imagine the possibility of introducing multiple post-quantum signatures into Bitcoin for redundancy. Balancing the risks of additional complexity with the benefits of signature-type redundancy will be the challenge here. - -* Test Vectors and Reference Code - -TBD - -* Related Work - -Below we attempt to summarize some of the ideas discussed on the Bitcoin Development Mailing List that relate to P2TSH. - -The idea of Taproot with key path spend removed has been discussed a number of times in the Bitcoin community. - -For instance, OP_CAT Makes Bitcoin Quantum Secure notes that if we disable the key path spend in Taproot and activated CAT BIP 347, we could achieve quantum resistance by using Lamport signatures with CAT. - -Lamport and WOTS (Winternitz One-Time Signatures) built from CAT are quantum resistant, but are one-time signatures—meaning, if you sign twice for the same public key, you leak your secret key, which is a significant practical vulnerability for everyday users. - -This would require major changes to wallet behavior and would represent a significant security downgrade. - -Trivial QC signatures with clean upgrade path and Re: P2QRH / BIP 360 Update also discuss the possibility of Taproot with key path spend removed. The design of P2TSH was partly inspired by these discussions. - -Commit-reveal schemes such as Re: Transition to post-quantum (2018) and Post-Quantum commit / reveal Fawkescoin variant as a soft fork (2025) have been proposed as a way to safely spend Bitcoin if CRQCs become practical prior to Bitcoin adopting achieving quantum resistance. - -* Other Methods of Addressing Quantum Vulnerabilities for Cryptocurrencies - -It is worth noting, by way of comparison, that Vitalik Buterin's proposed solution to Ethereum’s quantum vulnerability is quite different from the approach in this BIP. - -His plan involves a hard fork of the chain, reverting all blocks after some sufficient amount of theft, and using STARKs based on BIP 32 seeds to act as the authoritative secret when signing. We believe rollbacks of any kind are an untenable approach for Bitcoin—and would be practically impossible to implement. - -That said, we believe the use of STARKs (which are quantum-resistant) may prove useful as a method of proving access to external private keys, in the event that the community chooses to burn vulnerable coins—as proposed by Jameson Lopp and others in QBIP. - -Discussions related to the burning of coins, and other attempts to slow a potential supply shock caused by quantum-retrieval of vulnerable coins, are out of scope for this proposal. That said, we have separetly proposed Hourglass to address this concern and are continuing research on this subject. - -Commit-reveal schemes? Other? - -* Conclusion - -coming soon - -* Glossary - -- Quantum Key Recovery -The derivation of private keys from public keys in elliptic curve cryptography (ECC)—made possible by solving the discreet logarithm problem (DLP). - -- Shor’s algorithm, developed by Peter Shor in 1994, is a quantum algorithm that efficiently solves the discrete logarithm problem—potentially made possible by the future viability of cryptographically relevant quantum computers (CRQCs). - -- Long-Exposure (Quantum) Attacks -Attempts to derive private keys from public keys that are vulnerable for an extended period of time—that is, longer than the ~10 minute window that a public key is exposed in the mempool while waiting to be confirmed. - -Long exposure attacks give quantum attackers an unlimited amount of time to perform quantum key derivation, as long as funds remain in the address. Poor wallet hygiene (e.g. from re-using addresses) or use of addresses with exposed public keys (e.g. Taproot addresses) increases vulnerability to long exposure attacks. - -- Short-Exposure (Quantum) Attacks -Attempts to derive private keys from public keys during the brief period when funds are unconfirmed in the mempool. These attacks cannot be prevented through wallet hygiene, as revealing a public key is necessary for spending. - -Protection against short-exposure attacks requires post-quantum signature schemes; that said, executing these attacks requires faster CRQCs than those capable of executing long exposure attacks—and are therefore viewed as lower-risk than long-exposure attacks in the nearer term. - -- Tapscript-Supportive Output Type -Tapscript-supportive output types are the category of output types that support tapscript (including Schnorr signatures) and enable taproot-dependent technologies. - -- Pay-to-Tapscript-Hash (P2TSH) -A tapscript-supportive output type with nearly identical formatting to Pay-to-Taproot (P2TR)—with the quantum-vulnerable key path spend removed. - -* Footnotes - - ^ A Cryptographically Relevant Quantum Computer is an object which is only loosely defined by characteristics in quantum physics as of today. It could be understood in the context of this BIP and in Bitcoin that it's a hardware-agnostic computer supposed to have the architecture to keep coherent a sufficient number of logical qubits to be able to run the Shor algorithm in an efficient fashion. - - ^ Shor's algorithm is believed to need 10^8 operations to break a 256-bit elliptic curve public key. - - ^ Meaning, deriving private keys from public keys via Shor's algorithm - - ^ A vulnerable Bitcoin address is any scriptPubKey type that exposes an elliptic curve public key as raw bytes in a block, making it susceptible to private key derivation through Shor's algorithm. This includes P2PK outputs and any script that contains an unprotected or reused public key. - - ^ In the paper How to compute a 256-bit elliptic curve private key with only 50 million Toffoli gates the authors estimate that a 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. - - ^ Used by P2PKH, P2SH, and P2WPKH addresses, though not P2WSH because it uses 256-bit hashes. - - ^ Matt Corallo, Trivial QC signatures with clean upgrade path, (2024) - - ^ "[SQIsign] signing is now nearly 20× faster, at 103.0 Mcycles, and verification is more than 6× faster, at 5.1 Mcycles" SQIsign: Algorithm specifications and supporting documentation Version 2.0 (February 5 2025) - - ^ Why not have CHECKSIG infer the algorithm based on signature size? Each of the three signature algorithms, Schnorr, ML-DSA, and SLH-DSA, have unique signature sizes. The problem with using signature size to infer algorithm is that spender specifies the signature. This would allow a public key which was intended to be verified by Schnorr to be verified using ML-DSA as the spender specified a ML-DSA signature. Signature algorithms are often not secure if you can mix and match public key and signature across algorithms. - - ^ Bas Westerbaan (2025), jpeg resistance of various post-quantum signature schemes - - ^ BIP 32 relies on elliptic curve operations to derive keys from xpubs to support watch-only wallets, which PQC schemes may not support. - - ^ Why set the last bit of c[0] to one? Consider a faulty implementation that deserializes the leaf version as c[0] rather than c[0] & 0xfe for both P2TR and P2QRH. If they test against P2QRH outputs and require that last bit is 1, this deserialization bug will cause an immediate error. - - ^ If m >= 8, then the compact size will use 3 bytes rather than 1 byte - - ^ 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. It's worth noting that Winternitz signatures can only safely be used one time per public key. If addresses are reused, private key information might be leaked, allowing attackers to spend future outputs assigned to the same address. - - ^ 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. - -* Changelog - -To help implementors understand updates to this BIP, we keep a list of substantial changes. - - 2025-07-20 - Changed the Witness Version from 3 to 2. - - 2025-07-07 - P2QRH is now a P2TR with the vulnerable key path spend disabled. Number of PQ signature algorithms supported reduced from three to two. PQ signature algorithm support is now added via opcodes or tapleaf version. - - 2025-03-18 - Correct inconsistencies in commitment and attestation structure. Switch from Merkle tree commitment to sorted vector hash commitment. Update descriptor format. - - 2025-03-12 - Add verification times for each algorithm. 256 -> 128 (NIST V -> NIST I). Add key type bitmask. Clarify multisig semantics. - - 2025-02-23 - More points of clarification from review. Update dead link. - - 2025-01-20 - Remove SQIsign from consideration due to significant performance concerns. Refactor language from long-range attack to long-exposure so as to not be confused with the language around block re-org attacks. - - 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-01 - Add details on attestation structure and parsing. - - 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-27 - Initial draft proposal - -* Acknowledgements - -This document is inspired by BIP 341, which introduced the design of the P2TR (Taproot) output type using Schnorr signatures. - -Much gratitude to 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. The attestation was later discarded when Ethan Heilman -joined as co-author, whom I'm incredibly grateful to for transforming -this BIP into something far more congruent with existing Bitcoin -design. Thank you as well to those who took the time to review and -contribute, including Jeff Bride, notmike, Adam Borcany, Antoine Riard, Pierre-Luc Dallaire-Demers, D++ (dplusplus1024), Mark Erhardt, Joey Yandle, Jon Atack, Armin Sabouri, Jameson Lopp, and Vojtěch Strnad. - -* Copyright - -This document is licensed under the 3-clause BSD license. diff --git a/bip-0360/media/merkletree.png b/bip-0360/media/merkletree.png new file mode 100644 index 0000000000..dc6bdccabf Binary files /dev/null and b/bip-0360/media/merkletree.png differ diff --git a/bip-0360/merkletree.svg b/bip-0360/media/merkletree.svg similarity index 82% rename from bip-0360/merkletree.svg rename to bip-0360/media/merkletree.svg index a3dcb37937..fca5d1a02e 100644 --- a/bip-0360/merkletree.svg +++ b/bip-0360/media/merkletree.svg @@ -2,14 +2,14 @@ + showguides="true" + inkscape:showpageshadow="2" + inkscape:deskcolor="#d1d1d1" + inkscape:export-bgcolor="#ffffffff" /> + + id="layer1" + transform="translate(-0.34020621)"> + + + P2QRH Witness (input) + id="tspan3">P2TSH Witness (input) annex + id="tspan5">annex 50 + id="tspan7">50 Initial stack + y="238.933" + id="tspan9">Initial stack Merkle path (32*m bytes) + y="116.78066" + id="tspan10">Merkle path (32*m bytes) Control block + y="116.78066" + id="tspan11">Control block Witness Program + y="116.78066" + id="tspan12">Witness Program SegWit version 3 + y="116.78066" + id="tspan13">SegWit version 2 tapleaf tapleaf version + y="251.86074" + id="tspan15">version tapleaf tapleaf version + y="251.86074" + id="tspan17">version 1 + y="286.50917" + id="tspan18">1 { + id="tspan19">{ { + id="tspan21">{ P2QRH scriptPubkey (output) + id="tspan23">P2TSH scriptPubKey (output) How the tapleaf Merkle Root is computed: + id="tspan25">How the Taptree Root is Computed: OP_PUSHNUM3 + y="69.920135">OP_PUSHNUM2 tapleaf Merkle root + id="tspan27"> taptree root tapleaf Merkle root - - tagged_hashQuantumRoot + sodipodi:role="line"> taptree root tagged_hashtagged_hash Tapleaf tagged_hashtagged_hash TapBranch tagged_hashtagged_hash TapBranch tagged_hashtagged_hash TapBranch tagged_hashtagged_hash TapBranch + style="font-size:16px;line-height:1.25;font-family:sans-serif;white-space:pre;shape-inside:url(#rect255768);display:inline" /> tapleaf + y="605.54433" + id="tspan28">tapleaf A + id="tspan29">A tapleaf tapleaf version + y="251.86074" + id="tspan32">version tapleaf + y="605.54433" + id="tspan33">tapleaf B + id="tspan34">B tapleaf tapleaf version + y="251.86074" + id="tspan37">version tapleaf + y="605.54433" + id="tspan38">tapleaf C + id="tspan39">C tapleaf tapleaf version + y="251.86074" + id="tspan42">version tapleaf + y="605.54433" + id="tspan43">tapleaf D + id="tspan44">D tapleaf tapleaf version + y="251.86074" + id="tspan47">version tapleaf + y="605.54433" + id="tspan48">tapleaf E + id="tspan49">E + style="font-size:16px;line-height:1.25;font-family:sans-serif;white-space:pre;shape-inside:url(#rect265632);display:inline" /> + style="font-size:16px;line-height:1.25;font-family:sans-serif;white-space:pre;shape-inside:url(#rect288534);display:inline" /> tagged_hashtagged_hash Tapleaf tagged_hashtagged_hash Tapleaf tagged_hashtagged_hash Tapleaf - tagged_hashtagged_hash Tapleaf + style="font-size:16px;line-height:1.25;font-family:sans-serif;white-space:pre;shape-inside:url(#rect389388);display:inline" /> + style="font-size:16px;line-height:1.25;font-family:sans-serif;white-space:pre;shape-inside:url(#rect450123);display:inline" /> + NB This example assumes that the hashed values of the leaf scripts are such that H(A) < H(B) and H(C) < H(D). + + diff --git a/bip-0360/merkletree.png b/bip-0360/merkletree.png deleted file mode 100644 index 62c73f3139..0000000000 Binary files a/bip-0360/merkletree.png and /dev/null differ