BIP-360: Bitcoin's Quantum-Resistant Address Format Explained

Quantum computers capable of breaking elliptic-curve cryptography do not exist yet, but the timeline for their arrival keeps shrinking. In March 2026, a Google Quantum AI paper estimated that breaking Bitcoin's secp256k1 curve could require fewer than 500,000 physical qubits: a 20x reduction from the previous best estimate of roughly 9 million. BIP-360, formally titled Pay-to-Merkle-Root (P2MR), is Bitcoin's first concrete step toward quantum resistance. It introduces a new address format that eliminates the quantum-vulnerable spending path present in Taproot, laying the groundwork for post-quantum signature schemes to be plugged in later.

Why Bitcoin Needs Quantum-Resistant Addresses

Bitcoin's security rests on two cryptographic pillars: SHA-256 hashing and digital signatures over the secp256k1 elliptic curve. Quantum computers threaten these differently. Shor's algorithm can derive a private key from a public key in polynomial time, breaking ECDSA and Schnorr signatures entirely. Grover's algorithm provides only a quadratic speedup against hash functions, meaning SHA-256 would still require roughly 2¹²⁸ operations to brute-force: computationally infeasible even for quantum hardware.

The practical threat is signatures, not hashes. Any Bitcoin output where the public key is already visible on-chain is vulnerable to a long-exposure attack: an adversary with a sufficiently powerful quantum computer could derive the private key and steal the funds. Roughly 1.7 million BTC sit in legacy P2PK outputs where keys are exposed directly. Modern address types like P2PKH and P2WPKH hide the public key behind a hash until spending, but the key becomes visible in the mempool the moment a transaction is broadcast. This creates a short-exposure window that a future quantum adversary could exploit.

Long vs. short exposure: Long-exposure attacks target public keys that sit on-chain indefinitely (P2PK outputs, reused addresses). Short-exposure attacks target keys revealed during transaction broadcast. BIP-360 addresses the long-exposure case. Defending against short-exposure attacks requires post-quantum signature schemes, which are deferred to a future companion BIP.

What BIP-360 Actually Does

BIP-360 was authored by Hunter Beast (MARA), Ethan Heilman, and Isabel Foxen Duke. First proposed on the Delving Bitcoin forum in June 2024, it was merged into the official BIP repository on February 11, 2026 as a Draft. The proposal was originally called Pay-to-Quantum-Resistant-Hash (P2QRH) but was renamed to Pay-to-Merkle-Root (P2MR) as the design evolved.

P2MR defines a new output type using SegWit witness version 2. On mainnet, these addresses begin with the bc1z prefix, using bech32m encoding. The core innovation is simple but consequential: P2MR removes the key-path spend that Taproot introduced, committing only to a Merkle root of script leaves. No public key ever appears in the output, eliminating the long-exposure quantum attack vector entirely.

How P2MR Differs from Taproot

In P2TR (Taproot, witness version 1), the output commits to an internal public key tweaked by the script tree root. Spenders can use either the key-path (a single Schnorr signature against the tweaked key) or the script-path (revealing a leaf script and Merkle proof). The key-path is efficient and private, but it places a public key on-chain permanently.

P2MR drops the internal key. The 32-byte output program is the tagged hash of the script tree root itself (using the TapBranch tag defined in BIP 341). To spend, the witness must reveal one tapleaf script, provide the initial stack, and include a control block containing the Merkle path. The control block is shorter than Taproot's because it omits the 32-byte internal key: P2MR's control block is 1 + 32m bytes (where m is the tree depth), compared to 33 + 32m bytes for P2TR.

Consensus Logic

A Bitcoin Core implementation on regtest demonstrates that P2MR reuses BIP 341/342 tapscript execution and the Merkle path walk. Only the commitment check differs: the computed root is compared directly to the 32-byte program with no key tweak applied. Regtest measurements show a P2MR spend with a 2-leaf tree weighing 513 weight units (129 vbytes), compared to 545 weight units (137 vbytes) for an equivalent P2TR script-path spend: roughly 32 bytes lighter at most tree depths.

Address Type Comparison

Bitcoin has evolved through several address types, each with different security properties against quantum attacks.

Taproot's specific vulnerability: Taproot's key-path spend is its most common usage pattern because it is cheaper and more private than script-path spends. But it places a public key (the tweaked internal key) directly in the output script, making it a long-exposure target. BIP-360's P2MR eliminates this trade-off by making script-path the only option. See Bitcoin Taproot Quantum Vulnerability for a deeper analysis.

