Bitcoin’s Quantum Vulnerability: Anatomy of the Attack Surface

Introduction

In January 2026, a rumor spread across social media that Satoshi Nakamoto’s wallets had moved 10,000 BTC. It was false. Arkham Intelligence debunked it within hours. But before the correction reached the market, roughly $1 billion in Bitcoin ETF outflows had already been triggered in a single session.

That episode revealed something important about Bitcoin’s quantum risk that the technical community tends to overlook. The threat is not just cryptographic. It is psychological. Over 1.1 million BTC attributed to Satoshi Nakamoto sit in early Pay-to-Public-Key (P2PK) addresses with their public keys permanently exposed on the blockchain. A cryptographically relevant quantum computer would not need to guess or brute-force those keys. It would derive the private keys directly using Shor’s algorithm, then move the coins. Whether that actor is a government, a corporation, or a criminal syndicate, the market impact of Satoshi’s coins suddenly entering circulation would dwarf any technical damage.

But Satoshi’s coins are only the most visible piece of a larger exposure. As of early 2026, roughly 6.7 million BTC (about 34% of circulating supply) sit in addresses with public keys exposed on-chain, according to analysis in the Google Quantum AI whitepaper. Of those, approximately 2.3 million BTC are both vulnerable and dormant, meaning they have not moved in at least five years. This article maps the full vulnerability landscape: which script types are exposed, how public keys leak, what attack windows look like in practice, and why the policy debate over dormant assets may prove harder to resolve than the engineering.

The Script-Type Taxonomy

Bitcoin’s quantum vulnerability is not uniform. It depends on which type of locking script protects the coins and whether the public key associated with that script has been revealed. Understanding this taxonomy is essential because different script types require different mitigation strategies, and some cannot be mitigated at all.

P2PK: Permanently Exposed

Pay-to-Public-Key scripts record the recipient’s public key directly in the locking script on the blockchain. The key is visible to everyone from the moment the coins are received. There is no hash protection, no time-limited exposure window. A quantum attacker with access to a CRQC (even a slow one that takes days per key derivation) can work through P2PK addresses at leisure.

Roughly 1.7 million BTC sits in P2PK outputs, overwhelmingly from Bitcoin’s first two years of operation (2009-2010). This includes the estimated 1.1 million BTC attributed to Satoshi Nakamoto, spread across approximately 22,000 separate outputs (public keys), each with its own independent private key. These coins have not moved since they were mined. The overwhelming assumption is that the private keys are lost.

P2PK coins cannot be migrated to quantum-safe addresses because migration requires the private key, which the current holder must know and use. If the keys are truly lost, these coins are a fixed, permanent target: tens of billions of dollars in value that will eventually become accessible to anyone with a CRQC, regardless of what the Bitcoin protocol does.

P2PKH: Safe Until Spent

Pay-to-Public-Key-Hash scripts hide the public key behind a double hash (SHA-256 followed by RIPEMD-160). Only the hash appears in the locking script on the blockchain. The actual public key is revealed only when the owner spends the coins, at which point it appears in the unlocking script.

This design provides genuine quantum protection against at-rest attacks. A quantum computer running Shor’s algorithm can derive a private key from a public key, but it cannot reverse a hash function to recover a public key from its hash. (Grover’s algorithm could theoretically be applied, but the cost would be computationally prohibitive with no practical advantage over classical brute force.) As long as a P2PKH address has never been used to send a transaction, and the public key has not been exposed through other means, it remains safe from at-rest quantum attacks.

The protection breaks the moment the owner spends from that address. The public key, once revealed in the spending transaction, stays on the blockchain permanently. If the address held additional unspent outputs beyond what was sent, those remaining coins are now exposed. This is the address reuse vulnerability, and it is pervasive.

P2PKH addresses use the 1... prefix and dominated Bitcoin usage from 2010 through 2017.

P2WPKH and P2WSH: The SegWit Generation

Pay-to-Witness-Public-Key-Hash (P2WPKH) and Pay-to-Witness-Script-Hash (P2WSH), introduced with the SegWit upgrade in 2017, follow the same hash-protection logic as P2PKH and P2SH. Public keys and scripts are hidden behind hashes until spend time. These addresses use the bc1q prefix and represent the majority of current Bitcoin usage.

