Key takeaways

  • Bitcoin is not “blockchain encryption.” It relies on digital signatures for authorization and cryptographic hashes for commitments, addressing, and proof of work.
  • A sufficiently large, fault-tolerant quantum computer running Shor’s algorithm could derive a private key from an exposed elliptic-curve public key. No public machine can do that to Bitcoin today.
  • Grover’s algorithm gives a quadratic speedup for generic search. That changes the security margin of hashes, but it does not simply “break SHA-256” in the way Shor threatens elliptic-curve signatures.
  • Migration is a protocol and coordination problem as much as a cryptography problem: new rules, wallets, exchanges, custody systems, hardware, and decisions about inactive coins all matter.

Quantum computing and Bitcoin are often discussed in absolutes: either quantum machines are irrelevant forever, or they are about to empty every wallet. Neither position reflects the evidence available on September 15, 2026.

The risk is real but conditional. Bitcoin’s signatures depend on problems that Shor’s algorithm could solve on a sufficiently capable quantum computer. But “the algorithm exists” is not the same as “the machine exists.” Today’s experiments remain far from the sustained fault-tolerant operation an attack requires.

Understanding the distinction starts with what Bitcoin’s cryptography actually does.

For the underlying concepts—from qubits and interference to hardware and error correction—start with the complete guide to quantum computing.

Bitcoin uses signatures and hashes—not blockchain encryption

Bitcoin’s public ledger is designed to be read and independently verified. Ordinary transaction data is not encrypted. Calling Bitcoin “encrypted” obscures the two main cryptographic tools it actually uses.

Digital signatures authorize spending. A wallet creates a private key and derives a public key on the secp256k1 elliptic curve. To spend, the owner produces a signature that nodes can verify against the public key. Bitcoin uses ECDSA for older output types and Schnorr signatures for Taproot, as specified in BIP 340. The private key is meant to remain secret; the public key and signature are verification material.

Cryptographic hashes create compact, tamper-evident commitments. SHA-256 is used in proof of work, block and transaction structures, and other protocol constructions. HASH160—SHA-256 followed by RIPEMD-160—appears in common public-key-hash output types. Hashes are one-way functions, not encryption: there is no decryption key that reverses them.

That distinction matters because quantum algorithms do not affect every cryptographic primitive in the same way.

What Shor’s algorithm changes

Peter Shor’s original work showed that a quantum computer can solve integer factoring and discrete logarithms in polynomial time. The relevant problem for Bitcoin is the elliptic-curve discrete logarithm problem: given a public point on secp256k1, find the private scalar that generated it. Classical computers are not known to do this efficiently. A large fault-tolerant quantum computer running Shor’s algorithm could.

If an attacker recovered a private key from a public key, the attacker could create a valid signature and attempt to spend the associated bitcoin. The network would see a mathematically valid authorization; it could not infer which signer was the legitimate owner.

The threat applies to both Bitcoin’s ECDSA and Taproot’s Schnorr signatures because both use secp256k1 discrete-log security. Schnorr is an important improvement to Bitcoin, but it is not a post-quantum signature scheme.

The latest major resource study is sobering but easy to misread. In 2026, Google Quantum AI researchers and collaborators estimated that a logical circuit for the 256-bit secp256k1 problem could use at most roughly 1,200 logical qubits and 90 million Toffoli gates, or a different tradeoff of roughly 1,450 logical qubits and 70 million Toffoli gates. These are logical resources: reliable, error-corrected qubits and operations. Turning them into a working machine requires substantial physical-qubit overhead, error correction, connectivity, control, and enough speed to complete the computation before the target transaction confirms or the system fails.

The study refines the engineering target. It does not report a derived Bitcoin private key or a machine capable of producing one.

For the transaction-level sequence—including the difference between a visible key at rest and a key revealed during a spend—read how a hypothetical quantum Bitcoin theft would actually work.

Grover’s algorithm is a different kind of concern

Lov Grover’s quantum search algorithm can find an item in an unstructured space in roughly the square root of the classical number of queries. In simplified security language, an idealized quantum search against an n-bit hash preimage changes a 2^n-scale search into roughly 2^(n/2) quantum queries.

That differs fundamentally from Shor’s polynomial-time attack on elliptic-curve discrete logarithms. Grover does not reveal a private key from a public key. It supplies a quadratic speedup with demanding circuit depth and error-correction costs.

For Bitcoin mining, a hypothetical quantum miner would still face real implementation costs and the network’s difficulty adjustment. For SHA-256 preimages, the idealized 256-bit security level becomes approximately 128 bits against generic quantum search—still an enormous search space. Some address constructions use 160-bit HASH160 outputs, whose theoretical quantum preimage margin is lower, although exploiting that fact is not equivalent to instantly stealing a coin. The exact script, revealed data, timing, and available quantum resources all matter.

The useful summary is: Shor targets the algebra behind Bitcoin’s signatures; Grover reduces the margin of brute-force search against hashes. They should not be described as the same attack.

Our Shor-versus-Grover comparison puts the two algorithms, their assumptions, and their mining implications side by side.

Which Bitcoin outputs expose public keys?

