Key takeaways

  • A hypothetical quantum theft starts with an exposed public key, not a mysterious ability to read a wallet or reverse every Bitcoin address.
  • Shor’s algorithm could recover the private key behind Bitcoin’s elliptic-curve signatures on a sufficiently powerful, fault-tolerant quantum computer. No publicly demonstrated machine can do this today.
  • Some outputs reveal a public key while they sit unspent; others reveal it only when their owner spends. That difference changes the attack window.
  • A mathematically valid forged signature would look valid to today’s consensus rules. Preventing the scenario requires preparation before such a machine exists.

Can a quantum computer steal Bitcoin? In theory, yes—but only through a specific attack on exposed public keys, and not with the quantum computers demonstrated today. The phrase “break Bitcoin” conceals the useful questions: Which key is visible? How quickly could an attacker derive its secret counterpart? Could a competing transaction win confirmation? And what would Bitcoin’s rules accept?

The answers depend on the output being attacked. A coin sent to a public-key hash is not in the same position as a coin whose public key is already written in the output. A transaction waiting for confirmation creates a different opportunity from an output that has sat exposed for years. To see why, start with the ordinary act of spending.

A spend is an authorization, not a decryption

Bitcoin’s ledger is public. There is no encrypted balance that a quantum machine needs to unlock. An unspent transaction output, or UTXO, is a piece of bitcoin controlled by conditions in a locking script. The most familiar condition requires a valid digital signature associated with a key.

A wallet starts with a private key, a secret number. It derives a public key, a curve point that others can use to check a signature. When the owner spends, the wallet signs the transaction; nodes check the signature and the other spending conditions. Bitcoin’s transaction developer guide walks through this relationship using pay-to-public-key-hash (P2PKH). Bitcoin historically uses ECDSA, while BIP 340 specifies Schnorr signatures for Taproot. Both rely on the secp256k1 elliptic curve.

The distinction between a private key and its public key is essential. Knowing the public key does not let an ordinary computer efficiently calculate the private key. That one-way relationship is what makes public verification possible. A quantum attack would target that relationship, not decrypt the blockchain and not guess a wallet’s recovery phrase.

Where Shor’s algorithm enters

Peter Shor’s original result gives a quantum algorithm for discrete logarithms. Applied to the elliptic-curve problem behind secp256k1, it supplies a route from a known public key to its private scalar, assuming a sufficiently capable fault-tolerant machine. Both ECDSA and Schnorr inherit this kind of exposure because each depends on the same discrete-logarithm hardness, although their signature formats differ.

Imagine an attacker who sees an unspent output’s public key. If the attacker could calculate the corresponding private key, they could sign a transaction spending that output to themselves. Current nodes would verify the signature successfully. They cannot tell whether the signer obtained the key legitimately or through an impossible-to-detect mathematical shortcut. The eventual result would still depend on fees, competing transactions, network propagation, and confirmation.

That is a conditional scenario, not a report of a working exploit. Google Quantum AI’s 2026 resource-estimate paper explores optimized circuits for the secp256k1 problem. It describes logical qubits and very large numbers of operations, not a machine that recovered a real Bitcoin key. Error correction, physical hardware overhead, runtime, and reliability remain decisive constraints. An algorithm on paper can make an engineering problem urgent to study without making theft possible today.

For a broader separation of present capability and long-term risk, see our 2026 Bitcoin quantum-risk overview.

An address is not always a public key

People often say that a Bitcoin address “hides the key.” That is true of some common constructions at a particular point in their life, but it is not a universal rule. An address is a human-facing encoding of a spending destination. The actual exposure depends on the output script and what earlier transactions have revealed.

In P2PKH and native pay-to-witness-public-key-hash (P2WPKH), the output commits to a hash of a public key. A hash is a compact fingerprint; it does not simply display the key. When the owner spends, the public key appears in the unlocking data so nodes can verify the signature. BIP 141 defines the witness forms, while the Bitcoin developer guide shows the older P2PKH script and its revealed key.

Other output types expose a key from the start. Early pay-to-public-key (P2PK) scripts include it directly. BIP 341 defines Taproot outputs whose 32-byte witness program represents a tweaked public key. Taproot improves many things, but its Schnorr output key is not a post-quantum shield.

Script-hash outputs add another wrinkle. P2SH or P2WSH initially commit to a script hash; when spent, the redeem or witness script may reveal public keys. Multisignature and other scripts cannot be assessed from an address prefix alone. The practical unit of analysis is the unspent output plus any relevant on-chain history, not the casual label “Bitcoin address.” We compare these cases in detail in which Bitcoin addresses face the greatest quantum risk.

Two different clocks: exposed at rest or exposed in flight

An at-rest target has a public key visible before its owner broadcasts a spend. A P2PK output, a Taproot output, or a hash-based output tied to a previously revealed key could fit this description. A hypothetical attacker would have more than one block interval to work. The key might have been public for years. The owner could still move the coins first if a suitable migration path exists, so exposure is not the same as certain loss.

An in-flight target begins with a public-key hash or script hash whose relevant key has not been revealed. Spending exposes verification material in a pending transaction. The attacker would need to learn the key, derive its private counterpart, construct a conflicting valid spend, and have that spend confirmed before the intended transaction settles. That is a race against both computation time and Bitcoin’s transaction-confirmation process.

It is tempting to call the window “ten minutes,” but blocks arrive probabilistically. A transaction can confirm quickly or wait; fees and mempool policies influence propagation and selection. A capable future machine might change the risk calculation, but a fixed attack time cannot be deduced from an average block interval. Nor does one confirmation magically change the underlying key: address reuse may leave other UTXOs under the same already-revealed public key.

The phrase “harvest now, decrypt later” is also easy to misapply. It describes recording protected data today for later decryption in systems that actually encrypt information. Bitcoin transactions are already public, and the spending threat is usually later key recovery and signature forgery, not decrypting a stored transaction. An adversary can archive exposed Bitcoin public keys now, but that is a different mechanism from decrypting secret traffic. The distinction matters when judging which outputs remain targets after a future migration.

What would an attacker need to demonstrate?

An impressive qubit count is not enough. A credible attack would require reliable logical qubits, a long sequence of fault-tolerant gates, error correction that works throughout, and a physical implementation fast enough for the chosen target. Researchers can reduce resource estimates while experimental hardware progresses; neither trend by itself proves an attack is operational.

The benchmark also depends on the target. Deriving one known key for an exposed-at-rest output is different from deriving it inside a pending-transaction window. Even a future machine that could do the former might not always do the latter economically or in time. Publicly verifiable evidence would be a completed secp256k1 discrete-logarithm calculation at relevant scale, not merely a smaller demonstration problem or a vendor roadmap.

No one should infer from the theoretical pathway that today’s Bitcoin owners face a quantum thief in the mempool. The available primary research establishes a vulnerability of the cryptographic assumption under a sufficiently powerful future machine and studies resources for exploiting it. It does not establish that the machine has been built.

What changes the ending?

If Bitcoin eventually supports an appropriately reviewed post-quantum spending path, holders could move outputs before a quantum adversary can recover their existing keys. That entails protocol rules, wallets, hardware, custody operations, education, and time. It also raises the difficult question of outputs controlled by people who never appear to move them. Our post-quantum migration explainer separates the cryptographic options from the coordination work.

The attack story is useful precisely because it is concrete. A public key appears; a hypothetical machine derives its private key; a forged signature authorizes a competing spend under existing rules. Every step has conditions, and today the crucial machine is missing. The responsible response is to test those conditions, build migration options, and avoid describing a theoretical path as a present theft.

Sources