The quantum security properties are identical to P2PKH: safe from at-rest attacks as long as the public key has not been exposed through spending or reuse. The SegWit witness discount (which counts witness data at one-quarter the weight of non-witness data) also has implications for PQC migration, since post-quantum signatures will reside in the witness and benefit from the discount. More on this in the technical migration roadmap.

P2TR: The Taproot Quantum Regression

Pay-to-Taproot (P2TR) scripts, activated with the Taproot soft fork in November 2021, introduced Schnorr signatures and a versatile script structure that supports both a “key path” (direct signature spend) and a “script path” (complex spending conditions hidden in a Merkle tree). The upgrade was widely celebrated for improving privacy, reducing fees, and enabling advanced smart contract features.

It also reintroduced quantum vulnerability. P2TR stores the tweaked public key directly in the locking script, visible on the blockchain from the moment coins are received. From a quantum security perspective, Taproot constitutes a regression to the exposure model of P2PK. The privacy gains came at the cost of quantum safety.

This regression is not academic. P2TR addresses (using the bc1p prefix) have seen rapid adoption since 2021. According to the Google paper’s analysis of Bitcoin transaction data, P2TR represented 21.68% of all Bitcoin transactions in 2025 and moved roughly 16.8 million BTC during the year. Every one of those receiving addresses has an exposed public key.

Draft BIP-360 proposes Pay-to-Merkle-Root (P2MR) addresses as the remedy: essentially Taproot with the quantum-vulnerable key path removed. P2MR commits to scripts in a Merkle tree without exposing any public key on-chain, preserving the script-path flexibility while eliminating the at-rest attack vector. The proposed address prefix is bc1z.

P2MS: Legacy Multisig

Pay-to-Multisig scripts record all participating public keys directly in the locking script, similar to P2PK. All keys are exposed from the moment the multisig output is created. P2MS has been largely superseded by P2SH and P2WSH (which hide the multisig script behind a hash), but some legacy multisig outputs remain on the blockchain with permanently exposed keys.

Summary Table

Every existing Bitcoin script type is vulnerable to on-spend attacks by a fast-clock CRQC. P2MR, when combined with post-quantum signature verification in its script leaves, would be the first script type to eliminate both the at-rest and on-spend vectors for newly created outputs. It does not yet exist in Bitcoin’s consensus rules, and it does not protect legacy hash-protected addresses from on-spend attacks when their owners spend to migrate.

How Public Keys Get Exposed

The Google whitepaper identifies four pathways through which a quantum attacker can obtain the public key needed to derive a private key. Each creates a different exposure window and requires a different mitigation approach.

Weak Address vulnerability occurs when the locking script itself records the public key on the blockchain. P2PK, P2MS, and P2TR all suffer from this. The exposure is permanent and begins the moment coins are received. The attacker can work offline with unlimited time.

Address Reuse vulnerability occurs when the unlocking script from a spending transaction reveals the public key that protects other, still-unspent coins at the same address. This affects P2PKH, P2WPKH, P2SH, and P2WSH, all of which normally hide keys behind hashes. The protection evaporates the moment a user sends any transaction from an address that still holds additional funds. Despite longstanding guidance against address reuse (dating back to Satoshi’s own whitepaper), the practice is extremely common. Exchanges, custodians, and merchants routinely reuse addresses for operational convenience. The Google paper’s analysis quantifies this: among the top 100,000 vulnerable addresses by BTC balance, the majority are vulnerable not because of their script type but because of address reuse. Some of the largest holdings linked to Binance, Robinhood, and Bitfinex appear in this list.

Public Mempool Exposure occurs when a user broadcasts a transaction. The unlocking script (containing the public key and signature) becomes visible in the mempool before the transaction is confirmed in a block. For hash-protected addresses that have never been reused, this is the only window of vulnerability. It is also the window that defines on-spend attacks. The duration depends on block time and network congestion: typically minutes for Bitcoin, but potentially hours during peak congestion periods when the mempool backlog is large.

