Is Bitcoin quantum safe?

Bitcoin is not quantum safe in the long term: ownership of coins is proven with ECDSA and Schnorr signatures over the secp256k1 curve, and both fall to Shor's algorithm on a sufficiently large quantum computer. No machine disclosed as of early 2026 comes anywhere near that capability, so there is no immediate emergency, but millions of coins already sit behind exposed public keys and any migration would take years.

#What the signatures protect

Every spendable bitcoin is locked in an unspent transaction output, and for the overwhelming majority of coins the spending condition is a digital signature scheme over the secp256k1 elliptic curve. ECDSA has secured outputs since the network launched in 2009, and Schnorr signatures were added by BIP 340 with the 2021 taproot upgrade. Both schemes rest on the hardness of the elliptic curve discrete logarithm problem, which Shor's algorithm solves in polynomial time; quantum threat to ECDSA covers the mathematics and the machine sizes involved. Bitcoin's other cryptographic pillar, the SHA-256 hash function used in mining and address derivation, faces only a quadratic speedup from Grover's algorithm, which is why quantum computers and proof-of-work mining is a far smaller concern. The quantum question about Bitcoin therefore reduces to a question about signatures: who can see a public key, and when.

#The two exposure windows

Shor's algorithm needs the public key itself as input. An address that only commits to the hash of a key gives an attacker nothing to work with. This splits Bitcoin's exposure into two distinct windows.

The first window is keys at rest. Any output whose public key is already visible on chain can be attacked at leisure once a cryptographically relevant quantum computer exists. The ledger is public and permanent, so this is the signature analogue of harvest now, decrypt later: the disclosure has already happened, and only the attacker's hardware is missing.

The second window is the confirmation race. Spending any output reveals its public key inside the transaction. Between broadcast and confirmation, an attacker able to compute a discrete logarithm within minutes could sign a conflicting transaction that sends the same coins elsewhere and try to get it confirmed first. Aggarwal and coauthors analyzed this live-transaction attack in 2017, and it is the reason hash-guarded addresses are only a partial defense: every coin's key is exposed at least briefly whenever it moves.

The two windows call for different defenses. Coins at rest can be protected only by moving them to outputs whose keys are not exposed, an action each holder must take individually. The confirmation race can be narrowed by protocol changes, such as the commit-reveal schemes described below, but it cannot be fully closed while transactions must reveal classical public keys in order to be validated.

#How many coins already have exposed keys

A widely cited Deloitte analysis estimated that roughly 25 percent of all bitcoin, more than 4 million BTC at the time of the study, sits in outputs whose public keys are already visible. The exposed set has two main populations. The first is pay-to-public-key (P2PK) outputs, the format used by early coinbase rewards in 2009 and 2010; these contain the key outright and include the roughly 1 million BTC generally attributed to Satoshi Nakamoto, coins that have never moved and, if their keys are lost, can never be migrated to a safer format by anyone. The second population is reused pay-to-public-key-hash (P2PKH) addresses: the first spend from an address reveals its key, and every coin sent back to the same address afterward is exposed at rest from that point on.

#Exposure by output type

Taproot deserves the extra note. BIP 341 places an x-only public key directly in every P2TR output, so taproot coins are key-exposed at rest by design; the reasoning behind that choice and the debate around it are covered in taproot and quantum key exposure. The hash shield of legacy and segwit outputs is also weaker in practice than the table suggests, because address reuse, wallet change handling, and the confirmation race all leak keys over time.

#How large the attacking machine must be

Roetteler, Naehrig, Svore, and Lauter estimated in 2017 that computing a 256-bit elliptic curve discrete logarithm requires about 2330 logical qubits and roughly 130 billion Toffoli gates. Logical qubits are the error-corrected abstraction; each one costs hundreds to thousands of physical qubits to maintain. Webber and coauthors translated the attack into physical requirements in 2022: under superconducting-hardware assumptions, breaking a key within Bitcoin's roughly 10-minute block interval would take on the order of 1.9 billion physical qubits, within 1 hour about 317 million, and within 1 day about 13 million. As of early 2026 the largest publicly disclosed processors hold on the order of 1000 physical qubits, and error-corrected demonstrations involve tens of logical qubits, so the gap spans several orders of magnitude. The uncertainty runs in both directions: error correction has progressed faster than many expected, hardware roadmaps routinely slip, and the eventual arrival date, often called Q-Day, is an estimate rather than a schedule. The physical-qubit figures are also not fixed constants; they assume particular error rates and correction codes, and improvements in either could lower the requirement substantially, which is why such estimates are revisited every few years rather than treated as final.

#Proposed mitigations

BIP 360, part of the effort often called QuBit, drafts a pay-to-quantum-resistant-hash (P2QRH) output type: coins commit to a hash of post-quantum verification data, with candidate signature schemes drawn from the NIST standards such as ML-DSA and SLH-DSA. Deployed as a soft fork, it would give holders a quantum-safe destination to move coins to well before any attack is practical. Signature size is the recurring cost: post-quantum signatures run from under 1 kilobyte to several kilobytes, against 64 to 72 bytes today, with direct consequences for block space; post-quantum blockchains surveys how other networks absorb that overhead. Separately, commit-reveal spending schemes discussed on the bitcoin-dev mailing list and summarized by Bitcoin Optech could let even exposed-key coins move safely, by committing to a spend before the key is revealed so a quantum attacker cannot substitute their own transaction. The hardest question is governance rather than cryptography: if vulnerable coins are not migrated in time, the network must choose between letting a quantum attacker claim them and freezing them by consensus rule, a debate commonly summarized as burn versus steal. As of early 2026 that question is unresolved and actively argued.

#An honest reading

Three facts hold at once. First, no known machine can break secp256k1, and published estimates put the requirement millions of physical qubits away from disclosed hardware. Second, the exposure is structural: more than 4 million BTC sit behind keys that are already public, and coins whose owners are absent, deceased, or simply inattentive will never migrate themselves, which is what makes the burn-versus-steal question unavoidable. Third, migrations are slow: earlier upgrades such as segwit and taproot took years to reach wide use, and a signature migration touches every holder rather than only miners and node operators. Neither alarm nor dismissal fits this evidence. Bitcoin is not in danger today, but the work that would make it safe, standardized algorithms from post-quantum cryptography, an agreed output type, and an orderly migration path, is precisely the kind of work that takes the longest to finish.