BIP 360 (Pay-to-Merkle-Root)

BIP-360 is a draft proposal for Pay-to-Merkle-Root (P2MR) - a new output type that operates with nearly the same functionality as P2TR but with the key path spend removed. The bech32m address commits only to the script tree merkle root; no public key is exposed at output creation.

That single change is what makes P2MR a partial quantum hardening. Where P2TR is always-exposed by construction (the bech32m address IS the tweaked pubkey), P2MR exposes nothing on chain until a script-path spend reveals a single leaf. Long-exposure quantum attacks - attacks on public keys sitting on chain for extended periods - have nothing to work with, as long as the keys inside the scripts are not reused or otherwise revealed.

Address format

P2MR uses SegWit version 2 with the bech32m prefix bc1z (vs bc1q for v0 and bc1p for v1). The output script is the SegWit version byte followed by the 32-byte tagged TapBranch merkle root of the script tree. Spends are script-path only: the witness reveals one tapleaf, its initial stack, and the control block (control byte + merkle path) - omitting the internal key that a P2TR control block would carry.

Long-exposure vs short-exposure attacks

BIP-360 distinguishes carefully between two attack classes:

• Long-exposure attacks target public keys that sit on chain for extended periods (anything longer than the mempool window a spend needs to confirm). P2MR addresses these for tapscript outputs by removing the always-exposed key path.
• Short-exposure attacks target public keys revealed in the mempool during the few minutes between transaction broadcast and confirmation. P2MR does NOT address these. A full short-exposure fix may require post-quantum signature schemes, which the authors leave to a separate proposal.

This is the conservative-first-step framing. P2MR offers an exit from the most concrete quantum risk - long exposure, which already applies to Satoshi-era P2PK keys, reused-address keys, and P2TR keys - for anyone who moves coins into it, without committing the protocol to any specific post-quantum signature scheme. It does nothing for keys that stay where they are.

Why a new output type instead of using P2WSH

P2WSH is already long-exposure-resistant for similar reasons (the witness script is hashed and not revealed until spend). The reason for P2MR is tapscript. P2WSH does not support tapscript and therefore cannot benefit from the OP_SUCCESSx opcode-upgrade path that the BIP calls critical for adding post-quantum OP_CHECKSIG variants if and when PQ signatures arrive. P2MR is the unique combination: long-exposure resistance plus the tapscript machinery a future PQ signature opcode would need.

Relationship to BIP-361

BIP-361 defines the migration schedule that would sunset existing ECDSA and Schnorr spends over a multi-year window. BIP-361 assumes a quantum-resistant output type exists as the migration destination; BIP-360's P2MR is one candidate. Neither BIP mentions the other. BIP-361 lists a post-quantum signature BIP as its requirement, which P2MR is not; P2MR is the tapscript platform such a signature opcode could plug into, and it is not the only output design under discussion. BIP-360 can ship on its own as an opt-in hardening for users who want long-exposure protection.

Status

Draft. Not activated, not scheduled, not consensus. Assigned its number on December 18, 2024, when it was still called P2QRH; the key-path-free design dates from July 2025 and the P2MR name from February 2026. Authored by Hunter Beast (Surmount), Ethan Heilman, and Isabel Foxen Duke.

Builds on the Taproot stack: BIP-360 requires BIPs 340 (Schnorr), 341 (Taproot), and 342 (Tapscript).

See the Quantum and Bitcoin rabbit hole for the always-exposed problem P2MR is designed to address.

Spec: BIP-360.

See How Taproot Actually Works for the Taproot construction that P2MR keeps and the key path it removes.