The Merkle Tree Construction

P2MR builds on the same Merkle tree construction that Taproot uses for its script path. Each leaf in the tree represents a spending condition: a script that must be satisfied to authorize the transaction. The tree is hashed using BIP 341's tagged hash scheme, where each node is computed as SHA256(SHA256("TapBranch") || SHA256("TapBranch") || left || right).

The key difference is what the tree root commits to. In Taproot, the root is tweaked into the internal public key to form the output. In P2MR, the root is the output. This means the output reveals nothing about the spending conditions or the number of leaves: a single-leaf tree and a 128-leaf tree produce identical 32-byte outputs.

What Goes in the Leaves

Today, P2MR leaves can contain any valid Bitcoin Script opcode that Tapscript supports. In practice, most leaves would use standard signature-checking opcodes like OP_CHECKSIG or OP_CHECKSIGADD. The critical design decision is that BIP-360 does not mandate which signature algorithm those opcodes verify. When a soft fork introduces post-quantum signature verification (using schemes like SLH-DSA, Falcon, or lattice-based alternatives), those new opcodes can be placed inside P2MR leaves without any changes to BIP-360 itself.

Post-Quantum Signature Schemes

BIP-360 builds the address infrastructure. The actual quantum resistance requires post-quantum signature algorithms that a future BIP will specify. Several candidates are under discussion in the Bitcoin development community.

The size difference is stark. Even the most compact post-quantum scheme (Falcon at 666 bytes) is over 10x larger than a Schnorr signature. SLH-DSA, the most conservative choice because it relies only on hash function security, produces signatures over 120x larger. These sizes directly impact block space consumption, fee rates, and transaction throughput. This is one reason BIP-360 separates the address format from the signature scheme: the Bitcoin community can adopt P2MR addresses now and defer the signature-size tradeoffs until quantum hardware actually threatens the network.

Why hash-based signatures matter: Hash-based signature schemes like SLH-DSA derive their security entirely from the collision resistance of hash functions, which Grover's algorithm weakens only quadratically. Lattice-based schemes are smaller but rely on newer hardness assumptions. For a protocol managing over $1 trillion in value, conservative cryptographic choices carry weight.

Backward Compatibility and Activation

BIP-360 is designed as a soft fork. Nodes that do not upgrade will treat P2MR outputs as “anyone-can-spend” under the SegWit versioning rules, just as they did with Taproot before activation. Existing UTXOs are not affected: P2MR is a new output type, not a modification to P2TR or earlier formats.

This means BIP-360 does not protect coins already sitting in vulnerable outputs. Holders of P2PK, address-reused P2PKH, or Taproot key-path outputs would need to actively migrate their funds to P2MR addresses. The scale of this migration is significant: research estimates suggest millions of BTC may need to move before quantum hardware becomes capable enough to threaten secp256k1.

BIP-361 and the Migration Debate

A companion proposal, BIP-361, authored by Jameson Lopp and others and published in April 2026, outlines a more aggressive migration timeline. It proposes eventually sunsetting legacy signature types and potentially freezing coins in quantum-vulnerable outputs that are not migrated before a deadline. This approach has generated significant controversy in the Bitcoin developer community, with critics arguing that freezing dormant coins violates Bitcoin's property rights guarantees.

BIP-360 itself takes no position on forced migration. It simply provides the destination format. Whether and how the community incentivizes or mandates migration remains an open governance question.

What Wallet Developers Need to Implement

For wallet developers preparing for BIP-360, the implementation work falls into several categories.

Address Generation

Wallets must support constructing witness version 2 outputs with bech32m encoding. The output program is the 32-byte tagged hash of the script tree root. Since P2MR reuses the BIP 341 TapTree construction, wallets already supporting Taproot script-path have most of the building blocks. The main change is omitting the internal key from the commitment.

Key Derivation

BIP-32 HD wallet derivation paths will need a new purpose field for P2MR addresses, similar to how BIP-86 defined purpose 86 for Taproot. Output descriptors will need to support the new address type so that wallets can import, export, and recover P2MR funds correctly.

Transaction Signing

P2MR spends require constructing the witness with the script, initial stack, and a control block that includes only the Merkle path (no internal key). Wallet developers should note that the PSBT format (BIP-174) will likely need extensions to carry P2MR-specific fields, particularly once post-quantum signature schemes add new signer requirements.

Hardware Wallet Considerations