“An address hides the public key” is only sometimes true, and often only temporarily.

  • Pay-to-public-key (P2PK) outputs, common in Bitcoin’s early history, place a public key directly in the locking script.
  • Pay-to-Taproot (P2TR) outputs place a tweaked 32-byte public key directly in the output. BIP 341 explicitly contrasts this with earlier constructions that store a public-key or script hash.
  • P2PKH and P2WPKH outputs initially contain a hash of a public key. When they are spent, the public key is revealed in the transaction input. If an address is reused and still controls other unspent outputs, that exposure persists for those coins.
  • P2SH and P2WSH commit to a script. Spending normally reveals the redeem script or witness script, which may contain one or more public keys.

This creates two timing categories. In a long-exposure scenario, the public key is already visible before an attacker acts—for example, in P2PK, P2TR, or reused-key outputs. In a short-exposure scenario, a spender reveals the public key while broadcasting a transaction, and a quantum attacker would need to recover the key and get a conflicting spend confirmed within a narrow window.

Hashing a public key can delay exposure, but it is not a complete migration plan. Taproot exposes an output key from the beginning.

The guide to Bitcoin address and output exposure takes a closer look at spent versus unspent outputs, script types, and address reuse.

Why quantum hardware cannot attack Bitcoin today

The missing ingredient is not a theoretical algorithm. It is a cryptographically relevant, fault-tolerant quantum computer.

Physical qubits are noisy. Long calculations require logical qubits encoded across many physical qubits, repeated error detection, fast decoding, and a logical error rate low enough to survive millions of operations. The number of qubits alone is therefore a poor measure of attack readiness.

Official 2026 research illustrates both genuine progress and the remaining gap. IBM and the University of Chicago reported an encoded experiment involving 70 logical qubits, 2,415 logical two-qubit operations, and 468 logical T gates. Google Quantum AI reported advances in keeping error-corrected systems stable as hardware drifts. Those are meaningful research milestones. Compare them carefully with the secp256k1 estimate: around 1,200–1,450 logical qubits and 70–90 million Toffoli gates, under demanding fault-tolerance assumptions.

The comparison is not a forecast; architectures and algorithms can improve. It shows why a 2026 demonstration is not a Bitcoin-breaking machine. No authoritative source can supply a fixed “Q-Day.”

Migration is larger than choosing a signature algorithm

A post-quantum signature could authorize new outputs, but adoption would touch nearly every layer of the ecosystem.

Consensus. Bitcoin nodes need precisely specified validation rules and an activation mechanism. Signature and public-key sizes, verification cost, denial-of-service limits, witness accounting, and compatibility all require review. A proposal’s presence in the BIPs repository does not mean it has community consensus or is scheduled for activation.

Wallets and custody. Software wallets, hardware devices, multisignature systems, backups, descriptors, and signing workflows must support the new output type and a safe path for moving coins.

Exchanges and infrastructure. Exchanges, processors, custodians, miners, explorers, and libraries must update operational logic. A migration that works only in Bitcoin Core is incomplete.

Old and inactive coins. Some coins have exposed keys but may be lost, dormant, or intentionally untouched. If a future rule restricts legacy spending, should those coins be frozen, recoverable, or left vulnerable? Each choice affects property expectations, fungibility, incentives, and perceptions of immutability. Cryptography cannot settle that social question.

Coordination and time. Holders must learn and move funds; institutions need approvals. A rushed flag day carries risks, while indefinite delay leaves exposure in place.

Two 2026 drafts show that the design space is active. BIP 360 proposes pay-to-merkle-root as a way to improve protection against long-exposure attacks, while acknowledging that short-exposure protection needs post-quantum signatures. BIP 361 sketches a staged migration and eventual restrictions on legacy signature spends. Both are drafts. Neither is an adopted Bitcoin migration plan.

See what a post-quantum Bitcoin migration would actually require for the standards, block-space, wallet, and consensus tradeoffs. The separate lost-coin freezing debate examines the case for and against restricting old spends.

What post-quantum standards exist now?

NIST published its first three final post-quantum standards in August 2024: FIPS 203 for ML-KEM, FIPS 204 for the ML-DSA digital signature, and FIPS 205 for the SLH-DSA digital signature. For Bitcoin spending authorization, the signature standards—ML-DSA and SLH-DSA—are the directly relevant category; ML-KEM is for establishing shared secrets, not signing transactions.

NIST has also selected FN-DSA (derived from FALCON) for a forthcoming FIPS 206, and its additional-signature process advanced to a third round in May 2026. Standardization is essential evidence, but it is not automatic Bitcoin suitability. Bitcoin must evaluate signature and key sizes, verification performance, implementation complexity, side-channel resistance, conservative security assumptions, and how an algorithm fits consensus rules and fee economics.

What Bitcoin should monitor next

The sensible posture is neither panic nor complacency. Bitcoin’s technical community and users should monitor:

  1. reproducible fault-tolerant resource estimates for secp256k1, including physical overhead and runtime—not raw qubit announcements;
  2. demonstrated growth in logical-qubit count, gate fidelity, circuit depth, and sustained error correction;
  3. NIST’s FN-DSA work and additional signature standardization, alongside real-world cryptanalysis and implementations of ML-DSA and SLH-DSA;
  4. Bitcoin proposals, prototypes, test vectors, benchmarking, and review for quantum-resistant output types and migration rules; and
  5. ecosystem readiness across wallets, hardware signers, exchanges, custodians, miners, and long-inactive holdings.

Bitcoin is not under a working quantum attack in 2026. It does, however, face a legitimate long-horizon engineering challenge. The best response is the one Bitcoin has relied on before: open research, adversarial review, cautious implementation, and enough lead time for people—not just software—to migrate.

Sources