After reading the NIST post-quantum standards, FIPS 204 and FIPS 205, I started looking for chain-specific migration efforts. Bitcoin is a natural starting point: it has the most valuable UTXO set, the most value secured by classical signatures, and a long history of conservative script upgrades.

The two draft proposals that caught my attention are BIP360 and BIP361. BIP361 is the broader migration plan: after a future post-quantum output type exists, it proposes a staged sunset for legacy ECDSA/Schnorr usage. BIP360 is the more interesting technical step. It proposes Pay-to-Merkle-Root, or P2MR, a new output type that keeps the useful parts of Taproot script trees while removing Taproot’s key path.

Why does that matter? Because quantum risk is mostly about exposed public keys.

From P2PK to P2TR

Bitcoin’s output history can be read as a long migration toward revealing less information earlier:

1

P2PK -> P2PKH -> P2SH/P2WSH -> MAST -> P2TR

With P2PK, coins are paid directly to a public key:

1
2

lock = public_key
spend = valid_signature(public_key)

This is simple, but bad from a post-quantum perspective. The public key is visible as soon as the UTXO is created. If a cryptographically relevant quantum computer can derive private keys from public keys, P2PK gives the attacker a long time window.

P2PKH improved this by paying to a hash of the public key:

1
2

lock = hash(public_key)
spend = public_key + valid_signature(public_key)

The public key is only revealed when the coin is spent. This does not solve short-exposure attacks, where an attacker targets a transaction while it is waiting in the mempool, but it does reduce long-exposure risk for coins whose public keys have never been revealed.

P2SH and P2WSH generalized the same idea from keys to scripts: commit to a script hash now, reveal the script later. This supports more complex policies, but the full script is still revealed when spending.

1
2

lock = hash(script)
spend = script + data_that_satisfies(script)

MAST improves that model by putting possible spending conditions into a Merkle tree. The chain only sees the branch that is actually used. Unused branches remain hidden.

1
2
3
4
5
6
7

              Merkle root
             /           \
       hash(path A)    hash(path B)
          /                \
   "Alice signs"      "Alice + Bob sign"

spend reveals only the branch used + Merkle proof

Taproot, or P2TR, packages this nicely. The elegant part is that the public key can be tweaked by a commitment to the Merkle root. Thanks to Schnorr’s linear structure, that tweaked key can still be spent like a normal public key, while the hidden script tree remains available as a fallback.

So a P2TR output has two possible paths:

  • a key path, where the spend looks like a single Schnorr signature;
  • a script path, where only one script branch is revealed.

This is excellent for privacy and efficiency in the normal case. But the output itself commits to an x-only public key:

1
2
3
4

P2TR output = public_key

spend option 1 = signature(public_key)
spend option 2 = script_branch + Merkle proof

That means every P2TR output exposes an ECC public key from the moment it is created. In a post-quantum framing, Taproot’s biggest feature, the key path, is also the uncomfortable part.

What BIP360 Proposes

BIP360 proposes P2MR, or Pay-to-Merkle-Root. Conceptually, it is Taproot without the key path.

Instead of committing to a tweaked public key, a P2MR output commits directly to the Merkle root of a tapscript tree:

1
2
3

P2MR output = Merkle root

spend = script_branch + Merkle proof + data_that_satisfies(script)

The address format would use SegWit version 2, so mainnet addresses start with bc1z.

Spending is always script-path spending. The spending transaction provides:

  • the stack items needed by the script;
  • the leaf script;
  • a Merkle proof showing that this leaf belongs to the committed tree.

There is no Taproot internal key, no key-path spend, and no public key sitting in the output just waiting to be attacked.

The design goal is narrow but useful: protect against long-exposure attacks. It does not claim to solve all quantum risk. Most Bitcoin spends still reveal public keys when they are spent, so short-exposure attacks may require actual post-quantum signature opcodes in the future.

Still, P2MR gives Bitcoin a practical intermediate step: keep tapscript, keep script trees, remove the exposed Taproot key.

Tradeoffs

P2MR is not strictly better than P2TR. It trades efficiency and some privacy for reduced long-exposure risk.

Compared with a P2TR key-path spend, P2MR is larger because it must reveal a script and a Merkle proof. Compared with an equivalent P2TR script-path spend, P2MR is slightly smaller because it does not need to reveal Taproot’s internal key.

There is also a privacy tradeoff. A P2TR key-path spend hides whether a script tree existed at all. A P2MR spend always reveals that the coin was spent through a script tree. But unused branches are still hidden, so it keeps the main privacy benefit of MAST-style construction.

The migration path is also straightforward for simple wallets: a Taproot key-path spend can be represented as a single script branch like:

1

script_branch = "this public key must sign"

That is less compact than Taproot’s key path, but it avoids exposing the public key in the output itself.

Summary

BIP360 is not a full post-quantum Bitcoin design. It is more like a bridge.

It says: before Bitcoin has post-quantum signatures, we can at least stop creating new Taproot outputs that expose ECC public keys for long periods of time.

The historical direction is consistent:

1
2
3
4
5
6

P2PK:  expose the public key immediately
P2PKH: reveal the public key only when spending
P2SH:  reveal the script only when spending
MAST:  reveal only the script branch used
P2TR:  make the common case look like one key
P2MR:  keep script trees, remove the exposed key path

That makes P2MR a conservative, Bitcoin-style response to quantum uncertainty: do not replace everything at once, but reduce the attack surface where the current design obviously leaves one open.