1. The Threat Has Moved Off the Whiteboard
For years, quantum computing's threat to Bitcoin's cryptography occupied a comfortable theoretical space — real in principle, but far enough away in practice that the community could defer serious action. Google's Quantum AI team ended that comfort zone in late March 2026. By publishing a paper demonstrating that breaking Bitcoin's elliptic curve cryptography may require fewer than 500,000 physical qubits — a roughly twentyfold reduction from prior estimates — and that a sufficiently powerful future machine could derive a private key from a public key in approximately nine minutes, the researchers compressed the credible threat timeline to as early as 2029.
That compression has concentrated minds. The Bitcoin developer community is now engaged in a multi-front technical effort to identify, evaluate, and prepare the protocol for a suite of cryptographic upgrades that would need to be deployed before quantum hardware reaches the attack threshold. The stakes are not abstract: Bitcoin's market capitalization currently sits around $1.3 trillion, and an estimated 6.9 million BTC — roughly one-third of all circulating supply — already sits in wallets where public keys have been permanently exposed and could be targeted at leisure once a capable quantum machine exists.
2. Understanding the Two Attack Surfaces
Before examining specific proposals, it is necessary to understand that the quantum threat to Bitcoin manifests in two distinct attack categories, each requiring a different defensive response.
The first is the long-exposure attack, which targets wallets where the public key has already been permanently visible on the blockchain. Pay-to-public-key addresses, used by Satoshi Nakamoto and early miners in Bitcoin's first years, embed the public key directly in transaction outputs. More recently, the Taproot upgrade activated in 2021 made public keys visible by default for a common transaction type, inadvertently expanding the category of exposed addresses. Coins sitting in these addresses require no spending transaction for their public key to be accessible — a future quantum computer could work through them systematically and without any time constraint.
The second is the short-exposure attack, which targets transactions in the network's memory pool that are waiting for confirmation. When a transaction is broadcast, the public key is revealed temporarily before confirmation. Under Google's nine-minute model, a quantum computer could in theory derive the private key during that window, construct a competing transaction with a higher fee, and have it confirmed ahead of the original. This race condition — attacker against the clock — is the basis for the roughly 41% success probability estimated in Google's research under typical block confirmation timing.
3. BIP 360: Removing Public Keys From the Chain
The most comprehensive of the post-quantum upgrade proposals is Bitcoin Improvement Proposal 360, put forward by developer Hunter Beast. BIP 360 introduces a new output type called Pay-to-Merkle-Root, or P2MR, that permanently removes the public key from the blockchain itself. Under P2MR, addresses are derived from a Merkle root that contains hashed representations of multiple quantum-resistant public keys arranged in a tree structure. The private key is never exposed on-chain during normal operation, eliminating the primary target for both long-exposure and short-exposure attacks against newly created addresses.
For post-quantum signatures under BIP 360, the proposal incorporates SPHINCS+, the signature scheme standardized by the U.S. National Institute of Standards and Technology specifically because of its resistance to quantum attacks. SPHINCS+ relies on the computational difficulty of inverting hash functions rather than on elliptic curve mathematics, and is therefore resistant to Shor's algorithm. The trade-off is size: a single SPHINCS+ signature exceeds 8 kilobytes, compared to approximately 64 bytes for a standard Bitcoin signature today. That roughly 125-fold increase in signature size has material implications for transaction throughput and blockchain storage, and it is one of the primary engineering challenges BIP 360 must address before any realistic deployment timeline can be established.
4. SHRIMPS and SHRINCS: Smaller Quantum-Safe Signatures
The signature size problem associated with SPHINCS+ has prompted parallel work on more compact alternatives. Two proposals — SHRIMPS and SHRINCS — build on the security foundations of SPHINCS+ while attempting to reduce its data footprint to a level more compatible with Bitcoin's existing block size constraints and transaction throughput requirements.
SHRIMPS, which stands for Short Hash-based Really Improved Message Post-quantum Signatures, and SHRINCS, a related construction, both retain the hash-based security guarantees that make SPHINCS+ quantum-resistant while optimizing the signature structure to reduce the number of hash evaluations required per signature. The practical result is smaller signatures that are more efficient to verify without introducing new cryptographic assumptions that would require a fresh security analysis. Neither has advanced to the level of a formal BIP, but both are under active development and are likely to inform whatever final signature scheme emerges from the community's evaluation process.
The existence of multiple competing signature proposals reflects a healthy research environment, but it also introduces delay. Bitcoin's upgrade process requires extensive peer review, security analysis, and community consensus before any change to the protocol can be deployed. A fragmented landscape of competing alternatives, each with different efficiency profiles and security assumptions, extends the timeline required to reach the consensus that a soft fork would need.
5. The Commit/Reveal Scheme: Protecting In-Flight Transactions
For the specific problem of the short-exposure attack — protecting transactions that are waiting in the mempool — Lightning Network co-creator Tadge Dryja has proposed a soft fork implementing a commit/reveal mechanism. The proposal addresses the nine-minute race condition by adding an additional on-chain phase before the full transaction is broadcast.
Under the commit/reveal scheme, a user who wants to send bitcoin first publishes a cryptographic fingerprint — specifically a hash — of the intended transaction to the blockchain. This hash contains no information about the transaction's content or the sender's public key, but it creates a timestamped, immutable record of intent. Later, when the full transaction is broadcast and the public key becomes visible, the network checks whether the transaction has a prior commitment registered on-chain. A legitimate transaction does; a forged transaction created by an attacker who derived the private key from the exposed public key does not. The network rejects any transaction that lacks a corresponding prior commitment, even if it carries valid signatures.
The elegance of the commit/reveal approach is that it works within Bitcoin's existing security model and can be deployed as a soft fork without requiring the broader community to agree on a specific post-quantum signature scheme. The drawback is cost: breaking each transaction into two phases increases the number of on-chain operations, the associated fees, and the latency of the settlement process. Dryja himself describes it as an interim bridge — practical to deploy relatively quickly while the longer-term cryptographic migration is being prepared — rather than a permanent solution.
6. Hourglass V2: Protecting Satoshi's Coins and Early Wallets
The most politically and technically contentious proposal on the current list is Hourglass V2, put forward by developer Hunter Beast. The proposal targets the specific problem of the roughly 1.7 million BTC held in the oldest, most exposed addresses — including wallets attributed to Satoshi Nakamoto — that would be vulnerable to at-rest quantum attacks. Under Hourglass V2, spending from these already-exposed addresses would be limited to one bitcoin per block.
The rationale is protective: if a quantum computer eventually cracks these addresses, the damage would occur at a rate of one BTC per block — roughly one BTC per ten minutes — rather than all at once. This would give the network and the community time to detect the attack, respond, and potentially invalidate the stolen coins before catastrophic market damage occurs. The alternative scenario — where billions of dollars in old bitcoin suddenly flood the market after being stolen in a quantum attack — would be structurally destabilizing in a way that a slow-drip theft might not be.
The proposal is controversial for multiple reasons. Restricting the spending of certain coins by protocol rule is philosophically contentious in a community that strongly values the sanctity of property rights on-chain. The coins in question include wallets that may belong to individuals who are simply inactive — not to known bad actors — and imposing spending limits on them raises questions about the precedent it sets. Whether the community can reach consensus on a proposal this novel remains uncertain, and some prominent voices have argued for alternative approaches that rely on voluntary migration incentives rather than protocol-level restrictions.
7. The Governance Challenge That Dwarfs the Technical One
Every proposal in the current quantum defense discussion faces the same overarching constraint: Bitcoin's decentralized governance process is slow, deliberate, and resistant to change by design. Adding a feature or modifying the protocol requires a proposal to survive extensive peer review, generate developer buy-in, achieve miner activation through a soft fork process, and ultimately be adopted by the full network of nodes. The timeline for the most significant protocol changes in Bitcoin's history — including SegWit and Taproot — stretched across years from proposal to activation.
A comprehensive quantum migration would require not just protocol changes but also widespread user action: individuals holding coins in vulnerable addresses would need to migrate their funds to quantum-resistant formats. That migration cannot be forced — it can only be incentivized or, in the case of proposals like Hourglass V2, constrained. The population of holders with coins in exposed addresses includes a significant fraction who may be unreachable, deceased, or simply inactive, creating a coordination problem with no clean solution.
The timeline pressure from Google's research — with some analysts citing 2029 as a credible year for the emergence of sufficiently powerful quantum hardware — creates a genuine tension. The window between now and that potential threshold may not be long enough to complete the governance process, achieve broad adoption of new address formats, and coordinate user migration at the scale required. Bitcoin developer Adam Back has advocated for a phased approach, noting that Taproot's existing design properties provide some near-term buffer, but acknowledging that the longer-term migration is unavoidable and must begin in earnest.
8. Coinbase Calls for Industry-Wide Coordination
Beyond the core developer community, institutional actors have begun weighing in on the urgency of the quantum migration challenge. Coinbase CEO Brian Armstrong publicly called for an industry-wide effort on Bitcoin quantum resistance, framing the issue not as a Bitcoin-only problem but as a cross-industry challenge requiring coordinated action from exchanges, custodians, wallet providers, and protocol developers. Armstrong's statement reflects a growing recognition that the migration problem extends beyond the protocol itself — it requires ecosystem-level infrastructure changes, user education, and institutional processes for helping customers move funds from vulnerable addresses to quantum-resistant ones.
The involvement of institutional actors in the quantum migration conversation is significant because it introduces resources and incentive structures that the volunteer developer community alone cannot provide. Exchanges and custodians hold substantial amounts of bitcoin in custody and have direct relationships with the users whose funds are at risk. If major custodians develop migration tooling and actively encourage users to transition to quantum-resistant addresses once those are available, the practical adoption problem becomes more tractable than it would be if migration depended solely on individual initiative.
9. What Bitcoin's Mining Algorithm Is Not At Risk
One clarification that has been inconsistently communicated in public coverage of the quantum threat is that Bitcoin's mining process is not at risk from the same attack vector. Bitcoin's proof-of-work mining uses SHA-256, a hash function rather than an elliptic curve cryptographic system. Quantum algorithms — specifically Grover's algorithm — can provide a quadratic speedup in searching hash spaces, which would effectively halve the bit-security of SHA-256 in a quantum computing world. But halving SHA-256's security from 256 bits to approximately 128 bits does not make it breakable by any practical quantum hardware expected to exist in the near term. The mining security concern is real but manageable and involves a less dramatic revision of the timeline than the elliptic curve attack.
The distinction matters for understanding what quantum computing actually threatens. It threatens the ownership model — the cryptographic link between private and public keys that proves who controls a given bitcoin. It does not threaten the consensus mechanism or the immutability of the blockchain's transaction history. A quantum attack would allow theft of existing coins from vulnerable addresses; it would not allow an attacker to rewrite history or mint new coins. Bitcoin would continue to function as a network even in a world where quantum attacks are possible, but its ownership guarantees would be fundamentally compromised unless the cryptographic migration is completed.
10. The Race Against a Deadline That Keeps Moving
The urgency of the quantum defense work ultimately depends on assumptions about hardware timelines that remain genuinely uncertain. The most optimistic quantum computing roadmaps place a cryptographically relevant machine at 2029 or 2030. More conservative estimates push that threshold to the mid-2030s or beyond. The wide range of credible estimates reflects real scientific uncertainty about the engineering challenges involved in scaling quantum hardware while maintaining the qubit error rates needed for practical computation.
What Google's recent research has done is narrow the resource requirement threshold, making the date of arrival somewhat more plausible at the aggressive end of estimates and significantly raising the probability of a state-sponsored development reaching the threshold before any public announcement occurs. For a decentralized system like Bitcoin, which needs years of lead time to complete a meaningful protocol migration, the appropriate response to that narrowing is not panic but systematic urgency — beginning the governance process, maturing the technical proposals, and creating the user migration infrastructure now, while there is still time to act deliberately rather than reactively. The proposals described here represent the current state of that effort, and their evolution over the coming months will determine whether Bitcoin's $1.3 trillion in secured value is still secure when the quantum hardware era arrives.