Hardware wallets face additional challenges. Post-quantum signatures are substantially larger than ECDSA or Schnorr signatures, which affects memory constraints on signing devices. The secure elements in current hardware wallets were designed for 32-byte and 64-byte operations, not multi-kilobyte signatures. Manufacturers will need to plan firmware updates and potentially new hardware generations to support whichever post-quantum scheme Bitcoin adopts.

Timeline and Current Status

BIP-360 is a Draft proposal. Its merge into the BIP repository on February 11, 2026 means it met documentation standards for formal discussion: it does not signal endorsement or guarantee activation. The path from Draft to deployed consensus change is long and uncertain, as Bitcoin's soft fork activation history demonstrates.

• June 2024: initial proposal posted to Delving Bitcoin as P2QRH
• July 2025: v0.8.0 strips post-quantum signature algorithms, deferring them to a companion BIP
• February 2026: merged into the Bitcoin BIP repository as BIP-360 (P2MR)
• March 2026: BTQ Technologies deploys an implementation on their Bitcoin Quantum testnet (v0.3.0)
• April 2026: BIP-361 published, proposing an aggressive migration timeline
• July 2026: first Bitcoin Core regtest implementation with witness validation and test vectors

Activation would require broad agreement among developers, node operators, and miners. Given the contentious nature of the migration debate and the fact that the companion signature BIP has not been written yet, mainnet activation is unlikely before 2028 at the earliest.

Implications for Bitcoin Layer 2 Protocols

The quantum threat extends beyond Bitcoin's base layer. Any protocol that relies on secp256k1 signatures inherits the same vulnerability. FROST threshold signatures, used by protocols like Spark for cooperative signing between users and operators, are built on Schnorr signatures over secp256k1. A quantum computer capable of breaking individual Schnorr signatures would break FROST signatures equally.

For Spark's statechain model, this means the 2-of-2 multisig between users and operators would need to transition to a post-quantum threshold scheme. Research in this area is active but early: IBM's Hermine project, presented at Eurocrypt 2026, is a lattice-based threshold scheme designed to match FROST's feature set, but no deployed post-quantum threshold signature scheme currently provides all three of FROST's core properties (robustness, key aggregation, and deterministic nonces) simultaneously.

BIP-360's modular design helps here. Because P2MR separates the address commitment from the signature algorithm, Layer 2 protocols can begin migrating their on-chain anchoring outputs to P2MR now, and upgrade the off-chain signing component to a post-quantum scheme when one matures. This staged approach avoids forcing the entire ecosystem to upgrade atomically.

Open Questions and Risks

Signature Size and Fee Impact

Post-quantum signatures are 10x to 120x larger than Schnorr signatures. When they eventually land in P2MR leaves, transaction weights will increase substantially. This affects fee market dynamics and effective throughput. One approach under discussion is signature aggregation for post-quantum schemes, but this is an open research problem.

Algorithm Agility vs. Ossification

BIP-360 is deliberately algorithm-agnostic, but Bitcoin's ossification debate raises the question: will the network be able to deploy the companion signature BIP when it is ready? If consensus changes become harder to achieve over time, delaying the signature scheme could mean missing the window to activate it before quantum hardware arrives.

Migration Incentives

Even with P2MR available, users must actively move their funds. Lost coins, dormant addresses, and cold storage setups with complex access procedures create a long tail of unmigrated UTXOs. The community has not reached consensus on whether to let quantum-vulnerable coins remain indefinitely or impose deadlines, and this question may prove more contentious than the technical proposal itself.

What Comes Next

BIP-360 is step one in a multi-step process. The quantum resistance roadmap for Bitcoin looks roughly like this:

1. Adopt P2MR address format (BIP-360): provide the output structure
2. Specify post-quantum signature opcodes (future BIP): define which algorithms are valid in P2MR leaves
3. Activate both as a soft fork: enable P2MR spending on mainnet
4. Migration period: users move funds from legacy outputs to P2MR
5. Evaluate legacy output policy: decide whether to freeze, fee-penalize, or leave vulnerable outputs

For developers building on Bitcoin today, the practical action is to track BIP-360's progress and begin planning for larger witness sizes in fee estimation and transaction construction. Wallet developers can explore the Spark SDK documentation for an example of how Layer 2 protocols handle signature infrastructure, and monitor the Delving Bitcoin threads for specification updates. For a broader overview of how post-quantum cryptography intersects with Bitcoin, see our post-quantum cryptography analysis and the post-quantum cryptography glossary entry.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.