What is BIP-360?

BIP-360 is the Bitcoin proposal most often mentioned when quantum computers come up, and most often described wrongly. It is not a post-quantum signature scheme. It is a new output type that takes Taproot and removes the one part of it that leaves a public key sitting on the chain. This article explains what it does, what it deliberately leaves out, and what it means for your coins.

The problem it is trying to solve

If you have read our first article, you know the rule: a quantum computer running Shor's algorithm could derive a private key from a public key, but not from a hash of one. Coins on an address whose public key is hidden behind a hash are safe while they sit still. Coins on an address whose key is visible on-chain are not.

Most Bitcoin address types hide the key until the first spend. Taproot, the newest and in most other respects the best output type, does not. A Taproot output is a public key: a 32-byte key, tweaked with the hash of an optional tree of scripts, written directly into the output. That design is what gives Taproot its elegance. Spending by the “key path”, a single Schnorr signature against that key, is cheap, private, and indistinguishable from any other Taproot spend.

It also means that every Taproot output holding coins has its public key exposed from the moment it is funded, whether it has ever spent or not. The BIP calls this a long exposure vulnerability, and as Taproot adoption grows, so does the share of bitcoin in that position.

BIP-360 exists to give Bitcoin an output type with everything Taproot can do except that.

What P2MR actually is

Pay-to-Merkle-Root is best understood as Taproot with one thing deleted.

A Taproot output commits to two things at once: an internal public key, and the Merkle root of a tree of scripts. You can spend it either by signing with the key (the key path) or by revealing one of the scripts and satisfying it (the script path). A P2MR output commits only to the Merkle root of the script tree. There is no internal key, so there is no key path. The only way to spend is to reveal a leaf script, prove with a Merkle path that it belongs to the tree, and satisfy it.

In concrete terms:

• It is native SegWit version 2. Taproot is version 1. On mainnet the addresses are encoded with Bech32m and begin with bc1z.
• The output script is simply the version number followed by the 32-byte Merkle root.
• Spending always supplies a witness with the script, its inputs, and a control block containing the Merkle path. The control block is 32 bytes shorter than Taproot's, because there is no internal key to include.
• Script validation reuses Taproot's script language, tapscript, unchanged. The BIP requires BIPs 340, 341 and 342 and describes P2MR validation as a strict subset of Taproot's.
• A tree of depth zero, a single script with no siblings, is defined as anyone-can-spend, to discourage using the format as a bare script commitment.

Because older nodes do not know version 2, they treat these outputs as anyone-can-spend, which is the standard mechanism that lets a new output type arrive as a soft fork: upgraded nodes enforce the new rules, old nodes see nothing invalid. No hard fork is involved.

The proposal has changed names along the way. It began in 2024 as “Pay to Quantum Resistant Hash” (P2QRH), with a more ambitious design that bundled post-quantum signature schemes into the output type. The current version, by Hunter Beast, Ethan Heilman and Isabel Foxen Duke, has been cut down to the minimal change described above. If you read an older summary that talks about P2QRH and lists specific signature algorithms, it describes a version that no longer exists.

What it deliberately does not do

This is the part that is most often misreported, so it is worth being blunt.

It does not add post-quantum signatures

The BIP says so in as many words: the proposal “does not include the introduction of post-quantum signature schemes”. The scripts inside a P2MR tree are ordinary tapscript today, which means ordinary Schnorr signatures. Standardised post-quantum schemes such as ML-DSA and SLH-DSA are discussed as future candidates that could be added as new script features later, but nothing in BIP-360 commits to any of them.

What P2MR gives you is a container in which such signatures could one day live, and in which, until then, the public key stays off the chain while the coins are at rest.

It does not protect a transaction in flight

When you spend a P2MR output, the script you reveal contains a public key and your witness contains a signature against it. From the moment the transaction is broadcast until it is buried in the chain, that key is visible, exactly as with any other address type. An attacker with a quantum computer fast enough to derive a key in minutes could try to front-run the spend. The BIP calls this the short exposure attack and states plainly that P2MR provides no protection against it. Only a post-quantum signature scheme can, and that is a separate proposal.

The authors' argument for accepting this gap is that early quantum machines, if they arrive, are far more likely to be slow than fast. A key that has been public for years is a much easier target than one that appears for ten minutes. That makes protection against long exposure the time-critical part, and it is the part P2MR addresses.

