Gate Square “Creator Certification Incentive Program” — Recruiting Outstanding Creators!
Join now, share quality content, and compete for over $10,000 in monthly rewards.
How to Apply:
1️⃣ Open the App → Tap [Square] at the bottom → Click your [avatar] in the top right.
2️⃣ Tap [Get Certified], submit your application, and wait for approval.
Apply Now: https://www.gate.com/questionnaire/7159
Token rewards, exclusive Gate merch, and traffic exposure await you!
Details: https://www.gate.com/announcements/article/47889
The Real Quantum Threat to Bitcoin Has Nothing to Do With "Cracking Encryption"
The narrative surrounding quantum computers and Bitcoin security has been muddled by a fundamental terminology mistake. Media coverage often claims quantum computers will “crack Bitcoin encryption,” but this framing misses the actual vulnerability entirely. Bitcoin doesn’t store encrypted secrets on the blockchain. The real exposure lies in digital signatures and public-key compromise—a distinctly different threat vector.
Understanding What Actually Matters: Signatures Over Secrecy
Bitcoin’s security model relies on ECDSA and Schnorr signatures to prove ownership of coins. The blockchain is a transparent ledger; every transaction and address is publicly visible. This means nothing is encrypted in the traditional sense. The security question isn’t whether a quantum computer can decrypt something hidden—it’s whether it can derive a private key from an exposed public key and forge a valid signature.
Adam Back, a longtime Bitcoin core developer, framed this distinction sharply: “Bitcoin does not use encryption. Get your basics right.” This terminology error has inflated quantum FUD for years. The actual quantum risk involves Shor’s algorithm, which can theoretically compute discrete logarithms over elliptic curves. If a sufficiently powerful quantum computer runs this algorithm against a publicly visible key on-chain, it could derive the corresponding private key and authorize unauthorized transactions.
The Bottleneck: When Public Keys Become Exposed
Address format matters significantly for quantum risk. Many Bitcoin address types commit only to a hash of the public key, meaning the raw key remains hidden until that output is spent. This design narrows the window for a potential attacker to compute a private key via Shor’s algorithm.
However, other script types expose keys earlier. Address reuse turns a single reveal into a persistent vulnerability. Taproot (P2TR) outputs, introduced via BIP 341, include a 32-byte tweaked public key directly in the output program rather than a hash—a change that alters the exposure profile substantially.
Project Eleven’s “Bitcoin Risq List” tracks this exposure methodically. Their analysis identifies approximately 6.7 million BTC already on-chain with exposed public keys, creating what researchers define as the quantum-vulnerable address pool.
Quantifying the Computational Barrier
Understanding whether quantum risk is imminent requires separating logical from physical qubits. Research by Roetteler and colleagues establishes that computing a 256-bit elliptic-curve discrete logarithm requires roughly 2,330 logical qubits at upper bound. The square root of 256 computational relationship—along with broader algorithmic complexity—informs these estimates.
Converting logical qubits to error-corrected physical machines introduces enormous overhead. Recent estimates suggest approximately 6.9 million physical qubits could recover a 256-bit elliptic-curve key in about 10 minutes (under Litinski’s 2023 model). Other analyses cluster around 13 million physical qubits for breaking a key within a day. These numbers assume specific error-rate and timing assumptions that remain unproven in practice.
IBM’s recent roadmaps situate fault-tolerant quantum computers around 2029, though progress on error-correction components continues to shift timelines. The computational path from theoretical feasibility to practical attack remains extraordinarily steep.
The Grover Question: Why Hash Functions Remain Resilient
Quantum algorithms pose different threats to different cryptographic layers. While Shor’s algorithm targets discrete-log problems directly, Grover’s algorithm provides only a square-root speedup against brute-force search. For Bitcoin’s SHA-256 hashing, a Grover-accelerated attack leaves the security target at roughly 2^128 operations—still computationally infeasible and incomparable to an elliptic-curve break.
Hashing thus remains a secondary concern in quantum risk assessments.
Migration as the Real Challenge
If a quantum-capable machine does emerge, the threat wouldn’t involve rewriting Bitcoin’s consensus history. Instead, an attacker would race to spend outputs with exposed keys faster than legitimate transaction confirmation. This shifts Bitcoin’s vulnerability window from historical reconstruction to real-time transaction competition.
Protocol upgrades provide the path forward. BIP 360 proposes “Pay to Quantum Resistant Hash” output types, while proposals like qbip.org advocate legacy-signature sunsets to force migration and reduce the exposed address long tail. Post-quantum signatures such as ML-KEM (NIST’s FIPS 203 standard) are kilobytes rather than tens of bytes, fundamentally reshaping transaction economics and wallet design.
Wallet behavior and address reuse patterns offer near-term levers. Once a public key is broadcast on-chain, any future receipt to that same address remains exposed. Users and developers can reduce exposure today through operational discipline and better wallet defaults.
The Bottom Line: Risk Measurement Without Timeline Certainty
Bitcoin’s quantum vulnerability is real but measurable—and its urgency depends on fault-tolerant machine development rather than algorithmic breakthrough. The infrastructure challenge is manageable: tracking exposure, designing migration paths, and updating validation rules. The narrative challenge is correcting terminology: Bitcoin faces no encryption-breaking risk because it uses no encryption to break. It faces signature-forging risk from exposed public keys—and that timeline depends on hardware, not theory.