Offchain Exposure results from practices outside the Bitcoin protocol itself. Using the same private key on multiple blockchains (Bitcoin and Bitcoin Cash share early transaction history; Rootstock derives addresses from Bitcoin keys) can expose a public key on one chain while the corresponding funds sit on another. Sharing extended public keys with portfolio tracking services, wallet providers, or business partners creates another vector. In a world without quantum computers, sharing public keys is harmless. In a world with CRQCs, every public key exposure is a potential theft vector.

The 9-Minute Attack Window

On-spend attacks are the most operationally dramatic threat scenario. The mechanics work as follows:

A user broadcasts a Bitcoin transaction. The public key appears in the mempool. A quantum attacker extracts the public key, runs Shor’s algorithm to derive the private key, forges a competing transaction sending the coins to an address the attacker controls, and attempts to get the forged transaction confirmed before the legitimate one.

Google estimates that a primed superconducting CRQC could complete the key derivation in approximately 9 minutes. Bitcoin’s average block time is 10 minutes, but the mining process follows a Poisson distribution with high variance: the standard deviation is also about 10 minutes. Under idealized assumptions (the attacker receives the public key immediately and can insert a high-fee competing transaction), the probability of success is roughly 41%.

Several factors modify this probability in practice. Network congestion increases it: when the mempool backlog is large, legitimate transactions wait longer, giving the attacker more time. Replace-By-Fee (RBF) increases it: the attacker can outbid the legitimate transaction’s fee, and since they are stealing funds they do not own, they can rationally bid up to the full value of the coins. Faster blockchains reduce it sharply: Litecoin (2.5-minute blocks) drops to under 3%, Zcash (75-second blocks) to under 0.08%, Dogecoin (1-minute blocks) to under 0.01%.

The Google paper also describes a more sophisticated on-spend attack that targets Bitcoin’s consensus layer. When a high-value address’s public key first appears in a confirmed block, the attacker could offer miners a reward to orphan that block (causing a chain reorganization), then use the CRQC to break the now-exposed key and steal the funds in the replacement block. This attack is funded by the stolen assets themselves.

Proof-of-Work: Immune to Quantum Attack

A persistent misconception in both the quantum computing and cryptocurrency communities holds that quantum computers threaten Bitcoin mining. They do not. This point requires emphasis because the confusion muddies the policy debate.

Bitcoin mining requires finding a nonce that, when combined with a block’s data, produces a SHA-256 hash below a target threshold. Grover’s algorithm provides a quadratic speedup for this type of unstructured search, halving the effective bit security. SHA-256 would drop from 256-bit to 128-bit equivalent security under Grover’s attack.

In practice, the speedup is almost entirely consumed by the overhead of quantum error correction. The Google paper calculates that even under the fantastical assumption that a CRQC could compute SHA-256 in a single 1-microsecond error correction cycle, the resulting hashrate would be approximately 0.25 TH/s. A popular ASIC miner, the Bitmain S19 Pro, achieves 110 TH/s. The quantum miner would be more than two orders of magnitude slower. Under realistic error correction assumptions, the quantum miner’s hashrate drops by over ten orders of magnitude.

Furthermore, Grover’s algorithm does not parallelize efficiently. While classical mining speed scales linearly with the number of ASICs, Grover’s speedup scales only with the square root of the number of parallel quantum machines, yielding severe diminishing returns. Against Bitcoin’s massively parallelized classical network, Grover’s quadratic advantage evaporates.

Proof-of-Work consensus, SHA-256 hash locks in Lightning HTLCs, and hash-based address protection (P2PKH, P2WPKH) all remain quantum-safe. The quantum threat to Bitcoin is exclusively about Shor’s algorithm applied to elliptic curve signatures, not Grover’s algorithm applied to hashing.

The Dormant Asset Problem

The most difficult aspect of Bitcoin’s quantum vulnerability cannot be solved with code. It is a policy problem.

Roughly 2.3 million BTC sits in addresses that are both quantum-vulnerable (exposed public keys) and dormant (no spending activity in at least five years). The overwhelming assumption is that much of this Bitcoin is lost: private keys destroyed, forgotten, or belonging to people who have died. The 1.7 million BTC in P2PK scripts represents the largest concentration, but address reuse extends the dormant vulnerable pool to additional script types.

