Hadamard Get the app

BIP-360 P2MR Explained: Bitcoin’s bc1z Address and Its Quantum Limits

BIP-360 P2MR Explained: Bitcoin's bc1z Address and Its Quantum Limits — Hadamard

BIP-360 P2MR (Pay-to-Merkle-Root) is a draft Bitcoin soft fork. It adds a new output type, with addresses starting in bc1z, that works like Taproot but drops the key path spend, so an unspent output no longer has a public key sitting on-chain. It protects coins at rest against long-exposure quantum attacks. It does not protect against short-exposure attacks during the mempool window, and it is not active on Bitcoin.

The proposal was merged into the Bitcoin BIP repository in February 2026, and headlines followed saying Bitcoin had “added a quantum-resistant address.” This article covers what the specification actually says, how P2MR differs from Taproot, what it costs in fees, and where it sits next to the migration plan in BIP-361.

What is BIP-360 P2MR?

The BIP-360 specification is titled “Pay-to-Merkle-Root (P2MR)”. It is a consensus-layer soft fork of type Specification, currently at version 0.12.1 with status Draft, licensed BSD-3-Clause. It builds on BIPs 340, 341 and 342 (Schnorr signatures, Taproot and Tapscript). The authors are Hunter Beast, Ethan Heilman and Isabel Foxen Duke.

The stated goal is to provide script trees and tapscript that resist long-exposure quantum attacks, and also any future cryptanalysis of elliptic curve cryptography. The motivation is Shor’s algorithm: a cryptographically relevant quantum computer (CRQC) could derive private keys from exposed public keys. The spec points to the CNSA 2.0 and NIST IR 8547 migration timelines.

The authors call P2MR a “conservative first step”. It goes after long-exposure attacks because those are likely to become feasible first. The spec also argues that user worry alone could affect confidence in Bitcoin, even if the quantum threat never materializes.

From P2QRH to P2MR: how the proposal reached the BIP repository

