By Can Quantum Computers Actually Break Bitcoin?
Most writing about quantum computers and Bitcoin falls into one of two camps: dismissive ("decades away, don't worry about it") or alarmist ("Bitcoin is doomed"). Neither camp tends to cite the actual numbers, and the actual numbers changed more in the first three months of 2026 than in the previous seven years combined. This is an attempt at a third option: precise about what the current research says, honest about what remains uncertain, and specific about which parts of Bitcoin's cryptography are actually exposed versus which aren't.
What's mathematically at risk, and what isn't
Bitcoin's signatures, both the older ECDSA format and the newer Schnorr signatures introduced by Taproot, depend on the same hard problem: given a public key, it should be computationally infeasible to work backward to the private key that generated it. That problem is called the elliptic curve discrete logarithm problem, and it's what secures secp256k1, the specific curve Bitcoin uses. Peter Shor's original 1994 paper, best known for showing that a quantum computer could factor large numbers and break RSA, actually presented two algorithms side by side in the same publication: one for factoring, and one for solving the discrete logarithm problem in any finite group, elliptic curves included, both running in polynomial time on a quantum computer. Factoring got most of the public attention because it's easier to explain to a general audience than elliptic curve arithmetic, but the discrete-log algorithm was there from the start, not a later addition by someone else. That means a sufficiently capable quantum computer would break ECDSA and Schnorr equally; there's no version of Taproot that's more quantum-resistant than legacy addresses, because both ultimately rest on the same mathematical assumption. This isn't a hypothetical weakness discovered by activists looking for a scare story. It's been a known, published, mathematically proven property of elliptic curve cryptography since 1994. What's changed since then isn't the math. It's how close real hardware has gotten to actually running the attack.
The scale of what a working quantum computer would actually do to secp256k1's security is worth stating plainly: it's closer to a light switch than a partial weakening. Under classical brute force, Bitcoin's 256-bit keys offer roughly 128 bits of effective security, a number so large this site's own tool exists specifically to make tangible how far beyond any realistic computation it sits. Under Shor's algorithm, that same key offers approximately zero bits of security: a quantum computer with enough stable logical qubits, the 2026 frontier estimate discussed in detail below puts the number at 1,200 to 1,450, could recover a private key from its public key in minutes rather than never. Compare that to ML-DSA-44, the lattice-based signature scheme NIST has already standardized as a post-quantum replacement: it maintains 128 bits of security even against the best known quantum attack, because the best known quantum attack against it requires more than 1040 operations, a number with no practical meaning at any timescale. That contrast, from unbreakable in practice to broken in minutes, with no partial or gradual weakening in between, is exactly why Bitcoin's response to this threat has to be a wholesale migration to a different kind of cryptography entirely, not an incremental patch to the one it already has.
The estimate has collapsed 20-fold in under a decade
Track the published estimates of how many qubits it would actually take to break secp256k1, and the trend is the real story here, more than any single number. Roetteler and colleagues in 2017 estimated roughly 2,330 logical qubits and 2.3 × 1011 Toffoli gates. Gidney and Ekerå in 2019 put the practical requirement at around 20 million physical qubits on a superconducting architecture, the figure most casual coverage of this topic still quotes as current. Webber and colleagues in 2022 calculated that breaking the curve within a single hour specifically would need roughly 317 million physical qubits. Litinski in 2023 brought the estimate down to about 9 million physical qubits using a photonic architecture. Then, in a single paper published March 31, 2026, a team from Google Quantum AI working with Justin Drake of the Ethereum Foundation and Stanford cryptographer Dan Boneh cut the estimate by another factor of roughly 20: 1,200 to 1,450 logical qubits, 70 to 90 million Toffoli gates, and fewer than 500,000 physical qubits using surface-code error correction at a 10 -3 error rate. A separate March 2026 paper by Cain and colleagues proposed an even more exotic path using reconfigurable atomic qubits that could theoretically need as few as 10,000, though that architecture remains far less mature than the superconducting and photonic approaches the other estimates rely on. None of these papers changed the underlying math. They changed the engineering: better circuit optimization and smarter error-correction strategies, applied to a threat that hasn't gotten mathematically easier, just cheaper to eventually execute.
The runtime estimate compressed just as sharply as the qubit count. Elliptic curve cryptography requires roughly 100 times fewer Toffoli gates to attack than RSA-2048, 70 to 90 million versus roughly 6.5 billion, which is why the Google, Ethereum Foundation, and Stanford paper describes an attack completing in minutes rather than the week-plus that earlier RSA-focused estimates assumed. A minutes-long attack window matters specifically because of how Bitcoin transactions get confirmed, a point worth returning to shortly.
The private key for every Bitcoin wallet on Earth is on this website, even Satoshi's. But even if you try for a million years, you'll never find a funded one.
Try the key collider nowWhat actually exists in a lab right now
Here's the number that matters most for judging urgency, and it's the one most coverage either omits or badly conflates: the difference between a physical qubit and a logical one. Current quantum hardware in 2026 offers somewhere around 1,000 to 1,200 physical qubits at the high end, IBM's 1,121-qubit Condor processor and Atom Computing's 1,180-qubit neutral atom array among the largest. But physical qubits are noisy, prone to errors, and a cryptographically meaningful computation needs logical qubits, error-corrected units built by combining large numbers of physical qubits to suppress that noise. Current best-in-class systems demonstrate logical qubit counts only in the tens to roughly a hundred: Google's Willow chip has 105 physical qubits operating below the error-correction threshold, Quantinuum's Helios system has demonstrated 48 logical qubits, and a Harvard, MIT, and QuEra collaboration has reached up to 96. The ratio between physical and logical qubits in current error-correction schemes runs somewhere around a thousand to one. That means the "fewer than 500,000 physical qubits" figure from the March 2026 paper already accounts for expected improvements in that ratio; achieving it with today's error rates would require dramatically more hardware than exists anywhere on Earth. The paper's own authors are unambiguous about where this leaves things today, stating plainly that "cryptographically relevant quantum computers do not exist as of today." ARK Invest's own March 2026 assessment put it in similar terms, describing the current state as "Stage 0," quantum computers that exist and work, but with no commercially relevant cryptographic capability yet.
A real demonstration that proves less than it sounds like
In April 2026, a researcher won Project Eleven's Q-Day Prize, a competition explicitly designed to track this exact threat, by breaking a 15-bit elliptic curve key on an actual quantum computer, collecting a 1 BTC reward for the largest public demonstration yet of the attack class that threatens every Bitcoin wallet. It's worth being precise about the actual scale of that achievement before it gets rounded up into something scarier: Bitcoin uses a 256-bit curve. Going from 15 bits to 256 bits is closer to the gap between lighting a match and igniting a star than a modest step up, since the computational resources required scale exponentially with key size, not linearly. The demonstration is meaningful as a proof that the attack class works in principle, on real hardware, today. It is not evidence that the timeline to a cryptographically relevant machine has meaningfully shortened beyond what the qubit estimates already describe.
Not all Bitcoin is equally exposed, and the difference matters
This is the part most coverage of this topic gets wrong or skips entirely, and it's the single most important nuance in the whole subject. A Bitcoin address doesn't broadcast your public key by default. Standard address formats hash the public key first, so what actually sits on the blockchain, before you ever spend from that address, is a hash of the key, not the key itself, and Shor's algorithm has no known way to reverse a cryptographic hash the way it reverses a discrete logarithm. The public key only gets revealed on-chain at the moment you spend from an address, included directly in the transaction so the network can verify your signature. That creates a real, meaningful distinction: an address that has only ever received funds and never sent any is protected by that hash right up until the first time it spends. An address that has already sent a transaction, meaning its public key has already appeared on the public blockchain, is exposed permanently, whether that transaction happened yesterday or in 2011.
By multiple independent analyses in 2026, somewhere between 4.49 million and 6.9 million BTC, worth an estimated $650 to $750 billion, sits in addresses where the public key is already exposed on-chain, through address reuse or through early, legacy address formats that exposed the key by design. That range includes an estimated 600,000 to roughly 1.1 million BTC believed to belong to Satoshi Nakamoto, held in some of the earliest address formats Bitcoin ever used, formats that predate the hash-then-reveal design entirely. Separate from that figure, research firm River estimates roughly 1.6 million BTC are permanently lost, inaccessible because no one retains the private keys, a figure this blog has covered from the human side elsewhere. Lost coins carry a particular, permanent version of this risk: they can never be moved to a quantum-safe address, because nobody controls them, which means once a cryptographically relevant quantum computer exists, lost and exposed coins become, in the words of one 2026 analysis, simply "fair game" for anyone with the hardware to take them.
There's also a sharper, more immediate version of this exposure that doesn't require an address to have been used before. Every time you spend Bitcoin, your public key becomes visible the moment you broadcast the transaction, sitting in the mempool for the roughly ten minutes it typically takes to get confirmed into a block. The March 2026 Google, Ethereum Foundation, and Stanford paper explicitly models this scenario, a real-time attack that derives the private key from a freshly broadcast public key and races to spend the funds before the legitimate transaction confirms, estimating a 41% success rate against Bitcoin's standard confirmation window if a cryptographically relevant machine existed today. It doesn't exist today. But the scenario illustrates why "never reuse an address" is necessary but not sufficient once the hardware actually arrives, since even a first-time spend briefly exposes the key during confirmation.
What Bitcoin is actually doing about it
Bitcoin's developer community has moved from treating this as a distant theoretical concern to an active design problem, and the clearest evidence is BIP-360, published February 11, 2026 and merged into Bitcoin's official proposal repository. It introduces a new output type called Pay-to-Merkle-Root, which works similarly to Taproot but removes the specific mechanism, Taproot's key-path spend, that exposes a classical public key on-chain. Instead, P2MR commits only to the Merkle root of a script tree built from post-quantum signature algorithms, meaning no public key vulnerable to Shor's algorithm ever needs to appear on the blockchain at all, even when funds are spent. It uses Dilithium, the lattice-based signature scheme NIST selected as its primary post-quantum standard in 2024, in three security tiers with signatures running 2,420 to 4,595 bytes, considerably larger than a current ECDSA signature's roughly 70 bytes, a real tradeoff in block space and fees that Bitcoin's own ongoing arguments over how that space should be used, covered elsewhere on this blog, will have to absorb. The proposal is deployable as a soft fork through a new SegWit version, giving quantum-safe addresses their own prefix, "bc1z". BTQ Technologies built the first working implementation on a dedicated testnet in March 2026, attracting more than 50 participating miners, over 100,000 mined test blocks, and more than 100 contributing cryptographers, with full wallet tooling for creating and spending P2MR transactions. It's worth being clear about what that testnet is and isn't: a third-party proof of concept, not an implementation inside Bitcoin Core itself, which has made no comparable progress toward shipping this code as of the time of writing. And BIP-360 is deliberately narrow. It protects new transactions going forward. It does nothing for the millions of coins already sitting in exposed legacy addresses, including Satoshi's, which would need their owners to actively migrate them, something that's impossible for lost coins and unlikely for coins whose owners aren't paying attention.
What this actually means if you hold Bitcoin today
None of this calls for panic, and it doesn't call for doing nothing either. The single most useful practical habit, already recommended by security-focused Bitcoin educators well before this year's research, is simply not reusing addresses: generate a fresh address for every incoming payment, and once you spend from an address, treat it as permanently transitioned into the exposed category rather than reusing it again. That single habit keeps the vast majority of a typical holder's coins sitting behind an unrevealed hash rather than an exposed public key, for as long as they choose not to spend. It doesn't eliminate the brief exposure window during an actual spend, the one the March 2026 paper's real-time attack scenario targets, but no quantum computer capable of exploiting that window currently exists, and BIP-360 or something like it will very likely be available as a voluntary upgrade path well before one does. For anyone holding coins in very old address formats, particularly the earliest pay-to-public-key style addresses that expose a key immediately rather than only on spend, moving those funds to a modern, hash-protected address format today, long before any quantum-safe migration is even necessary, closes the exposure gap immediately using cryptography that already exists and needs no new consensus rules at all.
The actual range of credible timelines
Serious estimates of when a cryptographically relevant quantum computer might exist span a wide range, and it's worth hearing the actual spread rather than one cherry-picked number. Adam Back, the cryptographer and CEO of Blockstream, has argued the practical threat is 20 to 40 years away. DARPA's own managing director stated in March 2026 that it now "seems more likely than not" that a utility-scale quantum computer, a somewhat different bar than cryptographically relevant specifically, gets built by 2033. ARK Invest's own hardware projections, even in an optimistic scenario, don't place the industry at 500,000 physical qubits before 2033 to 2035. Policy responses have started assuming something in that same window: an eighteen-nation joint European statement has called for high-risk systems to complete post-quantum migration by 2030 and broader adoption by 2035, the EU's Cyber Resilience Act is moving toward a "quantum-safe-by-design" requirement, and Google itself, the author of the March 2026 paper that reset the whole conversation, has set its own internal deadline of 2029 to migrate its infrastructure to post-quantum cryptography, treating the "harvest now, decrypt later" risk, that someone could record encrypted data today and break it once the hardware catches up, as reason enough to move well ahead of any confirmed timeline.
"Harvest now, decrypt later" is usually explained through the lens of encrypted communications: an adversary records today's encrypted traffic, unable to read it now, and simply waits for a quantum computer capable of decrypting the archive later. Bitcoin's version of this risk works differently and, in one sense, more publicly. There's no need to secretly record anything. Every public key that has ever been exposed on-chain, through address reuse or an old address format, is already sitting in plain sight in the blockchain's full history, permanently and publicly archived by the very design that makes Bitcoin auditable at all. The waiting isn't being done by an attacker hoarding intercepted data. It's built into the ledger itself, openly, for anyone willing to wait for the hardware.
The honest summary sits between the two camps this piece opened by rejecting. No machine capable of breaking Bitcoin's cryptography exists, and every aggressive, well-credentialed 2026 paper on the subject says so explicitly. The gap has also closed by a factor of roughly 20 in under a decade, entirely through smarter mathematics rather than new hardware, which is exactly the kind of trend that justifies building the migration path now rather than waiting for a confirmed date that may arrive with less warning than anyone currently expects. For more on Bitcoin's actual security margin against classical brute-force attacks, a completely different and far less pressing question, see how absurd Bitcoin's security margin really is, and for what happens to coins nobody can move at all, quantum-vulnerable or not, see Bitcoin's real inheritance problem. For the mechanics of the Taproot upgrade this whole migration has to work around, see what Taproot actually is.