SignorCrypto note · CRYPTO
Bitcoin BIP-360 Explained: What P2MR Does—and Doesn't
The draft removes Taproot’s key path to limit long-exposure quantum risk, but adds no post-quantum signature.
As of 20 October 2026, BIP-360 is marked Draft: it is a proposal, not an activated Bitcoin consensus change. The proposal introduces Pay-to-Merkle-Root (P2MR), a SegWit version 2 output that commits to a script-tree Merkle root and removes Taproot’s key-path spend. That can reduce one long-exposure quantum risk tied to Taproot’s exposed output key. It does not add a post-quantum signature, protect every exposed public key, or stop attacks on a transaction while it waits in the mempool.
What does BIP-360 propose?
A Bitcoin output locks coins to spending conditions. Taproot (P2TR) commits to an output public key and lets a spender use either a key path or a script path. P2MR keeps Taproot’s script-tree approach but commits directly to the tree’s Merkle root instead of tweaking an internal key. The key path is removed, so a P2MR spend uses a script leaf and its Merkle proof. BIP-360 proposes this as a soft fork; BIP-341 specifies the Taproot design it builds on.
| Property | P2TR (Taproot) | Proposed P2MR |
|---|---|---|
| Witness version | 1 | 2 |
| Witness program | Tweaked output public key | 32-byte script-tree Merkle root |
| Spending route | Key path or script path | Script path only; no key path |
| Main trade-off | Compact key-path spend when available | Script, stack and Merkle proof are needed for each spend |
BIP-360 assigns P2MR mainnet addresses the bc1z prefix. That is a proposed SegWit v2/Bech32m format—not evidence that current wallets or nodes support spending it. BIP-350 describes Bech32m for witness versions 1 and higher.
Which quantum risk does P2MR address?
The proposal distinguishes long-exposure from short-exposure attacks. A long-exposure attack would use public-key information exposed on-chain for an extended period. A short-exposure attack would have to recover a key while a transaction is still unconfirmed in the mempool, leaving a much shorter window.
P2MR removes the Taproot key path and its output-key commitment. In the proposal’s threat model, that can reduce long-exposure risk for a script tree whose spending conditions do not otherwise expose a vulnerable public key. But P2MR is not blanket protection: a script can reveal a public key when spent, and key reuse, extended public keys or wallet descriptors can expose key material. The BIP explicitly says that P2MR alone does not protect against short-exposure attacks.
P2MR does not add a post-quantum signature
Removing a key path changes the output structure; it does not replace Bitcoin’s signature algorithms. If a P2MR script uses the existing tapscript OP_CHECKSIG path, it still relies on Schnorr signatures over secp256k1, as described by BIP-342. The proposal does not add a post-quantum signature opcode or make an existing signature quantum-resistant.
NIST has finalized post-quantum signature standards including ML-DSA in FIPS 204 and SLH-DSA in FIPS 205. Their publication does not integrate either algorithm into Bitcoin: that would require separate protocol and consensus work. BIP-360 presents P2MR as a possible script-tree foundation for future upgrades, not as a complete quantum migration.
What are the costs and implementation caveats?
P2MR gives up Taproot’s compact key-path spend. In BIP-360’s depth-one example, the P2MR witness is 135 bytes, compared with 66 bytes for a P2TR key-path witness—69 bytes more. An equivalent P2MR script-path witness is generally 32 bytes smaller than P2TR’s script-path witness because its control block omits the internal public key. These are witness-size comparisons, not a promise that every P2MR transaction will cost more or less in fees.
The draft also treats a depth-zero script tree as anyone-can-spend, so its authors discourage that construction. Wallets, nodes and other tools would need explicit support for the proposed witness version before users could safely create and spend P2MR outputs.
How does this fit with other post-quantum work?
The scope matters. Our Ethereum post-quantum roadmap guide covers a different chain and its separate account, consensus and data-layer questions. Our PQLN explainer describes research on selected Lightning off-chain surfaces, not a Bitcoin base-layer change. P2MR is narrower still: a draft Bitcoin output design aimed at a particular long-exposure risk.
Frequently asked questions
Is BIP-360 active on Bitcoin?
No. The BIP identifies itself as Draft. Its proposed bc1z address format should not be treated as a currently supported payment address just because it appears in the specification.
Does P2MR make Bitcoin quantum-proof?
No. The proposal targets a specific long-exposure risk by removing Taproot’s key path. It does not add a post-quantum signature and does not protect against short-exposure attacks or every case where public keys are exposed.
Does BIP-360 include ML-DSA or SLH-DSA?
No. Those are NIST-standardized signature schemes, but BIP-360 does not integrate them into Bitcoin. Any such integration would need separate protocol work and review.
Sources
- BIP-360: Pay-to-Merkle-Root (P2MR) — proposal, status, security scope and witness trade-offs.
- BIP-341: Taproot — existing P2TR output and spending design.
- BIP-342: Validation of Taproot Scripts — tapscript validation rules.
- BIP-350: Bech32m — witness address encoding.
- NIST FIPS 204: ML-DSA and FIPS 205: SLH-DSA — post-quantum signature standards.
For a team assessing a Bitcoin integration or cryptographic migration, contact SignorCrypto to map protocol architecture, wallet compatibility and implementation constraints before a build.