These assets cannot be migrated to post-quantum addresses because migration requires the private key. If the keys are truly lost, no protocol upgrade can move the coins to safety. They will sit on the blockchain, with public keys permanently exposed, until a quantum computer derives the private keys and someone moves them.

The Bitcoin community is debating four approaches:

Do Nothing. The protocol stays unchanged. Whoever derives the private keys (including quantum attackers) can claim the coins. This preserves Bitcoin’s property rights model and immutability norms, but risks price destabilization as billions in dormant supply re-enter circulation unpredictably.

Burn. A protocol change renders dormant vulnerable outputs unspendable after a specified date. This prevents quantum theft but expropriates any legitimate owner who fails to migrate in time, including holders who are offline, unaware, imprisoned, or dead. The BIP-361 proposal follows a variant of this approach, with a phased sunset of legacy signature types and a potential Phase C recovery mechanism using zero-knowledge proofs tied to BIP-39 seed phrases.

Hourglass. A protocol change limits the rate at which dormant coins can be spent (for example, one P2PK UTXO per block). This avoids outright confiscation while creating a bottleneck that slows quantum attackers and potentially transfers some value to miners through fee competition. The Hourglass proposal from Hunter Beast and Mike Casey was the subject of detailed discussion at Bitcoin 2026.

PACTs (Provable Address-Control Timestamps). Proposed by Dan Robinson of Paradigm in May 2026, this alternative lets dormant holders prove they still control their keys without moving coins, using timestamped cryptographic attestations. The approach aims to distinguish legitimate dormant holders from truly lost coins, enabling more targeted policy responses.

The Google paper introduces a fifth option: digital salvage. Drawing an analogy to maritime salvage law for sunken treasure, this framework would treat CRQC-based recovery of dormant assets as a regulated activity, bringing the financial gains into the formal, taxable economy rather than letting them fall to criminal or state-sponsored actors. The paper also proposes a “bad sidechain” mechanism (borrowing the “bad bank” concept from traditional finance): a dedicated post-quantum sidechain where recovered dormant coins are sent for ownership resolution, using offchain proofs like BIP-39 mnemonic codes to return assets to legitimate owners.

The community remains split. At the Presidio Bitcoin Quantum Summit in San Francisco in early 2025, an informal poll showed roughly equal support for Do Nothing, Burn, and Hourglass. At Bitcoin 2026, the consensus among several prominent voices leaned toward leaving Satoshi’s coins untouched, with one advocate noting that “violating his property rights” would set a dangerous precedent. But the Google paper’s framing is blunt: “Coins stolen by a quantum computer would devalue every other bitcoin. Think of it as theft from everyone.”

This debate will define Bitcoin’s governance capacity for the decade ahead. The technical migration path is covered in the next article in this series.

What Bitcoin Holders Should Do Now

The immediate action items depend on how you hold Bitcoin today.

If your coins are in P2WPKH (bc1q) addresses that have never been used to send a transaction, and you have never reused those addresses, your public key is not exposed on-chain. You are not at risk from at-rest quantum attacks. Continue following address hygiene best practices: generate a fresh address for every receive, never reuse addresses, and avoid sharing extended public keys with third-party services.

If your coins are in P2TR (bc1p) addresses, your public key is exposed in the locking script. Consider moving to a fresh, non-reused P2WPKH address. This is not a permanent solution (it does not protect against on-spend attacks when you eventually spend), but it removes the at-rest exposure until BIP-360 P2MR addresses become available.

If you have ever reused an address (sent multiple transactions to the same address and still hold funds there), your public key is exposed. Move remaining funds to a fresh address.

If you manage exchange or custodial infrastructure, audit your key management practices for address reuse. The Google paper identifies several major exchanges among the top vulnerable addresses by BTC balance. Eliminate reuse, implement Hierarchical Deterministic wallet structures with hardened derivation paths (which prevent a single compromised derived key from exposing the extended private key), and begin planning for PQC-capable address formats.

If you hold P2PK coins and still have the private keys, move them to modern hash-protected addresses now. Every day they remain in P2PK outputs is a day they are exposed to an attacker who may be building a CRQC.

The practical preparation guide later in this series provides more detailed recommendations segmented by role, and the PQC Migration Framework offers structured methodology for institutional migration programs.