Bitcoin and quantum computers: the post-quantum BIPs

A large enough quantum computer running Shor's algorithm could derive a private key from a public key, which would break the signatures Bitcoin uses today. No such computer exists, and nobody knows when or whether one will. Coins are only exposed where a public key is visible on chain: early P2PK outputs, reused addresses and Taproot outputs. Two BIPs propose responses: BIP 360 adds a Taproot-like output without a key path (Pay-to-Merkle-Root, P2MR), and BIP 361 sets out a phased retirement of today's signatures. Both are proposals; each BIP page shows its current status.

Updated 2026-10-20 · 7 min read

The short answer

Bitcoin uses two kinds of cryptography. ECDSA and Schnorr signatures prove ownership; both rely on the elliptic curve discrete logarithm problem being hard. Hash functions (SHA-256, RIPEMD-160) build addresses, link blocks and drive mining. Quantum algorithms threaten the first much more than the second.

BIP 360's authors put it this way: "it is unclear when or if" cryptographically relevant quantum computers (CRQCs) will become viable, and their proposal "does not take a position on any specific quantum computing timeline". BIP 361's authors argue the opposite emphasis, that migration takes years and should start early. This guide explains what is at stake and what each proposal would do, without guessing dates.

What a quantum computer could and couldn't break

Shor's algorithm: signatures

Shor's algorithm, published by Peter Shor in 1994, solves the discrete logarithm problem efficiently on a sufficiently large, error-corrected quantum computer. For Bitcoin that means computing the private key from a public key, which BIP 360 calls "quantum key recovery". It would affect ECDSA and BIP 340 Schnorr alike, since both use the secp256k1 curve. It only works where the public key is known, which is why the type of output matters.

Grover's algorithm: hashes and mining

Grover's algorithm gives a general quadratic speedup for search problems. Against a hash function it turns a 2^256 brute-force search into roughly 2^128 operations: a big reduction, but 2^128 is still far out of reach. That is why hashes are considered much more robust than elliptic curve signatures, and why outputs that publish only a hash protect keys while unspent. Shorter 160-bit hashes, used in P2PKH and P2WPKH addresses, keep a smaller margin. Grover could in principle speed up mining too, but no BIP proposes changing proof of work in response to quantum computing.

Which bitcoin outputs expose public keys?

BIP 360 separates two kinds of attack:

• Long exposure attacks target public keys that sit on chain for a long time. An attacker has as long as the coins stay put.
• Short exposure attacks target a public key revealed in a transaction waiting in the mempool, and would require a far faster quantum computer to finish before the transaction confirms.

Almost every spend reveals a public key, so short exposure applies to all output types. Long exposure depends on the output type:

Three things turn a "No" into a "Yes". Address reuse: once you spend from an address, its public key is on chain, so coins still sitting there are exposed. Shared extended public keys: BIP 360 notes that xpubs and output descriptors reveal public keys too. Scripts that contain keys, once spent.

P2PK outputs include many coins mined in Bitcoin's first years. BIP 361's authors estimate that, as of 1 March 2026, over 34% of all bitcoin was in outputs whose public key had been revealed on chain.

Why does Taproot put a public key in the output?

BIP 341 explains the choice. Taproot needs the key for batch verification, and a 256-bit hash would have cost about as much space. On quantum risk its authors wrote that hashing keys "is often said to protect against ECDLP breaks or quantum computers", but "this protection is very weak at best: transactions are not protected while being confirmed, and a very large portion of the currency's supply is not under such protection regardless." Real resistance, they argued, needs different cryptographic assumptions. The Taproot guide covers the rest of the design.

BIP 360: Pay-to-Merkle-Root (P2MR)

BIP 360, by Hunter Beast, Ethan Heilman and Isabel Foxen Duke, proposes a new output type through a soft fork. P2MR works like a Taproot output with the key path removed:

• What's in the output: OP_2 plus the 32-byte Merkle root of a script tree, built exactly as in BIP 341 (TapLeaf and TapBranch hashes). It is SegWit version 2, so addresses start with bc1z.
• How it's spent: always through a script, revealing the leaf script, its inputs and a control block of 1 + 32m bytes. Unlike Taproot there is no internal key to reveal.
• What it protects against: long exposure attacks, because only a hash is on chain until spending. The BIP says it gives 128 bits of collision resistance and 256 bits of preimage resistance, the same as P2WSH.
• What it doesn't do: add post-quantum signatures. Scripts in a P2MR tree still use today's signature opcodes, so short exposure attacks remain possible. The authors say protection against those "may require the introduction of post-quantum signatures", which they intend to offer as a separate proposal, and name ML-DSA and SLH-DSA as schemes to scrutinize.

Why not just use P2WSH, which already hides keys behind a hash? Because P2WSH doesn't support Tapscript, and the BIP calls Tapscript's OP_SUCCESSx upgrade path "critical" for adding post-quantum signature opcodes later.

The cost. A P2MR spend is always larger than a Taproot key path spend: the BIP's example witness for a depth-1 tree is 135 bytes against 66 bytes for a P2TR key path spend. It is smaller than the equivalent Taproot script path spend, since no internal key is included. Single-leaf trees are made anyone-can-spend, to push users toward at least two spending paths.

The name. BIP 360's changelog records earlier names: it was Pay to Quantum Resistant Hash (P2QRH), renamed Pay-to-Tapscript-Hash (P2TSH) in September 2025 and Pay-to-Merkle-Root in February 2026. The witness version also changed from 3 to 2 in 2025.

BIP 361: Post Quantum Migration and Legacy Signature Sunset

BIP 361, by Jameson Lopp, Christian Papathanasiou, Ian Smith, Joe Ross, Steve Vaile and Pierre-Luc Dallaire-Demers, assumes some post-quantum output type has already been deployed and proposes a pre-announced sunset of ECDSA and Schnorr:

The rescue idea relies on something the real owner knows and a quantum attacker doesn't. For example, a wallet built with BIP 32 hardened derivation could prove knowledge of the parent private key, perhaps with a zero-knowledge proof. The BIP says no such rescue is believed possible for P2PK outputs, and that it is compatible with a separate "Hourglass" style proposal for them.

This is the most contested part of the quantum discussion. BIP 361 calls itself "radically different from any in Bitcoin's history" and argues that coins taken by a quantum attacker would amount to "a theft from everyone". Critics see restricting old signatures as confiscating coins whose owners don't act in time. The authors respond that if rescue protocols cover most of the supply, the restriction "will be at most mildly confiscatory". Both positions have supporters.

Other quantum ideas in the BIPs

• Lamport signatures via OP_CAT. BIP 347 lists hash-based Lamport signatures as one use of OP_CAT, but notes that a Taproot output's key path would still be exposed to a quantum attacker. BIP 360 adds that such signatures are one-time: signing twice with the same key risks leaking it.
• New script systems. BIP 141 already named "Lamport signatures, which are quantum computing resistant" as an example of what witness versioning could add later.
• Encrypted transport. BIP 324 lists post-quantum upgrades to its handshake as a possible future feature.

More covenant and opcode proposals that could interact with this work are in the covenants guide, and the activation question in the soft forks guide.

What you can do today

Nothing in the protocol currently requires you to act. Sensible habits that help regardless:

• Don't reuse addresses. Spending from an address reveals its public key.
• Keep xpubs and descriptors private, since they reveal public keys.
• Know your output type. Hash-based outputs (bc1q, 3, 1) keep the key off chain until you spend; Taproot (bc1p) doesn't. The address checker tells you which type an address is.
• Be wary of anyone selling a "quantum-safe" wallet or migration service. Never type a seed phrase or private key into a website.