Many readers will know the proposal by its earlier name, P2QRH. It now goes by Pay-to-Merkle-Root. The pull request “BIP 360 – Pay to Merkle Root (P2MR)” (bitcoin/bips #1670) was opened on 2024-09-27. The number 360 was assigned on 2024-12-18, and murchandamus merged the PR on 2026-02-11.

Merging is not endorsement. As Bitcoin Magazine noted, a merged BIP is neither approved nor scheduled for activation. BIPs are merged so that they can be documented and discussed. Hunter Beast described “the introduction of BIP 360 and P2MR” as “a first step” toward quantum-hardening Bitcoin. Isabel Foxen Duke said the team “aimed to ensure the BIP was written in a manner that was clear and understandable” to the general public.

A Cointelegraph feature described the merge as something that “formally puts quantum resistance on Bitcoin’s road map for the first time.” Being on the road map is not the same as being scheduled.

How P2MR works: Taproot without the key path

A Taproot (P2TR) output commits to a tweaked public key. You can spend it with a single signature for that key (the key path) or by revealing one script from a committed tree (the script path). The key path is cheap and private, but the output itself is effectively a public key, and that key is visible on-chain for as long as the coins stay unspent.

P2MR keeps the script tree and removes the key. Its 32-byte witness program is the Merkle root of the script tree, computed with the same BIP 341 TapBranch/TapLeaf hashing, but there is no internal key and no tap tweak. The details from the spec:

  • Encoding: SegWit version 2. The scriptPubKey is OP_2 OP_PUSHBYTES_32 <hash>.
  • Addresses: on mainnet they would start with bc1z and use Bech32m (BIP 173/350).
  • Spending: script path only. The control block is 1 + 32·m bytes, with m from 0 to 128. It leaves out the internal public key that P2TR includes, and the parity bit of the control byte must be 1.
  • Execution: leaves run under BIP 342 tapscript rules, and the signature message construction is unchanged from BIP 342.
  • Upgrade hook: leaf versions other than 0xC0 succeed, which keeps them available for later upgrades.

This keeps the change small for wallet developers. The spec says existing tapscripts can mostly be reused unchanged. Cointelegraph notes that multisig, timelocks and inheritance schemes keep working through Tapscript trees.

P2TR (Taproot) P2MR (BIP-360)
SegWit version 1 2
Mainnet prefix bc1p bc1z
Witness program Tweaked public key Merkle root of script tree
Key path spend Yes No
Internal key in control block Yes No
Output size Same
Status on Bitcoin mainnet Active Draft, no activation plan

Long-exposure vs short-exposure attacks: what P2MR fixes and what it leaves open

A long-exposure attack targets a public key that has been visible for a long time, for example an old output that commits directly to a key. An attacker can work on that key for as long as it takes. P2MR outputs are 256-bit hashes, which gives 128-bit collision resistance and 256-bit preimage resistance, the same as P2WSH. An unspent P2MR output reveals no public key to attack.

A short-exposure attack happens while a transaction is being spent. Spending a P2MR output reveals the leaf script, and that usually includes a public key and an elliptic-curve signature. A quantum computer fast enough to recover the private key while the transaction waits in the mempool could interfere with the spend. The spec says plainly that P2MR does not protect against this. That would need post-quantum signatures in a separate proposal.

P2MR also has limits of its own:

  • Funds can become vulnerable again if a script reveals a public key or if keys are reused.
  • Existing UTXOs are not upgraded automatically. They stay vulnerable until their owners move them, as Cointelegraph points out.
  • Coins that never move, including lost or dormant coins, gain nothing from a new output type. Hunter Beast told Bitcoin Magazine that the team is looking at ways to handle vulnerable coins that are unlikely to move.

To see which of today’s output types expose keys, read our breakdown of which Bitcoin addresses are vulnerable to quantum computers.

Does P2MR cost more than Taproot? Witness size and fees

The outputs are the same size as P2TR outputs. The difference shows up when you spend. Compared with a Taproot key-path spend (one signature), every P2MR spend has to reveal a script and a control block:

  • A depth-1 P2MR witness is 135 bytes. A P2TR key-path witness is 66 bytes, so P2MR uses 69 bytes more.
  • In general, a P2MR witness is 37 + 32·m bytes larger than a P2TR key-path witness.
  • Compared with a P2TR script-path spend of the same tree, P2MR is 32 bytes smaller (34 bytes smaller at m = 7), because it does not carry the internal key.

An independent regtest implementation posted on Delving Bitcoin measured transactions with one input, one P2TR output and a single-key OP_CHECKSIG leaf:

Spend type vsize Weight
P2MR, 2-leaf tree 129 vB 513
P2MR, 4-leaf tree 137 vB 545
P2TR script path, 2-leaf tree 137 vB 545

In practice, users who rely on cheap Taproot key-path spends would pay somewhat more. Users who already spend through script paths would pay slightly less. According to the spec, privacy is roughly similar to P2TR, and both reveal less than P2SH.

Where post-quantum signatures fit: ML-DSA, SLH-DSA and the rejected OP_CAT route

BIP-360 does not add any post-quantum signature scheme. Its leaves still check Schnorr signatures under tapscript. The spec names ML-DSA and SLH-DSA as candidates for a future proposal, and bip360.org says the authors plan later proposals for post-quantum signature schemes to deal with short-exposure attacks. The open leaf versions give those future schemes a place to go without another new output type.

The spec also explains why it did not take an earlier route: disable the key path and use OP_CAT-based Lamport or Winternitz (WOTS) one-time signatures. One-time signatures leak key material if the same key signs twice. Fee-bumping with RBF or CPFP can lead to exactly that kind of reuse, so the spec calls this approach a “significant security downgrade”.

Is BIP-360 live? Bitcoin Core regtest work and BTQ’s testnet fork

BIP-360 is not live on Bitcoin, and it has no activation plan. On backward compatibility, the spec says non-upgraded nodes see SegWit v2 outputs as anyone-can-spend but generally do not relay or mine them. Old wallets that follow BIP 350 can send to v2 addresses, but receiving and validating P2MR needs updated software.

Independent Bitcoin Core regtest implementation

In July 2026 a developer posting as jeanpablojp, who says they are not affiliated with the BIP authors, published a P2MR implementation in Bitcoin Core on regtest. The branch, p2mr-regtest, is pinned to spec commit 0fdf6ff (2026-07-24). The changes are small: about 96 lines of consensus code, 33 lines of policy and flags, and 59 lines of address recognition, plus about 540 lines of unit tests and a 492-line functional test.

The work found bugs in the spec’s test vectors. The fixes were merged as bitcoin/bips#2220, and all 16 construction vectors now pass. Spend-path vectors were submitted as #2232. This is regtest-only and does not mean Bitcoin Core has adopted the proposal.

BTQ’s “Bitcoin Quantum” testnet

BTQ Technologies announced its “Bitcoin Quantum” testnet v0.3.0, a separate fork that is not Bitcoin. BTQ calls it the first working implementation of BIP-360, and it pairs P2MR with ML-DSA (Dilithium) signatures. Those are the company’s own claims. BTQ’s release itself says BIP-360 “remains a draft proposal” in the wider Bitcoin ecosystem.

How BIP-360 relates to BIP-361, and what to do now

The two proposals handle different parts of the problem. BIP-360 creates a destination: an output type whose coins at rest do not expose a public key. BIP-361 is the migration plan that would phase out ECDSA and Schnorr spends over time, and it assumes a destination like P2MR exists. Our explainer on BIP-361 and the plan to sunset quantum-vulnerable coins covers that side in detail.

Practical steps, given that nothing is activated:

  • Holders: no bc1z address exists on mainnet, so there is nothing to migrate to yet. Treat any service offering “Bitcoin P2MR addresses” with caution, because these exist only on test networks and forks. Avoiding address reuse limits how many of your public keys are exposed.
  • Wallet developers: read the spec and its test vectors, and try the regtest branch. Most tapscript logic carries over, but address handling (SegWit v2, Bech32m, bc1z) and control-block construction without an internal key are new.
  • Custodians and exchanges: list which holdings sit behind exposed public keys, and plan for the higher spend cost of P2MR compared with Taproot key-path spends if it is ever activated.

The idea behind P2MR, committing to a hash and revealing nothing about keys until spend time, is also the basis of Hadamard’s own work. BB84 is a hash-based, ECDSA-free Layer 2 rollup on Ethereum in which accounts are one-time addresses built on hash commitments rather than ECDSA keys. You can follow how other chains and standards are progressing on our post-quantum migration tracker.

FAQ

Is BIP-360 active on Bitcoin, and can I get a bc1z address today?

No. BIP-360 is a Draft BIP that was merged into the repository for discussion on 2026-02-11, and it has no activation plan. bc1z outputs exist only on test networks and forks.

Does moving my BTC to a P2MR address make it fully quantum-safe?

No. P2MR protects against long-exposure attacks only. Short-exposure attacks during the mempool window would need future post-quantum signatures, and coins in old outputs stay exposed until they are moved.

Will P2MR transactions cost more than Taproot?

Compared with a Taproot key-path spend, yes: the witness is at least 69 bytes larger at depth 1. Compared with a Taproot script-path spend of the same tree, a P2MR spend is 32 bytes smaller.

How is BIP-360 different from BIP-361?

BIP-360 creates the new output type. BIP-361 is the migration plan that would phase out ECDSA and Schnorr spends, and it assumes a destination like P2MR exists.

Sources