Over the past few months, Bitcoin's long-running "quantum resistance" concern has moved from academic curiosity into practical risk management. Jefferies' Christopher Wood removed Bitcoin from his long-term model portfolio over quantum risk.
Coinbase stood up an "Independent Advisory Board on Quantum Computing and Blockchain." Inside the technical community, BIP 360 (a quantum-resistant output type) was merged as a draft into the official BIP repository, and Blockstream broadcast the first post-quantum-signed transactions on a production sidechain.
Since then, the timeline compression has only accelerated. On March 25, 2026, Google announced that all of its systems must migrate to post-quantum cryptography by 2029. Three papers published between May 2025 and March 2026 dropped the estimated qubit cost of breaking public-key cryptography by roughly three orders of magnitude, from ~20 million physical qubits down to potentially fewer than 100,000.
A March 2026 Google Quantum AI paper estimated that elliptic-curve cryptography could be broken with fewer than 500,000 physical qubits in minutes; Google withheld the attack circuits and published only a zero-knowledge proof of the result. A Caltech/Oratomic team suggested ~26,000 reconfigurable atomic qubits could break ECC-256 in about ten days. The gap between "laboratory curiosity" and "cryptographic threat" is closing from both directions, with algorithmic compression and hardware scaling simultaneously.
To understand the threat, it helps to look at what quantum computers can and cannot do. They do not "try all keys in parallel." Shor's algorithm gives exponential speedups for discrete log and factoring, the problems that elliptic-curve and RSA cryptography rely on, while symmetric crypto and hash functions only suffer a square-root speedup from Grover's algorithm, compensable with larger parameters.
"Quantum breaks cryptography" is both true and misleading: it targets primitives whose security reduces to group-structure problems, not an indiscriminate brute-force miracle. Post-quantum cryptography already exists and is deployable today; NIST has finalized standards (ML-KEM, ML-DSA, SLH-DSA) explicitly to support migration away from ECC/RSA.
In Bitcoin specifically, the hazard is about signatures: if an attacker can see your public key, Shor's algorithm can recover the private key. For pubkey-hash addresses (P2PKH/P2WPKH), the public key is only exposed when you spend; the main risk is address reuse. But Taproot outputs (P2TR) and old pay-to-pubkey outputs expose the public key at creation time, no spending required. BIP 360's Pay-to-Merkle-Root (P2MR) addresses this directly: a Taproot-like output type that never puts a public key on chain.
The priority is not to perfect Bitcoin's post-quantum story on paper; it's to start user migration now. Let users attach a post-quantum spending path alongside their existing elliptic-curve one. In peacetime, they keep using Schnorr/ECDSA; the post-quantum key sits unused. If a "clear and present danger" emerges, the network can deprecate elliptic-curve signatures without waiting years for a mass migration. It doesn't have to be the final scheme—pick something conservative now, improve later. The migration clock is measured in adoption, not engineering difficulty.
My take is that Bitcoin should choose hash-based signatures for this escape hatch. Not because lattice (ML-DSA) is bad, but because hash-based is the closest thing cryptography has to "as secure as it gets": minimal structure, minimal magic, minimal room for trapdoors. It's also surprisingly easy to audit and understand, which is in-line with Bitcoin's ethos.
SPHINCS+ (SLH-DSA) is the standard choice, but it produces fairly large signatures, ~8 kB to achieve "statelessness". Bitcoin doesn't really need that property. The UTXO model is inherently use-and-discard; systematic address reuse was never part of the design and the infrastructure accommodates this well. Stateful schemes like XMSS produce dramatically smaller signatures (~2.5 KB) and Bitcoin's spending model maps naturally onto that constraint.
Blockstream Research's SHRINCS construction gives you both: a stateful primary mode with a stateless SLH-DSA fallback if you lose state. Jonas Nick's SHRIMPS extension solves multi-device signing. Both are purely hash-based, and both are already running on Liquid.
If a credible "Shor is here" threshold is crossed, the first job is stopping irreversible theft, not saving every legacy output. The safest default is a kill switch: make elliptic-curve signatures non-spendable at the consensus level. A temporary lock is reversible; a quantum theft isn't. For outputs where the public key was never exposed, a ZK proof (e.g., a STARK) could let the rightful owner prove knowledge of the unlocking witness without revealing the key. For already-exposed keys, the only plausible rescue relies on an additional secret like an HD wallet seed. Coins without either path - dormant coins, early coins, Satoshi's coins - would remain locked. Better "still lost" than "now stolen."
A paper from StarkWare in April 2026 demonstrates that quantum-safe Bitcoin transactions are possible today under existing consensus rules. It's a genuinely clever construction but sadly the reaction around it exposes a genuine issue in the Bitcoin community. This trick is widely impractical and no substitute for a softfork, but so ingrained is the opposition to doing anything that it is already cited as a reason not to flip the "fix everything easily switch."
Get everyone a life jacket. Don't overthink it. The hard part isn't the cryptography; it's getting millions of users and every wallet, custodian, exchange, and signing device to migrate. This is the approach Tezos is taking: treat post-quantum readiness as two tracks (user key migration vs protocol cryptography), let users attach a backup post-quantum key now, and deprecate elliptic-curve signatures later if the threat materializes. Start the social migration while there's no urgency, because urgency is when ecosystems make mistakes. Put the life jackets on first; debate the boat design later.