It does not migrate or protect any existing coin

BIP-360 creates a new place to put coins. It does nothing to coins that are already exposed. Every Taproot output, every reused address, every early pay-to-public-key output stays exactly as vulnerable as it is today. Moving to safety is a transaction that each owner has to make, and coins whose owners are gone will never move.

It does not retire ECDSA or Schnorr

Taproot and every older output type remain valid. Nothing in BIP-360 stops anyone from sending to, or spending from, a quantum-vulnerable address. That question, whether and when to restrict the old signature schemes, belongs to a different proposal, covered below.

Why remove the key path instead of adding new cryptography

A reasonable reaction to all this is: why go to the trouble of a soft fork for a change this small? Why not add post-quantum signatures straight away?

The BIP gives three intentions, and they are worth taking seriously.

1. Change as little as possible. P2MR reuses Taproot's validation code almost line for line. The smaller and more familiar a consensus change is, the easier it is to review, and review is the bottleneck for anything that touches Bitcoin's rules.
2. Build the safest path for post-quantum signatures to arrive later. The candidate schemes are still young by cryptographic standards, and their signatures are large: kilobytes where a Schnorr signature is 64 bytes. Committing the whole network to one of them today, inside the same proposal that fixes the Taproot key path, would tie a simple and urgent change to a complex and unsettled one. Separating them lets the simple one move first.
3. Make quantum resistance iterative. Once P2MR exists, new signature schemes can be introduced as new script features, tried in the wild, and superseded if something better appears, without another new output type each time.

The trade-off is cost. A P2MR spend always reveals a script, so its witness is always larger than a Taproot key-path spend: for the simplest tree, about 69 bytes more. Against a Taproot script-path spend it is actually 32 bytes smaller. For most users that difference is a fraction of a cent at ordinary fee levels, but it is real, and the BIP does not hide it.

Where BIP-361 fits

If BIP-360 is the new room, BIP-361 is the proposal for eventually closing the old ones. Titled Post Quantum Migration and Legacy Signature Sunset and authored by Jameson Lopp and others, it is an informational draft from early 2026 that lays out a two-phase soft fork:

• Phase A, lasting roughly three years, would prohibit sending coins to quantum-vulnerable output types, so that the exposed set stops growing.
• Phase B, some years later, would restrict spending from them, so that a quantum attacker could not drain old outputs, while giving legitimate owners a recovery route based on knowledge an attacker would not have, such as proofs derived from a wallet's seed.

Two things about BIP-361 matter here. First, it explicitly assumes that a post-quantum output type already exists: it “follows the implementation of any post-quantum output type” and separately requires a post-quantum signature BIP. It cannot go first. Second, it puts a number on the problem: as of March 2026, over 34% of all bitcoin has a public key revealed on-chain. That is the population a migration would have to move, and it is why the migration, not the cryptography, is the part everyone expects to be slow and contentious.

BIP-361 is far more controversial than BIP-360, because it is the one that would eventually stop old coins from being spent in the old way. Expect the debate over it to run for years.

What this means for your coins today

Practically, nothing changes yet, and it is important not to let the discussion make it feel otherwise.

• You cannot use a bc1z address today. The proposal is a draft. No wallet will offer one, and no node will enforce the rules, until the soft fork is activated. If a product tells you it can already put your coins in a BIP-360 address, be careful.
• The protection you can have today is the one that has always existed: a hashed address of an ordinary type that has never spent. Keeping coins at rest on fresh bc1q addresses gives you, today, the same protection against long exposure that P2MR is designed to give tomorrow. The scanner on the front page tells you which of your coins already have it and which do not.
• When activation comes, migration will be one transaction per owner, competing for block space with everyone else doing the same. People who already know which of their outputs need moving will be the ones who move calmly.

On the timeline, honestly

There is no activation date, and anyone who gives you one is guessing. For scale: Taproot was first proposed in 2018 and activated in November 2021, and it was a comparatively uncontroversial upgrade. BIP-360 is small and has broad sympathy; BIP-361 is neither. A sensible expectation is that a new output type can arrive within a few years and that the sunset of old signatures, if it happens at all, is much further out.

What is knowable now is your own exposure. That part is arithmetic over public data, and it is worth doing before it matters.