Bitcoin Resisting the Quantum Threat: BIP 360 proposal removes the Taproot vulnerable path and introduces a new output type, P2MR, via a soft fork.

Bitcoin 's efforts to resist quantum attacks continue to advance. Yesterday, the improvement proposal BIP 360, co-authored by Hunter Beast, Ethan Heilman, and Isabel Foxen Duke, was updated, proposing a new output type called P2MR (Pay-to-Merkle-Root). Through a soft fork, this adds a layer of quantum protection to Bitcoin without forcing everyone to migrate.

The core concept is actually quite intuitive: the current Taproot (P2TR) has two cost paths, where the "key path" relies on elliptic curve cryptography (ECC), which is precisely the part that quantum computers can theoretically break using Shor's algorithm. P2MR's approach is to directly dismantle this quantum-fragile path, retaining only the script tree path.

Faced with the potential threat of quantum attacks, BIP 360 is not a panic-driven, comprehensive overhaul, but rather a minimal, "better safe than sorry" modification. It doesn't even include post-quantum signature schemes (such as ML-DSA and SLH-DSA), but rather lays the groundwork for future integration of these schemes. The following is a translation of the proposal from [website name - implied]:

summary

This proposal introduces a new output type called Pay-to-Merkle-Root (P2MR) through a soft fork. P2MR works similarly to P2TR (Pay-to-Taproot), but removes the quantum-fragile key path cost.

This proposal enables developers to use script trees and tapscript in the following ways:

1. Defend against long-term exposure attacks launched by quantum computers (CRQC) with cryptographic breaking capabilities.
2. Resisting cryptanalysis methods that could potentially break elliptic curve cryptography in the future.

Important Note: P2MR outputs only provide protection against "long-term exposure attacks"—attacks targeting keys that have been exposed for extended periods. Protection against "short-term exposure attacks" (attacks while transactions are waiting for confirmation in the memory pool) may require future implementations of post-quantum signature schemes.

This document defines and provides supplementary explanations for "long-term exposure" and "short-term exposure" attacks in its glossary.

motivation

The main threat of quantum computing to Bitcoin comes from its potential ability to compromise the security of digital signatures. Specifically, Shor's algorithm enables CRQC to solve the Discrete Logarithm Problem exponentially faster, thereby deriving the private key from the public key—a process known as "quantum key recovery."

Although the timeline for the feasibility of CRQC remains uncertain, several organizations have expressed their concerns:

• The U.S. Commercial National Security Algorithm Suite (CNSA) 2.0 requires a quantum solution upgrade by 2030, and browsers and operating systems must be fully upgraded by 2033.
• NIST IR 8547 plans to ban the U.S. federal government from using elliptic curve cryptography (with the exception of hybrid encryption schemes) after 2035.
• Users' anxiety about the progress of quantum technology has affected the adoption and confidence in Bitcoin.

Even in the most optimistic scenario—where quantum computers never threaten the ECC—responding to user concerns about quantum risks could strengthen network adoption.

P2MR represents a conservative first step—enabling quantum-resistant Bitcoin usage without forcing everyone to participate.

Long-term exposure attack vs. short-term exposure attack

Long Exposure Attack: An attack targeting data already exposed on the blockchain (public keys, spent output scripts). The attacker has ample time to recover the quantum keys. This is likely the earliest threat posed by quantum computers to Bitcoin.

Short Exposure Attack: Requires a faster quantum computer and must be completed within a short window while the transaction awaits confirmation in the memory pool. Since most Bitcoin transactions require the public key to be revealed upon spending, the output is typically vulnerable.

Since long-term exposure attacks targeting public keys are likely to be the earliest quantum threat, P2MR proposes a script tree output type to defend against such attacks as a preliminary security enhancement measure.

Output type vulnerability table

Funds in P2PKH, P2SH, P2WPKH, P2WSH, and P2MR may still be vulnerable to long-term exposure quantum attacks when the script reveals the public key.

Fundamentally vulnerable output types:

• P2PK Output
• Reusable output
• Taproot output (bc1p)

Note: Extended public key (xpub) and wallet descriptor also reveal quantum-fragile public key information.

design

P2MR commits to the Merkle root of the script tree, but not to the internal key—removing the quantum-fragile key path cost while preserving the script tree and tapscript functionality.

Instead of using P2TR's tweaked internal key method, P2MR hashes the 32-byte script tree root defined in BIP 341 with a "TapBranch" label.

Script tree construction

 D = tagged_hash("TapLeaf", bytes([leaf_version]) + ser_script(script))CD = tagged_hash("TapBranch", C + D)CDE = tagged_hash("TapBranch", CD + E)ABCDE = tagged_hash("TapBranch", AB + CDE)

P2MR Witness Structure

初始堆疊元素0,...,初始堆疊元素N,葉腳本（leaf script）,控制區塊= [控制位元組, 32*m 位元組Merkle 路徑]

The initial stack elements follow the P2TR script path cost rules, placing elements on the stack for leaf script execution.

