Will a Quantum Computer Break Bitcoin?

The question gets asked in two registers, and neither is much use. One is that quantum computers will drain every wallet within a couple of years. The other is that it is all hype and nothing needs doing. The arithmetic is public, so it is possible to just do it.

Everything below is calculated rather than cited, and the assumptions are stated so you can argue with them.

What actually secures a Bitcoin key

Bitcoin signs transactions with ECDSA over secp256k1, a 256-bit elliptic curve. Security rests on the elliptic curve discrete logarithm problem: given a public key, recovering the private key requires solving a discrete log, which no classical algorithm does in any practical time.

Shor's algorithm does solve it, in polynomial time. So the question is not whether a quantum computer can break a Bitcoin key. It is how large that computer would have to be.

Step one: logical qubits

An elliptic curve discrete logarithm over an n-bit prime field needs roughly 9n logical qubits under the standard construction. For secp256k1, n is 256:

9 x 256 = 2,304 logical qubits

Worth noting in passing that this makes a 256-bit elliptic curve key a smaller quantum target than a 2048-bit RSA key, which needs about 2n + 3, or 4,099 logical qubits, despite the two offering comparable classical security. Elliptic curves are more efficient classically and more fragile quantumly.

Step two: physical qubits, which is where it gets expensive

Logical qubits are not free. Under the surface code, each one is built from many physical qubits, and how many depends entirely on the physical error rate. The logical error rate falls as roughly 0.1(p/p_th)^(d/2) for physical error rate p, a threshold p_th near 1 percent, and code distance d. Each logical qubit costs about 2d^2 physical ones.

Requiring a logical error rate of 1e-15, low enough that an algorithm running for hours does not simply fail, fixes d:

Physical error rate   Code distance   Physical per logical
1%                    n/a             never: at or above threshold
0.5%                  95              18,050
0.1%                  29              1,682
0.01%                 15              450

The top row is the most important line in this article. At or above the threshold, error correction does not work at all, and no number of qubits fixes it. Below threshold the overhead falls fast, which is why gate fidelity rather than qubit count is the number worth tracking, and why a headline about a thousand-qubit processor tells you much less than a fidelity figure does.

The number

At 0.1% physical error rate (conservative):
  2,304 x 1,682  = 3,875,328 physical qubits

At 0.01% physical error rate (best two-qubit fidelity reported today):
  2,304 x 450    = 1,036,800 physical qubits

Applying IBM's claimed tenfold overhead reduction to the conservative figure:
                 ~387,533 physical qubits

So somewhere between roughly 390,000 and 3.9 million physical qubits, depending on which assumptions you accept, and the spread is entirely driven by gate fidelity rather than by anything about Bitcoin.

For scale: the largest processor available through this platform is 108 physical qubits with no error correction at all. That is our catalogue rather than the state of the art. Machines with more than a thousand physical qubits exist, two-qubit fidelity has passed 99.99 percent, and QuEra has demonstrated 96 logical qubits from 448 physical ones. Measured against the field rather than against what we resell, the gap is smaller than 35,883x, and it is still four orders of magnitude.

Treat 3.9 million as a textbook upper bound rather than a forecast. The arithmetic is deliberately naive: generic surface code, no algorithmic optimisation, no co-design. The real figure will be lower, possibly much lower. It will not be small.

Which coins are actually exposed

This is the part that gets skipped, and it is the part that decides how worried to be.

A quantum attack needs the public key. Bitcoin addresses do not generally publish one. In a pay-to-public-key-hash output, the chain stores a hash of the public key, and the key itself is revealed only when the coins are spent. A hash is not vulnerable to Shor's algorithm, so an address that has received funds and never spent them is not exposed by this attack at all.

What is exposed is anything where the public key is visible on-chain: early pay-to-public-key outputs, which published the key directly, and any address that has ever spent, since spending reveals the key in the signature. Reused addresses are therefore permanently exposed once they have been used once.

There is also a narrower window that matters more than the long-term one: between broadcasting a transaction and its confirmation, the public key is public and the coins have not yet moved. An attacker with a sufficiently fast quantum computer could derive the key and race a competing transaction. That requires the machine described above and enough speed to beat block time, which stacks two hard problems rather than one.

Mining is not the risk, and this is the most common error

Grover's algorithm gives a quadratic speedup on unstructured search, which includes hash preimages. Applied to SHA-256 that takes 2^256 operations down to about 2^128.

2^128 is not a number that becomes tractable. It is still comfortably beyond any physical computer, quantum or otherwise, and the quadratic speedup is also fragile: it assumes serial oracle queries, and ASICs already perform hashing at a throughput no near-term quantum device approaches. Hash-based security is weakened on paper and untouched in practice. Doubling hash output length restores the margin completely if anyone ever needs it.

The threat is to signatures, not to mining, and not to the hash functions.

Harvest now, decrypt later does not quite apply here

The standard warning for encrypted traffic is that an adversary captures ciphertext today and decrypts it when hardware arrives. Anything with a confidentiality lifetime measured in decades is already exposed to a machine that does not yet exist.

Digital assets have a different shape. There is no ciphertext to harvest, because a signature is not an encryption. What an adversary can do is enumerate every exposed public key on a public ledger today, at leisure, and hold that list against the day the hardware exists. The ledger is the harvest, and it has already happened. That is a slower problem than the encrypted-traffic one, and it is not a smaller one, because the exposed set only grows.

What would actually fix it

NIST has standardised post-quantum signature schemes, and the migration path for Bitcoin is a signature scheme change, which means a soft fork and the coordination that implies. Hash-based schemes are the natural fit for a chain that already depends on hash security, and they are conservative in exactly the way this problem wants.

The engineering is understood. The hard part is coordination and the very large set of coins whose keys are already published and whose owners may not be reachable. A migration that requires every holder to move funds is not a migration that completes. The general standards picture is covered in the post-quantum cryptography primer, and the full resource-estimation working is on the cryptography benchmark page.

Where the honest uncertainty is

The weakest number above is the surface-code overhead. It assumes a generic code, a specific target logical error rate, and no algorithmic co-design, and every one of those assumptions is being actively attacked by people whose job it is. If the overhead falls by another order of magnitude, secp256k1 lands near 40,000 physical qubits, which is a different conversation entirely.

What is not uncertain is the direction, and that gate fidelity is the variable to watch rather than qubit count. A press release about qubit numbers tells you almost nothing. A two-qubit fidelity figure tells you a great deal.

What actually runs today

It is worth grounding all of this in what is currently possible, because the gap is the point. A 1001-qubit error-correcting code circuit runs on a stabilizer engine in milliseconds for a tenth of a cent, exactly, with a public certificate at api.zksf.org/certify/86125198363b4d02. That sounds enormous until you notice it is a Clifford circuit, which the Gottesman-Knill theorem says is classically tractable at any width. It is not progress toward breaking secp256k1. It is a different category of problem entirely, and knowing which category a result belongs to is most of the literacy this subject requires.

Shor's algorithm is not Clifford. That is precisely why it is hard, and why the numbers above are what they are.

You can run the algorithms this article is about, at sizes that fit, and read the accuracy statement on every result. Start in the browser with no account at the circuit sandbox, or run the same circuits on hosted engines and real quantum processors through one API. The Android app runs the same engines if you want to check something from a phone. The applications benchmarks carry the full resource-estimation working, alongside the industrial problems where classical computing currently wins, which is most of them.