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.

The published estimates below are cited with their dates and sources. Everything else is calculated or measured on our own engines, and the assumptions are stated so you can argue with them.

How many qubits does it take to break Bitcoin?

Between about 10,000 and 500,000 physical qubits, according to the estimates published in 2026, and the spread is a trade between size and speed. The smaller designs take days to months to recover one key, and the largest takes minutes. All of them describe error-corrected machines that have not been built yet.

Everything here is runnable on your own circuit. Try it in the console

Published estimates for recovering one secp256k1 private key, as of September 2026:

These are designs rather than machines. Each assumes low error rates held across the whole device while error correction runs for the full length of the attack, and IonQ says its figure matches the scale of systems on its public roadmap for around 2028. For comparison, the most cited figure in 2022 was 13 million physical qubits for an attack lasting a day (Webber and colleagues). Most of the fall since then came from better algorithms and error-correcting codes rather than from better hardware.

On real hardware, the largest public key recovery so far is a 15-bit elliptic curve key, which won Project Eleven's Q-Day Prize in April 2026 with a variant of Shor's algorithm. The previous public record, in September 2025, was a 6-bit key on IBM's 133-qubit processor.

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.

We ran a quick 7-bit attack on our CPU and GPU engines as a test

Rather than take the polynomial-time claim on trust, we ran Shor's discrete logarithm algorithm against real elliptic curves on our own engines and recovered the private keys from the public ones. The curves are real, the group law is real elliptic curve point addition, and the private key appears nowhere in the circuit. It is used once, at the end, to check the answer.

Key size  Curve                         Qubits  Two-qubit gates  Private key
3 bits    y^2 = x^3 + 4x + 1  / F_5        9              328  recovered
4 bits    y^2 = x^3 + 2x + 1  / F_11      12            1,924  recovered
5 bits    y^2 = x^3 + x + 10  / F_23      15           10,090  recovered
6 bits    y^2 = x^3 + x + 6   / F_53      18           49,758  recovered
7 bits    y^2 = x^3 + x + 34  / F_107     21          235,470  recovered

Every one of those runs returned the correct private key. The 7-bit case took about seventy seconds of exact simulation, and the same 7-bit circuit on our GPU tier (exact.gpu, 21 qubits, 64 shots) returned the correct key in 66 seconds.

Run on our engines

Shor's discrete logarithm algorithm on real elliptic curves y² = x³ + ax + b over F5 to F107, recovering each private key from its public key at 64 shots. On 25 September the 7-bit recovery ran again on exact.tpu, a Google TPU, recovering the same key from 25 usable shots in 271 seconds. Submitted to each kind of compute we offer, on 10, 24 and 25 September 2026. Every figure below is a real job on the service, priced as any customer would be priced.

Device	Engine	Kind	Qubits	Result	Cost
	exact.cpu	CPU	9	3-bit key recovered, d = 7, in 0.14 s *	$0.0001
	exact.cpu	CPU	12	4-bit key recovered, d = 11, in 0.57 s *	$0.0001
	exact.cpu	CPU	15	5-bit key recovered, d = 19, in 8.40 s *	$0.0002
	exact.cpu	CPU	18	6-bit key recovered, d = 35, in 6.70 s *	$0.0002
	exact.cpu	CPU	21	7-bit key recovered, d = 67, in 70.5 s *	$0.0020
	exact.gpu	GPU	21	7-bit key recovered, d = 67, in 66 s certificate	$0.1066
	exact.tpu	TPU	21	7-bit key recovered, d = 67, in 271 s certificate	$0.4534
	neural.tpu	TPU	—	Shor's algorithm is a circuit, not a Hamiltonian, so it does not reach the neural tier	—

* Run in-process on the exact.cpu engine rather than submitted as billed jobs. Each cost is the measured runtime priced at the rate the service quotes for CPU work, with its $0.0001 minimum. The steps are in the docs.

The same problem is yours to run: every instance here is seeded, so it rebuilds exactly. Open the console and a cost estimate is free before anything executes.

Read the gate column rather than the qubit column. Width grows politely, three qubits per bit of key, which is why 7 bits still fits on a workstation.