The control block is an array of 1 + 32*m bytes. The first byte is the control byte (specifying the leaf version via 7 bytes). Unlike P2TR, P2MR omits the public key in the control block. The parity bit is fixed at 1 because P2MR has no key path cost. Optional annex support is retained.

Design Principles

The design of P2MR follows three guiding principles:

1. Minimize network changes: Reuse existing, battle-proven P2TR, tapleaf, and tapscript code to reduce the implementation burden and complexity risks of wallets, exchanges, and libraries.
2. Paving the way for post-quantum signature integration: P2MR is the only script tree output type that can withstand long-term exposure attacks. The existing defense type (P2WSH) does not support tapscript and lacks the OP_SUCCESSx opcode upgrade path that is crucial for post-quantum OP_CHECKSIG integration.
3. Promote incremental integration of quantum-resistant features: The design allows for iterative adoption as quantum computers evolve, encouraging a measured rather than reactive approach.

The choice between P2MR

Witness size: P2MR witnesses cost more than P2TR key path (which requires only one signature), but less than the equivalent P2TR script path (because the internal key of 32 byte bits is omitted in the control block).

Privacy: Users who spend P2MR outputs reveal that they used a script tree, unlike P2TR key path spending which is more covert. However, P2MR and P2TR script path spending offer equivalent privacy, both being superior to P2SH (which reveals unused script paths).

Specification

P2MR is a native SegWit output (BIP 141) that uses version 2 and a 32-bit witness program. It functions similarly to P2TR, but is quantum resistant by disabling key path costs by omitting the internal key.

Address format

P2MR output uses SegWit version 2, and is encoded according to BIP 173's Bech32m encoding. The mainnet address starts with "bc1z" (the character "z" corresponds to version 2).

Example: bc1zzmv50jjgxxhww6ve4g5zpewrkjqhr06fyujpm20tuezdlxmfphcqfc80ve

This address is committed to a 32-bit script tree Merkle root.

ScriptPubKey

 OP_2 OP_PUSHBYTES_32 <hash>

in:

• OP_2 indicates SegWit version 2
• It is the 32-byte Merkle root of the script tree.

Script verification

P2MR is the native SegWit version 2 output with a 32-bit tuple witness. The verification logic is the same as the script path verification in BIP 341, but with the following modifications:

Verification steps:

1. Let q be a 32-byte witness program (the Merkle root of the script tree).
2. If the stack has fewer than two elements, the test fails.
3. If there are exactly two elements and the first byte of the last element is 0x50, then the process fails.
4. If there are at least three elements and the first byte of the last element is 0x50, then remove this element as Appendix a (overwritten by the signature, included in the weighting, and ignored during verification).
5. At least two witness elements must be retained:
   • The second-to-last element s is the script.
   • The last element 'c' is the control block, and its length must be 1 + 32*m (where m is between 0 and 128).
   • Let v = c[0] & 0xfe be the leaf version; the last bit of c[0] must be 1.
   • Let k₀ = hash_TapLeaf(v || compact_size(length of s) || s)
   • For j in [0, 1, …, m-1]:
     • Let eⱼ = c[1+32j : 33+32j]
     • If kⱼ < eⱼ: kⱼ₊₁ = hash_TapBranch(kⱼ || eⱼ)
     • If kⱼ ≥ eⱼ: kⱼ₊₁ = hash_TapBranch(eⱼ || kⱼ)
   • Let r = kₘ
   • If q ≠ r, then it fails.
6. The script is executed using BIP 342 rule, with the witness elements (excluding s, c, and a) used as the initial stack.

Key differences from BIP 341:

• The witness is the Merkle root, not the adjusted key.
• Jump directly to script path verification
• Calculate the Merkle root r of the script tree and compare it directly with q.
• The control block is 1 + 32 m bytes, not 33 + 32 m bytes.

General signature message construction

P2MR's signature message construction follows the "General Signature Message" procedure of BIP 342.

Compatibility with BIP 141

P2MR follows the SegWit transaction structure and version control, maintaining compatibility with existing transaction processing. Nodes unfamiliar with SegWit version 2 will treat these outputs as "anyone-can-spend," but will typically not broadcast or mine such transactions.

Transaction size and fees

The output sizes of P2MR and P2TR are always the same. The input size of P2MR, relative to the input of P2TR, depends on whether it is the key path cost or the script path cost.

Comparison with P2TR key path cost

The witness for P2MR is greater than the witness for the key path cost of P2TR (which only contains a signature) because each P2MR cost is a script path cost, which requires a script, input stack, and control block.

Witness to a P2MR tree at depth 0 (103 bytes):

 [計數] (1 位元組)[大小] 簽名(65 位元組)葉腳本= [大小] [OP_PUSHBYTES_32, 32 位元組公鑰, OP_CHECKSIG] (35 位元組)控制區塊= [大小] [控制位元組] [Merkle 路徑（空）] (2 位元組)

P2TR Key Path Cost Witness (66 bytes):

 [計數] (1 位元組)[大小] 簽名(65 位元組)

