Bitcoin's $1.3T Quantum Security Race: Key Initiatives

The Bitcoin quantum computing threat has crossed from theoretical to urgent. Google published research this week claiming a sufficiently powerful quantum computer could crack Bitcoin's core cryptography in under nine minutes — one minute faster than the average block confirmation. Analysts who track the space have pegged 2029 as a realistic timeline for such a machine to exist. That's not a distant abstraction anymore. That's three years away.

Why Is Bitcoin Vulnerable to Quantum Computers?

Bitcoin's security rests on a one-way mathematical relationship. Generate a wallet, and the system produces a private key — a secret number — from which a public key is derived. To spend your coins, you don't reveal the private key directly; you use it to generate a cryptographic signature the network can verify. That's the design. It works because breaking elliptic curve cryptography — specifically the Elliptic Curve Digital Signature Algorithm, or ECDSA — would take modern computers billions of years.

Quantum computers change the math. Shor's algorithm, running on a sufficiently powerful quantum machine, can reverse-engineer a private key from its public key. That flips Bitcoin's one-way street into a two-way road. Once a quantum attacker has your private key, they can forge transactions, drain wallets, and the network would see it as perfectly valid.

The exposure happens in two ways. The first is the 'long-exposure attack': coins sitting idle on-chain in address types that permanently reveal their public key. The second is the 'short-exposure attack': transactions waiting in the mempool, where public keys are briefly visible before confirmation. Both are real attack surfaces, and they require different fixes.

Which Bitcoin Addresses Are Already Exposed?

Roughly 1.7 million BTC sits in old Pay-to-Public-Key (P2PK) addresses — the format used by Satoshi Nakamoto and early miners. These addresses permanently expose their public keys on-chain, which means a future quantum attacker doesn't need to wait for a transaction to occur. The target is already sitting there, readable by anyone on earth. Some of those coins almost certainly belong to Satoshi.

Taproot (P2TR), Bitcoin's current address format activated in 2021, has the same problem. Every Taproot address embeds the public key permanently on-chain. Developers who pushed for Taproot's adoption knew this — the trade-off was accepted for other feature gains — but the quantum calculus has since shifted. Every new Taproot address created today is another permanent target.

The mempool exposure is different in character. Transactions waiting for block inclusion show public keys to the entire network. A quantum computer watching the mempool could, in theory, derive the private key and race a competing transaction to confirmation — but only within that brief window before the original gets buried. Speed matters enormously for this attack vector, which is why Google's nine-minute figure hit so hard. Bitcoin's block time is ten minutes. The margin is already almost gone.

BIP 360: Hiding the Public Key On-Chain

The most direct fix for new coins is BIP 360. Proposed as a Bitcoin Improvement Proposal, it introduces a new output type called Pay-to-Merkle-Root (P2MR) that removes the public key from the blockchain entirely. No visible key, no target. A quantum computer studying the chain has nothing to reverse-engineer.

The design preserves everything else. Lightning Network payments, multi-signature arrangements, and other Bitcoin features work as before. BIP 360 is essentially a structural change to how new addresses store ownership proof — swap out the exposed public key for something a quantum algorithm can't exploit.

The catch is scope. BIP 360 only protects new coins created after activation. The 1.7 million BTC already sitting in P2PK and Taproot addresses is a separate, harder problem. Developers working on BIP 360 are explicit about this: the legacy exposure requires other proposals, outlined below.

SPHINCS+ and the Signature Size Problem

SPHINCS+ post-quantum signature schemes work by avoiding elliptic curve cryptography altogether, instead building on hash functions that Shor's algorithm does not threaten in the same way. The National Institute of Standards and Technology standardized SPHINCS+ in August 2024 as FIPS 205 (also called SLH-DSA), following years of public review — making it the first post-quantum signature standard from a major government body to reach that milestone.

The security is solid. The practicality is painful. Current Bitcoin signatures clock in at 64 bytes. SLH-DSA signatures are 8 kilobytes or more — roughly 125 times larger. Deploy that on Bitcoin as-is and block space demand would spike, fees would climb, and the network would groan. That's not a workable rollout.

Two proposals — SHRIMPS and SHRINCS — have emerged to address the bloat. Both build on SPHINCS+ while targeting smaller signature sizes, aiming to preserve the post-quantum security guarantees in a more block-space-efficient form. Neither has reached the maturity of BIP 360, but the direction is clear: SPHINCS+ is the cryptographic foundation, and the engineering work now is about making it fit inside Bitcoin's constraints.

The Commit-Reveal Soft Fork: A Mempool Shield

Lightning Network co-creator Tadge Dryja proposed a soft fork specifically targeting the mempool exposure. The mechanism splits transaction execution into two phases: a Commit phase and a Reveal phase.

In the Commit phase, you broadcast only a cryptographic hash of your transaction — a sealed fingerprint that reveals nothing about the actual spend. The blockchain timestamps that fingerprint permanently. Later, in the Reveal phase, you broadcast the full transaction, making your public key visible. At this point, yes — a quantum attacker watching the network could theoretically derive your private key and forge a competing spend. But that forged transaction would get rejected immediately. The network checks whether the spend has a prior on-chain commitment. Yours does, registered before the Reveal. The attacker's doesn't — they created it moments ago. Your pre-registered fingerprint is your alibi.

Dryja's framing is pragmatic. The Commit-Reveal mechanism is described as an interim bridge — practical to deploy while the community builds toward a comprehensive quantum defense. The cost is real: splitting transactions into two phases increases complexity and fees. But it buys time.

Hourglass V2: Managing the Worst-Case Scenario

Proposed by developer Hunter Beast, Hourglass V2 accepts a premise most Bitcoin proposals try to avoid: the roughly 1.7 million BTC in already-exposed addresses might simply be stolen if a sufficiently capable quantum computer arrives. Given that, the proposal focuses on limiting the damage — specifically, restricting sales from compromised addresses to one bitcoin per block to prevent a catastrophic overnight liquidation.

The bank run analogy is apt. You can't stop withdrawals from a panicking system. But you can cap the pace and prevent the system from collapsing in a single session. A slow bleed is survivable; an overnight drain of hundreds of billions of dollars worth of bitcoin would not be.

The proposal is controversial, and deliberately so. Even a soft limit on spending rights cuts against one of Bitcoin's foundational commitments — that no external party can interfere with a holder's right to move their coins. Some in the developer community see Hourglass V2 as an acceptable emergency measure. Others see it as a philosophical betrayal. That tension isn't resolved, and it probably won't be until the threat becomes imminent.

Where Does the Quantum Defense Stand Today?

None of these proposals are live. BIP 360, SPHINCS+, the Commit-Reveal soft fork, and Hourglass V2 are all under active developer discussion, but Bitcoin's decentralized governance — spanning developers, miners, and node operators — means no single actor can push an upgrade through. Consensus takes time, sometimes years.

What's worth noting is that this discussion predates Google's report. Developers had already been tracking the quantum threat before this week's research landed. The Bitcoin quantum computing threat research adds urgency and specificity — nine minutes is a sharper number than any prior estimate — but the proposals in circulation didn't spring up overnight in a panic. They've been building.

About $1.3 trillion in market cap rides on whether this defensive work keeps pace with quantum hardware development. The nine-minute window in Google's research is not today's reality. But it signals what tomorrow's reality could look like — and Bitcoin's developers are already arguing about how to answer it.