BIP 360, an updated Bitcoin improvement proposal, lays out a soft-fork path for a new output type called P2MR (Pay-to-Merkle-Root). The proposal targets the part of Taproot seen as most exposed to future quantum attacks: the key-path spend that relies on elliptic curve cryptography, or ECC. P2MR removes that path and keeps only the script-tree route.
The proposal is authored by Hunter Beast, Ethan Heilman, and Isabel Foxen Duke. It does not try to turn Bitcoin into a fully post-quantum system in one move. The design is framed as a limited change that adds an optional layer of protection without forcing all users to migrate, while keeping room for later integration of post-quantum signatures.
Removing the key path while preserving Taproot script functionality
Taproot, or P2TR, supports two spending paths. One of them, the key path, depends on ECC and is the portion that could in theory be broken by a cryptographically relevant quantum computer using Shor’s algorithm. BIP 360 focuses on what it calls long-exposure attacks, where an attacker has extended time to work against public keys or spent scripts already revealed on-chain.
P2MR is built to resemble P2TR, but instead of committing to an internal key, it commits directly to the script tree’s Merkle root. The proposal is explicit about its scope. P2MR is meant to defend against long-exposure attacks only. Protection against short-exposure attacks, such as those during the mempool window before confirmation, may still require future post-quantum signature systems like ML-DSA or SLH-DSA.
SegWit v2 format and bc1z addresses
Under the draft specification, P2MR is a native SegWit output using version 2 with a 32-byte witness program. On mainnet, addresses would begin with bc1z. The ScriptPubKey format is defined as OP_2 OP_PUSHBYTES_32 <hash>, where the hash is the 32-byte Merkle root of the script tree.
The proposal also keeps full compatibility with existing tapscript. Current tapscript programs can work inside P2MR without modification. That is central to the design: reuse as much of the existing P2TR, tapleaf, and tapscript machinery as possible so the implementation burden for wallets, exchanges, and libraries stays lower.
Trade-offs on size and privacy
The proposal spells out the costs. Because every P2MR spend uses the script path, its witness is larger than a P2TR key-path spend. The draft gives a concrete comparison: a P2MR depth-0 tree witness is 103 bytes, while a P2TR key-path spend witness is 66 bytes, a difference of 37 bytes. Against an equivalent P2TR script-path spend, though, P2MR is 32 bytes smaller because the control block omits the internal public key.
There is a privacy trade-off as well. Spending from P2MR reveals that the user is using a script tree, unlike a Taproot key-path spend that can stay hidden. The proposal still argues that P2MR offers privacy comparable to P2TR script-path spends, and better privacy than P2SH, which reveals unused script branches.
A framework first, not a full post-quantum migration
BIP 360 does not introduce post-quantum signatures and does not claim a timeline for quantum computing. Its role is narrower: remove Taproot’s quantum-exposed key path with a minimal protocol change and give developers and users an optional output type aimed at stronger long-term defense.
The proposal adds that older wallets and nodes without SegWit v2 support will not recognize P2MR outputs. Users would need updated wallet and node software to receive and validate related transactions. The translated text cited in the source notes that it is based on BIP 360 v0.11.0 (2024-12-18).