Difference: P2MR has 37 more bytes.

In a multi-leaf Merkle tree of the same depth m: P2MR witness: 10³ + 32 m bytes longer than the P2TR key path: 37 + 32 m bytes longer.

Comparison with P2TR script path cost

The P2MR witness takes 32 fewer bits than the equivalent P2TR script path (because the internal public key is omitted in the control block).

Performance impact

P2MR verification is slightly more computationally efficient than P2TR script path verification because P2MR operations are a strict subset of P2TR script path operations.

Backward compatibility

Legacy wallets and nodes lacking SegWit version 2 support cannot recognize P2MR outputs. According to BIP 350, legacy wallets should be able to make payments to SegWit version 2 outputs. Users must ensure their wallets and nodes are updated to receive P2MR and verify related transactions.

P2MR is fully compatible with tapscript; existing tapscript programs can run in P2MR without modification. P2MR supports future scripts using new leaf versions.

Security

P2MR provides the same tapscript functionality as P2TR, but removes the quantum-fragile key path cost. This similarity allows script trees to be directly migrated from P2TR to P2MR for protection against long-term exposure to quantum attacks.

Public key exposure protection requires users to avoid reusing public keys and other insecure practices.

P2MR uses a 256-bit hash output (128-bit collision resistance, 256-bit image quality), consistent with the P2WSH safety level in BIP 141.

P2MR does not protect against short-term exposure to quantum attacks, but quantum signatures could mitigate this risk once they are enabled in the future.

Combined with post-quantum signatures, P2MR provides comprehensive quantum resistance, including protection against short-term exposure.

Long-term exposure protection should not be underestimated – early CRQC may lack the speed to launch short-term exposure attacks, making long-term exposure protection more urgent in terms of time.

Security considerations for post-quantum signature schemes

This proposal does not introduce post-quantum signatures, but it does involve related security considerations.

Quantum-resistant algorithms (ML-DSA, SLH-DSA) offer different levels of protection and require rigorous review before use. Research on Bitcoin's post-quantum signature proposals is ongoing.

Using multiple post-quantum signatures to achieve redundancy is conceivable, although balancing complexity with the benefits of signature type redundancy presents challenges.

Test vectors and reference code

Test vectors created by P2MR UTXO can be obtained from the BIP repository.

These vectors are built on top of the BIP 341 test vectors, with the main difference being that the P2MR test vectors exclude scenarios involving key path costs.

The Rust and Python implementations include test vectors. One of the tests demonstrates a tapscript (modeled using the Taproot script path paradigm) that requires a secp256k1 signature to spend a P2MR UTXO. Following the BIP 341 vector, all signatures use zero-valued (0x0000…0000) BIP 340 auxiliary random numbers.

Related work

Remove Taproot from key path

The article "OP_CAT Makes Bitcoin Quantum Resistant" points out that by disabling Taproot key path spending and enabling OP_CAT (BIP 347), quantum resistance can be achieved through Lamport signatures.

Lamport and WOTS, built on CAT, are quantum resistant, but they are one-time signatures—signing twice will leak the private key, causing a major security risk.

This requires significant changes to wallet behavior and represents a substantial security degradation. Practices such as RBF (Fee Alternative) and CPFP (Child Pays Parent) may expose private keys in the absence of a stateless signature scheme.

The discussion on "Simple Quantum-Resistant Signatures Using Clean Upgrade Paths" explored the removal of the key path via Taproot. Part of P2MR's design was inspired by these conversations.

Commitment-Disclosure Program

Commit-Reveal and a "post-quantum commitment/reveal Fawkescoin variant" have been proposed for cryptocurrencies that do not require public-key cryptography.

Tadge Dryja’s recent “Lifeboat” proposal provides quantum protection for Bitcoin transactions through a similar pre-commitment mechanism and is designed specifically for Bitcoin.

Other methods to address quantum fragility

Ethereum's solution: Vitalik Buterin's proposal involves a chain rollback via a hard fork after a quantum theft occurs, using STARKs based on BIP 32 seeds as authoritative keys.

Bitcoin applicability: Chain rollback is not feasible for Bitcoin and is likely not practically feasible.

STARKs (quantum-resistant) may be useful in proving external private key access, and are applicable to community choices such as the fragile coin destruction scheme proposed by Jameson Lopp et al. in QBIP.

Discussions on coin burning and supply shock mitigation are beyond the scope of this proposal. Some team members have proposed an alternative solution called "Hourglass" to address these issues, and research on it is ongoing.

in conclusion

P2MR takes a "better safe than sorry" approach to potential advancements in quantum computing, providing Bitcoin users with optional enhanced protection. This BIP does not comment on a quantum computing timeline, but rather offers flexible, non-intrusive options for users to choose based on their individual quantum risk assessment.

Discussions about quantum computing have been appearing in Bitcoin forums since at least 2012, indicating a clear demand from users for enhanced quantum security.

Translation based on BIP 360 v0.11.0 (2024-12-18). The original text can be found on GitHub .