The two-qubit gate count grows by a factor of about five per bit, from 328 to 235,470 across those four extra bits, and it is the gates a real device has to survive. Depth, not width, is what stands between this algorithm and a real key, which is the opposite of the way qubit-count headlines frame the problem.

Re-running the identical circuits under a depolarizing noise model locates the wall precisely. The 3-bit key still comes out at 99.0 percent two-qubit fidelity, which is an ordinary superconducting device.

The 4-bit key, roughly six times as many gates, needs better than 99.8 percent and fails below it. One extra bit of key moved the hardware requirement across the entire range of machines in commercial service, which is the clearest demonstration we have that gate fidelity rather than qubit count is the number to watch.

Other circuit constructions have reached further on real hardware, as the 15-bit record above shows. The gate counts here belong to this construction, which builds every step from generic gates.

Scaling that table to 256 bits is not a matter of continuing it. Our oracle is built by enumerating the curve's points, which is fine at seven bits and is itself the classical attack at any real size.

The construction that scales is the field-arithmetic one, and the next three sections work out what it costs by the textbook method. The full working, the curve parameters and the code are on the cryptography benchmark page.

The textbook method, step one: logical qubits

An elliptic curve discrete logarithm over an n-bit prime field needs roughly 9n logical qubits under the textbook construction, published by Roetteler, Naehrig, Svore and Lauter in 2017 (arXiv:1706.06752). Their exact bound is 9n + 2⌈log2 n⌉ + 10. For secp256k1, n is 256:

9 x 256 = 2,304 logical qubits
Exact bound: 2,304 + 16 + 10 = 2,330

By the same textbook arithmetic, a 256-bit elliptic curve key is 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.

The textbook method, step two: physical qubits

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 textbook number, and why the published ones are lower

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 the textbook method gives somewhere between roughly 390,000 and 3.9 million physical qubits, depending on which assumptions you accept, and the spread is driven by gate fidelity rather than by anything about Bitcoin.

The 2026 estimates in the table at the top come in between about 8 and nearly 400 times below the conservative textbook figure. Each replaces generic assumptions with specific ones: arithmetic circuits that need about 1,200 to 1,500 logical qubits rather than 2,304, scheduling built around one kind of hardware and, in the neutral-atom and trapped-ion designs, error-correcting codes that pack many logical qubits into far fewer physical ones than the surface code does.

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. What no machine has shown yet is error correction running across thousands of qubits for the length of an attack, which every design in the table assumes.

Which coins are exposed, and why attack speed decides it

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, and most Bitcoin addresses do not 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 of that kind that has received funds and never spent them is not exposed by this attack at all.

What is exposed falls into two groups, and they need machines of different speeds.

Keys already on the ledger: a slow attack is enough

Some public keys are visible before anyone spends. Early pay-to-public-key outputs published the key directly, and by Google Quantum AI's count they hold a little over 1.7 million bitcoin. Taproot outputs, in use since 2021, also store a public key in the output itself rather than a hash of it. And any address that has ever spent has revealed its key in the signature, so a reused address stays exposed from its first spend onward.

None of these need speed. An attack taking 25.7 days per key, as in IonQ's estimate, reaches all of them. At that pace one machine makes about 14 attempts a year, each succeeding about 63 percent of the time by the paper's own estimate, which points at the largest exposed balances first rather than every wallet at once.

Keys revealed by a transaction: only a fast attack can race it

Spending from a hashed address reveals its public key when the transaction is broadcast, and the coins stay where they are until a block confirms it, about 10 minutes on average. An attacker who derives the private key inside that window can broadcast a competing transaction.

Only the fastest designs are in range. Google Quantum AI's estimate puts a superconducting attack at roughly 9 to 23 minutes, close to Bitcoin's average block time, and its authors do not expect the slower neutral-atom and trapped-ion designs to manage this kind of attack. Which group of coins is at risk first depends on which kind of machine is built first.

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 estimates are heading

The textbook number rests on a generic error-correcting code, a fixed target logical error rate and no co-design between algorithm and hardware, and each of those assumptions has since been improved on. Three groups published estimates within six months of each other in 2026, by different routes, and they are unlikely to be the last.

What has not changed is the variable to watch. A press release about qubit numbers tells you almost nothing. A two-qubit fidelity figure, and a logical error rate held over a long computation, tell 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 hundredth 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.