# Bitcoin & Quantum Computing — Full Content > Three-part research series by NVK. Site: https://bitcoinquantum.space --- # I Spent 200 Hours Reading Quantum Computing Papers So You Don't Have To. Bitcoin Is Fine. *Well, mostly fine. The truth is more interesting than the panic — and more urgent than the dismissals.* --- ## TL;DR for Skimmers - **Bitcoin does not use encryption.** It uses digital signatures. Most articles get this wrong, and the difference matters. - **Quantum computers cannot "crack Bitcoin in 9 minutes."** That headline describes a theoretical circuit on a machine that doesn't exist and won't for at least a decade. - **Quantum mining is physically impossible.** It would require more energy than the Sun produces. Seriously. - **Bitcoin CAN upgrade** — it has before (SegWit, Taproot) — and work has started (BIP-360). But the community needs to move faster. - **There IS a real concern**: ~6.26 million BTC have exposed public keys, and the qubit gap is closing faster than anyone predicted. This isn't a thing to panic about. It's a thing to prepare for. --- ## The Throughline Here's the one-sentence version of everything I'm about to tell you: > **The quantum threat to Bitcoin is real but distant, the media coverage is systematically unhinged, and the most dangerous thing isn't quantum computers — it's complacency disguised as either panic or dismissal.** Both the "Bitcoin is doomed!" crowd and the "Nothing to see here!" crowd are wrong, in ways that are equally unhelpful. The truth requires holding two ideas simultaneously: (1) there is no imminent quantum threat to your Bitcoin, and (2) the Bitcoin community has about a decade to implement changes that will take 7-10 years. That's a tight window. But it's a window — not a wall. Let me show you the math. --- ## Part 1: The Media Machine (Or, Why Headlines Are the Real Threat) Every few months, the same cycle repeats: 1. A quantum computing lab publishes a careful, heavily caveated research paper 2. Tech media writes: **"QUANTUM COMPUTERS COULD CRACK BITCOIN IN 9 MINUTES"** 3. Crypto Twitter compresses this to: **"BITCOIN IS DEAD"** 4. Your uncle texts you asking if he should sell 5. The actual paper says nothing of the sort In March 2026, Google's quantum AI team published a paper showing that breaking Bitcoin's elliptic curve cryptography would require fewer than 500,000 physical qubits — a 20x improvement over prior estimates. This is genuinely important research. Google was so serious about responsible disclosure that they withheld the actual attack circuits and published only zero-knowledge proofs. What the paper did NOT say: that Bitcoin can be cracked today, that a timeline exists, or that anyone should panic. What the headlines said: **"Bitcoin cracked in 9 minutes."** CoinMarketCap ran an article titled "Will AI-Accelerated Quantum Computing Break Bitcoin in 2026?" The article then spent its entire body explaining why the answer is "almost certainly no." This is the standard pattern: sensational headline for clicks, cautious body for accuracy. But 59% of shared links are never clicked — so the headline IS the message for most people. Raoul Pal had the best economic debunk: *"Markets price risk extremely fast. You wouldn't steal something that collapses in value the moment you take it."* If quantum computing were about to break everything, Google itself — which uses the same cryptography — would show panic in its stock price. GOOG is doing fine. **The takeaway**: The headlines are the real misinformation. The research is real and worth understanding. Let's do that. --- ## Part 2: What Quantum Computers Actually Threaten (And What They Don't) ### The #1 Misconception: "Encryption" Nearly every article about quantum computing and Bitcoin uses the word "encryption." This is wrong, and the error changes everything. **Bitcoin does not use encryption to secure your funds.** It uses digital signatures (ECDSA, and more recently Schnorr via Taproot). The blockchain is public by design — all transaction data is visible to everyone, always. There is nothing to "decrypt." As Adam Back — inventor of Hashcash (cited in the Bitcoin whitepaper) — puts it: *"Encryption implies data is hidden and can be decrypted. Bitcoin's security model is based on signatures that prove ownership without exposing the private key."* This isn't a semantic quibble. It means the "harvest now, decrypt later" threat — the strongest urgency argument in quantum computing — largely doesn't apply to Bitcoin fund security. There's nothing encrypted to harvest. The public keys that are exposed are already sitting in the open on the blockchain. (There is a privacy nuance here — a quantum computer could link identities to transactions by deriving public keys from addresses — but that's a privacy concern, not a "your coins are stolen" concern.) ### The Two Algorithms: One Matters, One Doesn't *(Stick-figure diagram style borrowed from Tim Urban's [Wait But Why](https://waitbutwhy.com) — if you haven't read his work, you should.)* **Shor's Algorithm** (the real threat): Provides an *exponential* speedup for breaking the mathematical problem underlying digital signatures (ECDSA). This would allow someone to derive your private key from your public key, and sign transactions as if they were you. This is the thing to actually worry about. **Grover's Algorithm** (not the threat): Provides only a *quadratic* speedup for attacking hash functions like SHA-256 (Bitcoin mining). This sounds scary until you do the math. A 2025 paper titled "Kardashev Scale Quantum Computing for Bitcoin Mining" calculated what Grover's algorithm would actually require at Bitcoin's real-world difficulty level: - **~10²³ physical qubits** (we currently have about 1,500) - **~10²⁵ watts of power** (the Sun produces ~3.8 × 10²⁶ watts) To mine Bitcoin with a quantum computer, you would need to harness a significant fraction of the Sun's total energy output. We are a Kardashev Type 0.73 civilization. This is a Type II requirement. For context: an "optimistically specified" quantum miner achieves about 13.8 GH/s. A single Antminer S21 does 200 TH/s. The classical ASIC is **14,500 times faster**. > --- > **The stat to text your friend:** > > Mining Bitcoin with a quantum computer would require **10²⁵ watts of power** — roughly 3% of the Sun's total energy output. The entire planet Earth currently uses about 1.8 × 10¹³ watts. You'd need to multiply humanity's total energy consumption by **a trillion** to quantum-mine a single block. > > A $2,000 ASIC from Amazon is 14,500x faster than the best theoretical quantum miner. The quantum computer costs billions and needs to be cooled to near absolute zero. The ASIC plugs into a wall outlet. > > Quantum mining isn't hard. It's *thermodynamically absurd*. > > --- **Bottom line**: Quantum mining is not a thing. Not now, not in 50 years, possibly not ever. If someone tells you quantum computers will "break Bitcoin mining," they have confused two fundamentally different algorithms. --- ## Part 3: The 8 Claims You'll Hear (And Why 7.5 of Them Are Wrong) Let me walk through the specific FUD claims in circulation and give you the counterargument for each. I'm using a half-point because one of these claims is half-right. ### Claim 1: "All Bitcoin can be stolen overnight once quantum computers arrive" **Reality**: Only Bitcoin with *exposed public keys* is vulnerable. Modern Bitcoin addresses (P2PKH, P2SH, SegWit) do not expose your public key until you spend from them. If you've never reused an address and never spent from it, your public key is not on the blockchain. The breakdown: - **Tier A** (immediately vulnerable): ~1.7 million BTC in old P2PK format — keys visible right now - **Tier B** (vulnerable, but fixable): ~5.2 million BTC in reused addresses and Taproot — users can migrate - **Tier C** (briefly vulnerable): Every transaction is exposed during the ~10 minutes it sits in the mempool Total: about 6.26 million BTC with exposed keys (Chaincode Labs estimate). That's ~30-35% of the supply — significant, but not "all Bitcoin." ### Claim 2: "Satoshi's coins will be stolen, crashing the market to zero" **Half-right**: Satoshi's ~1.1 million BTC are in P2PK format with exposed keys. They ARE among the most vulnerable coins. But: 1. Stealing them requires a machine that does not exist 2. Nation-states with early quantum capability would target intelligence and military systems — not attempt "what would be a very public Bitcoin theft PR stunt" (as the Quantum Canary research group puts it) 3. The Bitcoin community would have years of warning from visible hardware milestones and could implement protocol changes (freeze, migrate, or burn vulnerable UTXOs) before theft becomes practical ### Claim 3: "Bitcoin can't upgrade — it's too slow and ungovernable" **False, but not without nuance.** Bitcoin has successfully executed major upgrades: - **SegWit** (2015-2017) — Extremely contentious, near-failure, caused the Bitcoin Cash fork. But it shipped. - **Taproot** (2018-2021) — Smooth activation, ~3.5 years from proposal to live on mainnet. BIP-360, the leading quantum-resistant proposal, was merged into Bitcoin's BIP repository in early 2026. It introduces a new address type (bc1z) that removes Taproot's quantum-vulnerable key-path spend. It's in Draft status, with a testnet already running Dilithium post-quantum signature opcodes. Ethan Heilman, BIP-360 co-author, estimates the full process at about 7 years: 2.5 years of development and review, 0.5 years for activation, and 4 years for ecosystem migration. He readily admits: "I'm just spitballing here. No one actually knows." The honest answer: Bitcoin *can* upgrade and *has started*, but the process is early-stage and needs to accelerate. The claim it's "impossible" is false. The claim it's "done" is also false. ### Claim 4: "We only have 3-5 years" **Probably wrong, but not safely wrong.** Expert estimates span a huge range: - **Adam Back** (Hashcash inventor, cited in Bitcoin whitepaper) — 20-40 years - **Craig Gidney** (Google Quantum AI) — 10% chance of a cryptographically relevant quantum computer by 2030 - **Expert survey** (26 quantum security researchers) — 28-49% chance within 10 years - **Ark Invest** — "Long-term, not imminent" One thing worth understanding: quantum computing progress is not always linear and visible. Google's Willow chip crossed the "below-threshold" barrier for quantum error correction in late 2024 — meaning that from this point on, adding more qubits makes the system *exponentially* better, not incrementally better. That's a phase transition, not a smooth curve. Google itself withheld its actual attack circuits from the March 2026 paper, publishing only zero-knowledge proofs. And Scott Aaronson has warned that at some point, researchers will *stop publishing* resource estimates for breaking cryptography. So the assumption that we'll see Q-Day coming from a mile away is not guaranteed. That said, building a machine with hundreds of thousands of fault-tolerant qubits is still an enormous engineering challenge. No quantum computer has ever factored a number larger than 13 digits. Breaking Bitcoin's cryptography requires the equivalent of factoring ~1,300-digit numbers. That's not a gap that closes overnight — but the trajectory deserves respect, not dismissal. ### Claims 5-8: Quick Hits **"Quantum breaks mining"** — No. Requires the Sun's energy output. See Part 2. **"Harvest now, decrypt later"** — Doesn't apply to fund theft (blockchain is already public). Does apply to privacy (a legitimate but lesser concern). **"Google says 9 minutes"** — Google says a theoretical circuit *could* run in 9 minutes on a 500,000-qubit machine that doesn't exist. Google cautioned against FUD. Google withheld the attack circuits. **"Post-quantum crypto isn't ready"** — NIST has already standardized ML-KEM, ML-DSA, and SLH-DSA. The algorithms exist. The challenge is deploying them in Bitcoin, not inventing them. --- ## Part 4: The Honest Part (What I Worry About) A debunking article that dismisses everything loses credibility. Here are the five things that keep me up at night: **1. The qubit estimates are collapsing.** In 2012, breaking cryptography required an estimated 1 billion qubits. By 2019: 20 million. By 2025: under 1 million. In early 2026, Oratomic demonstrated feasibility with as few as 10,000 physical qubits using neutral-atom architecture. Nobody knows when the "qubits needed" and "qubits available" lines cross. The honest answer is genuine uncertainty. **2. The exposed surface is growing, not shrinking.** Taproot — Bitcoin's newest and most promoted address format — exposes tweaked public keys on-chain, giving quantum attackers an indefinite offline window. Bitcoin's most recent upgrade made things *worse* for quantum resistance. That's an irony worth sitting with. **3. Bitcoin's governance is slow.** No soft fork has activated since November 2021 — over four years of base-layer stasis. Google targets 2029 for its own post-quantum migration. Bitcoin's most optimistic estimate is 2033. If a CRQC arrives before ~2035 (28-49% of experts consider this plausible), Bitcoin faces a genuine race condition. **4. Satoshi's coins are an unsolvable game-theory problem.** ~1.1 million BTC in P2PK addresses that can never be migrated because no one holds the keys (or Satoshi is absent). The options — do nothing, freeze, burn — all have serious consequences. There is no clean solution. **5. The blockchain is a permanent target list.** Every exposed public key is catalogued forever at zero cost. Nation-states can prepare now and wait. Defense requires active coordination; attack requires only patience. These aren't FUD. These are engineering challenges that deserve engineering responses — which is exactly what the Bitcoin developer community is working on. --- ## Part 5: So What Should You Actually Do? If you're a Bitcoin holder: 1. **Don't panic.** The threat is real but distant. You have time. 2. **Stop reusing addresses.** Your public key is hidden behind a hash, but only until you spend. Once you spend from an address, the key is on-chain and any funds received afterward are exposed. Taproot (bc1p) is the exception — it exposes the tweaked public key immediately, no spending required. Use fresh addresses for every receive. 3. **Watch for BIP-360.** When quantum-resistant address types become available, migrate your funds. 4. **If you're holding long-term**, consider keeping funds in addresses you've never spent from. Your public key stays hidden. 5. **Ignore the headlines.** Read the actual papers. They're more interesting and less scary than the coverage suggests. If you're a Bitcoin developer: 1. **BIP-360 needs more reviewers.** The testnet is running. The code needs eyeballs. 2. **The 7-year timeline needs to compress.** Every year of delay narrows the safety margin. 3. **Start the governance conversation about legacy UTXOs.** Satoshi's coins won't protect themselves. The community needs a plan. If you're someone who just read a scary headline: Remember that 59% of shared links are never clicked. The headline is designed to make you feel something. The paper underneath is designed to make you think something. Go read the paper. --- ## The Real Story The quantum threat to Bitcoin is not a binary — it's a spectrum. On one end: "Bitcoin is doomed and you should sell everything." On the other: "Nothing to see here, quantum is a hoax." Both ends are wrong. The truth sits in a specific, actionable middle: Bitcoin has a real engineering challenge with known parameters, active development, and a timeline that is tight but manageable — *if* the community treats it with appropriate urgency. The most dangerous thing isn't quantum computers. It's the media cycle that oscillates between panic and dismissal, making it impossible for anyone to think clearly about what is fundamentally a solvable problem. Bitcoin has survived the block size wars, exchange hacks, regulatory assaults, and its own creator disappearing. It will survive quantum computing — but only if the community starts preparing now, not in a panic, but with the steady, methodical engineering focus that has always been Bitcoin's greatest strength. The house isn't on fire. But the gas line is leaking and the smoke detector needs batteries. Time to get to work. --- *Sources: 66 research documents across two topic wikis spanning quantum computing resource estimates, Bitcoin vulnerability analysis, debunking psychology, and content virality research. Key sources include Google Quantum AI (2026), Kardashev Scale Mining Paper (2025), BIP-360 documentation, Berger & Milkman (2012), the Debunking Handbook 2020, and practitioner accounts from Tim Urban, Dan Luu, and patio11. Full wiki available for peer review.* --- # I Went Deeper Down the Quantum Rabbit Hole. The Industry Is Full of Shit. *A follow-up. [Part 1 here.] The more I read, the less worried I got — and the angrier.* --- ## TL;DR - The quantum computing industry has received **$40+ billion** in government funding and produced **under $1 billion** in revenue. Insiders are selling stock at a 216:1 ratio. The hype is not accidental. - Expert technology predictions are wrong **86% of the time** for long-term forecasts. Domain insiders are systematically ~20 years more optimistic than outsiders. Fusion has been "20 years away" for 50 years. - The people who actually build and break cryptographic systems — Green, Schneier, Thaler, Bernstein — are far more skeptical than the people selling quantum hardware. The father of post-quantum cryptography says: *"I hope quantum computing somehow fails."* - The largest number ever factored by a quantum computer is **21**. A 1981 Commodore VIC-20 can do the same thing. Breaking Bitcoin requires factoring a 1,300-digit number. - **Bitcoin should still upgrade its cryptography** — not because quantum computers are coming, but because relying on a single cryptographic assumption for a $2 trillion network is bad engineering. Classical math has broken more crypto than quantum computers ever have. --- ## Why a Part 2 After publishing Part 1, I got two kinds of responses. The "Bitcoin is doomed" crowd told me I was too dismissive. The "nothing to see here" crowd told me I was too worried. Then I kept reading. Another 40 papers. The Cloudflare roadmap. Alex Pruden's hardware progress thread. Matthew Green's commentary. Tim Palmer's PNAS paper on quantum mechanics itself. Insider trading data. Prediction market odds. Technology forecasting research going back decades. And something shifted. Not toward panic — further away from it. The deeper I went into the actual evidence, the more the quantum threat looked like a story told primarily by people with a financial interest in you believing it. That doesn't mean it's fake. It means the timeline is almost certainly bullshit, the urgency is manufactured, and the real reason to upgrade Bitcoin's cryptography has nothing to do with quantum computers. Let me show you what I found. --- ## Part 1: The Base Rate Problem (Or, Why Expert Predictions Are Garbage) Before I give you anyone's estimate for when quantum computers will break cryptography, you need to understand how reliable expert predictions are. The answer: not very. A study of 300+ technology forecasts published in *PNAS* found that long-term predictions (11-30 years) have a **14% success rate**. Not 50%. Not 30%. Fourteen percent. Six out of seven expert predictions for transformative technologies are wrong. Philip Tetlock ran a 20-year study tracking over 30,000 expert forecasts. The average expert performed at the level of random guessing. He called it the "dart-throwing chimpanzee" problem — you'd get similar accuracy from a chimp throwing darts at a board of possibilities. It gets worse. Research from AI Impacts found that people *inside* a field are systematically ~20 years more optimistic about their technology's timeline than outsiders looking at the same evidence. The mechanism is obvious: the people most motivated to work on quantum computing are the ones who believe it will succeed soon. That's selection bias baked into every expert survey. Fusion energy has been "20 years away" for 50 years. A formal academic review in Springer tracked three decades of fusion predictions. Over 30 calendar years, the estimated distance to commercial fusion shrank by a net **1.5 years**. In one decade, it actually moved *backward* — experts said it was further away than they'd said ten years prior. Autonomous driving predictions from 2015-2016 targeted 2019-2021. Lyft said majority of rides would be autonomous "within five years." Ford promised steering-wheel-free robotaxis. Level 5 is still not here in 2026, 10+ years late and counting. Every single one of these predictions was made by smart people with access to the best data available. They were all wrong. Not by a little. By decades. Now here are the expert estimates for quantum computers breaking cryptography. --- ## Part 2: What the Experts Actually Say (Read Between the Lines) Watch who says what — and what they sell. **Adam Back** (Hashcash inventor, cited in the Bitcoin whitepaper): 20-40 years. **Jensen Huang** (NVIDIA CEO): Initially said 15-30 years, January 2025. This was honest. The market wiped **$8 billion** off quantum computing stocks in a single day. Within 60 days, Huang walked it back, hosting a "Quantum Day" where he let QC CEOs explain why he was wrong. Draw your own conclusions about which estimate he actually believed and which one the industry needed him to say. **Bruce Schneier** (cryptographer): *"I am also skeptical that we are going to see useful quantum computers anytime soon."* Estimates ~2039, and frames it: *"We don't know if it's 'land a person on the surface of the moon' hard, or 'land a person on the surface of the sun' hard."* **Matthew Green** (Johns Hopkins, one of the most respected cryptographers alive): *"Apple even spent time adding post-quantum encryption to its iMessage protocol — this means Apple users are now safe from quantum computers that don't exist."* On Google's 2026 paper: *"It's an algorithm for a computer that's at best years away from existing, so I'd say publish."* **Justin Thaler** (Georgetown CS professor, a16z crypto research partner): *"Timelines for a quantum computer powerful enough to break modern cryptography are being widely overstated, and that exaggeration is driving costly and in some cases misguided security decisions."* His bottom line: *"Implementation security, not quantum computing, is the dominant cryptographic risk for years to come."* **Scott Aaronson** (UT Austin, leading quantum complexity theorist): Refuses to give a timeline. Notes breaking RSA would require "someone investing $100 billion." He's probably the most intellectually honest person in the field — and he keeps his personal wealth in index funds, not quantum stocks. **Craig Gidney** (Google Quantum AI): 10% chance by 2030. Also notes he does NOT see another 10x improvement in qubit estimates under current assumptions — the optimization curve may be flattening. **Prediction markets** (Manifold, 2026): RSA-2048 broken before 2030: **~20%**. SHA-256 broken: **8%**. Consumer quantum products: near-zero. **Daniel Bernstein** — the person who literally *invented* the term "post-quantum cryptography" in 2003 and co-designed one of four NIST PQC winners: *"I hope quantum computing somehow fails."* Notice the pattern. The people who build and break cryptographic systems for a living — Green, Schneier, Thaler, Bernstein — are systematically more skeptical than the people who build quantum computers. This is not a coincidence. It's the selection bias from the PNAS study made flesh. --- ## Part 3: Follow the Money Here's where it gets ugly. The quantum computing industry has received over **$40 billion in government funding** globally, plus billions in private capital. Total 2024 industry revenue: **under $1 billion**. That's a ratio that would embarrass a Ponzi scheme. Quantum computing stocks trade at price-to-sales ratios that make the dot-com bubble look conservative. Rigetti: **360:1**. IonQ: **188:1**. For context, at the peak of the dot-com bubble, Amazon was at 31:1 and eBay at 144:1. And here's the stat that tells you what insiders actually think: over five years, executives at IonQ, Rigetti, and D-Wave collectively *sold* **$930 million** in stock while *buying* **$4.3 million**. That's a **216:1 sell-to-buy ratio**. The Rigetti CEO personally sold $11 million. D-Wave's entire C-suite is selling. Not a single insider at Rigetti, D-Wave, or QCI purchased a share in the trailing year. Let that sit. The people running quantum computing companies are dumping stock as fast as they legally can while telling you the future is almost here. Every single vendor roadmap has been revised backward. IBM promised 1 million qubits by 2030 — now targets 100,000 by 2033. PsiQuantum promised 1 million qubits by 2025 — nothing materialized. Google quietly dropped its million-qubit target entirely. BCG explicitly admitted their near-term NISQ predictions were "overly optimistic." ### Quantum Predictions vs. Reality | Who | What They Predicted | When Predicted | Target Date | What Actually Happened | How Far Off | |-----|---------------------|----------------|-------------|------------------------|-------------| | **PsiQuantum** | 1 million qubits | 2020 | **2025** | Zero publicly demonstrated product progression by 2024. Shifted roadmap to 2027, then likely 2028-2029. As of 2026, Omega chipset announced but no million-qubit system. | **4+ years** (and counting) | | **IBM** | 1 million qubits | 2020 | **2030** | Revised to 100,000 qubits by 2033. Pivoted strategy entirely — abandoned monolithic scaling (Condor) in favor of modular approach (Heron). The "1 million" target quietly disappeared. | **3+ years** (target moved, scope reduced 10x) | | **Google** | 1 million error-corrected qubits | ~2020 | **~2029** | Now targeting 100-1,000 logical qubits by 2030. The million-qubit claim evaporated. Current Willow chip: 105 qubits. | **Indefinite** (goal quietly dropped) | | **D-Wave** | 1,024-qubit machine | 2007 | **Mid-2008** | Did not deliver. D-Wave One (128 qubits) arrived in 2011. 1,000+ qubits not achieved until ~2015 (D-Wave 2X). | **7 years** | | **D-Wave** | Quantum speedup over classical | 2011-2013 | **Immediate** | Troyer & Lidar found "no speed increase compared to classical computers." McGeoch's 3,600x claim was revised to ~30x (equivalent to ~30 classical cores). | **Not achieved** (disputed to this day) | | **Google** | Quantum supremacy (Sycamore) — "10,000 years classically" | Oct 2019 | **Achieved** | IBM immediately countered: 2.5 days classically. By 2022, Chinese researchers simulated it on a classical supercomputer. The "10,000 years" was off by orders of magnitude. | **Supremacy claim eroded** | | **D-Wave** | Quantum supremacy on useful problem | Mar 2025 | **Achieved** | Within days, Flatiron Institute solved the same problem classically with 4 GPUs in 3 days. EPFL published similar classical results. | **Claim disputed immediately** | | **IBM** | NISQ utility demonstrated (127-qubit experiment) | 2023 | **Achieved** | Claims "quickly refuted by further studies that simulated IBM's experiment on a conventional laptop." | **Claim refuted** | | **Jensen Huang (Nvidia)** | Useful QC is "15-30 years away," 20 years most likely | Jan 2025 | **2040-2055** | Walked it back 2 months later at GTC, saying "my comments came out wrong." Hosted "Quantum Day" to let QC CEOs explain why he was wrong. | **Self-corrected in 60 days** | | **BCG (consultants)** | Near-term NISQ value creation | 2021 | **2021-2025** | BCG explicitly admitted "assumptions for near-term value creation in the NISQ era have proved optimistic and must be revised." | **Wrong by their own admission** | | **Honeywell/Quantinuum** | 10x quantum volume increase per year for 5 years | Mar 2020 | **2020-2025** | Actually delivered on this (QV 128 to 2M+). Rare example of a prediction that was *met or exceeded*. | **Prediction met** (notable exception) | | **IonQ** | Commercially available interconnected system | 2024-2025 | **2028** | Roadmap: 2M physical qubits / 80K logical qubits by 2030. Analysts warn scaling from ~50-100 qubits to 10K+ in 2-3 years is "unprecedented." | **TBD** (high skepticism) | | **Rigetti** | Commercial quantum advantage | ~2022 | **~2025** | Timeline slipped to 2027, now looks like 2029. Delayed 108-qubit system deployment due to coupling issues. $201M net loss in 2024. | **4+ years** (and counting) | | **Field consensus** | RSA-2048 broken by quantum computer | Various (2010s) | **~2030** | Old estimate: needed 20M physical qubits (decades away). New Gidney estimate (2025): <1M qubits, under a week. Hardware not there yet. Still no CRQC. | **TBD** (goalposts moved both ways) | | **Geordie Rose (D-Wave)** | Qubit doubling every 18 months ("Rose's Law") | ~2003 | **Ongoing** | For D-Wave's annealing qubits specifically, this roughly held. But annealing qubits are not equivalent to universal gate-model qubits — a distinction often blurred. | **Technically met, practically misleading** | https://x.com/nvk/status/2041632785928994816 The DARPA program manager for quantum computing calls himself the "Chief Quantum Skeptic" and openly questions whether fault-tolerant quantum computing is even possible. And then there's the goal-post moving. The industry started with "quantum supremacy." When that was challenged (IBM disputed Google's claim within days; Chinese researchers simulated it classically within years), it became "quantum advantage." When that proved elusive, it became "quantum utility." When IBM's quantum utility claims were "quickly refuted by further studies that simulated IBM's experiment on a conventional laptop," it became "quantum readiness." Each rebrand is a retreat disguised as progress. QuEra's own Chief Commercial Officer puts it without the spin: *"If someone says quantum computers are commercially useful today, I say I want to have what they're having."* --- ## Part 4: The Scoreboard Let's look at what quantum computers have actually done. The largest number ever factored by Shor's algorithm on real quantum hardware is **21**. That's 3 times 7. Done in 2012. An attempt at 35 failed. In 2025, cryptographers Peter Gutmann and Stephan Neuhaus published a paper in which they replicated *every quantum factoring record* on a 1981 Commodore VIC-20, an abacus, and a trained dog. The dog was slowest. The paper is titled "Replication of Quantum Factorisation Records with a VIC-20, an Abacus, and a Dog." It's published on the IACR ePrint Archive. It's not a joke — or rather, the joke is the scoreboard. Now, an important distinction. The factoring records above apply to RSA, not Bitcoin. Bitcoin uses Elliptic Curve Cryptography (secp256k1), which Shor's algorithm also breaks — but through the Elliptic Curve Discrete Logarithm Problem (ECDLP), not integer factoring. Solving Q = dG for d on a 256-bit curve is a different computational problem. And the quantum scoreboard for ECDLP is even emptier than factoring — no quantum computer has solved a meaningful elliptic curve discrete log instance. Ever. The difficulty is comparable to factoring a ~3,000-bit RSA key, but the point stands on its own: both problems are equally out of reach for any quantum hardware that exists or is on any credible roadmap. The entire urgency argument rests on a hidden assumption that Scott Aaronson states explicitly: once Shor's algorithm runs on a fault-tolerant quantum computer — even for small numbers — scaling to RSA and ECC is "merely a matter of scaling up." That "merely" is doing an extraordinary amount of work. If there's a hard ceiling somewhere between 10 and 1,200 logical qubits — and several serious physicists argue there is — then the urgency collapses entirely. No quantum computer has ever solved a real-world problem faster or cheaper than a classical computer. Not once. In over 30 years. --- ## Part 5: Why It Might Be Never I'm not being flippant. Serious physicists and mathematicians — people with named theorems and Royal Society fellowships — argue that fault-tolerant quantum computing at cryptographic scale faces barriers that may be fundamental. **Leonid Levin** (co-inventor of NP-completeness): *"Quantum amplitudes need accuracy to multi-hundredth decimals, but we have never seen a physical law valid to over a dozen decimals."* Quantum mechanics has been verified to ~12 decimal places. Shor's algorithm needs hundreds. That gap has never been tested. **Michel Dyakonov** (theoretical physicist): A 1,000-qubit system requires controlling ~10^300 continuous parameters simultaneously — more than the number of subatomic particles in the universe. His assessment: *"No, never."* **Gil Kalai** (Hebrew University, mathematician): Quantum noise exhibits irreducible correlations that worsen with system complexity. Error correction at scale is fundamentally impossible — not merely hard. His conjectures are unproven after 20 years, but his experimental predictions have been partially wrong, which cuts both ways. **Tim Palmer** (Oxford, Fellow of the Royal Society): His Rational Quantum Mechanics framework, published in *PNAS* in March 2026, argues that gravity discretizes quantum mechanics itself. Entanglement hits a hard ceiling at roughly 200-1,000 qubits. Beyond that, Shor's algorithm loses its exponential advantage. Palmer isn't arguing that engineering is too hard. He's arguing that *quantum mechanics doesn't work the way we think it does* at scale. His paper was reviewed by Nicolas Gisin and three other respected quantum foundations researchers. Aaronson expects near-term experiments to refute it. The prediction is concrete and falsifiable within five years. And there's an intuitive version of this argument that's harder to shake. Grover's algorithm — the one that's supposed to threaten Bitcoin mining — claims you can search an unsorted list of N items in O(square root of N) time. There is no classical analogy for this. You cannot search faster than you can look. It's an all-or-nothing prediction of quantum mechanics: either nature gives you exactly this speedup, or it doesn't. And what that speedup produces in practice is the absurd result we covered in Part 1: quantum mining would require the Sun's energy output to do what a $2,000 ASIC does better. When a theory predicts you need a star's energy to underperform a chip that plugs into a wall outlet, maybe the theory doesn't describe what happens at the scales required. The quantum computing industry has 6-9 competing hardware architectures — superconducting, trapped ion, neutral atom, photonic, topological, and more. In technology history, this is called the "era of ferment": the automobile industry had 275 manufacturers with three different engine types before consolidation. It's normal. It's also the phase where observers mistake activity for progress. The fusion parallel is the most precise. Thirty years of predictions. Net progress toward the goal: 1.5 years. One decade moved backward. --- ## Part 6: The Real Worries (And They're Not What You Think) I don't want to dismiss everything. That's the other side's mistake. Here's what actually keeps me up at night: **The exposed surface is growing.** Taproot — Bitcoin's newest address format — exposes tweaked public keys on-chain. Bitcoin's most recent upgrade made things *worse* for quantum resistance. About 6.26 million BTC have exposed public keys. That's 30-35% of the supply. It's not a reason to panic. It is a reason to prepare. **Bitcoin's governance is slow.** No soft fork has activated since November 2021. Cloudflare already has 65% of its traffic post-quantum encrypted. Bitcoin is at 0%. The gap isn't technical — it's governance. But slow isn't the same as stuck. BIP-360 is in draft status with a testnet running. The work has started. **Migration is a race condition.** To move Bitcoin to a quantum-resistant address, you have to spend from the old one — exposing your public key in the process. Solutions exist (commit-delay-reveal protocols, pre-emptive poison pills), but they only work for Bitcoin whose public key is still hidden behind a hash. For the ~6.26 million BTC with already-exposed keys, including Satoshi's coins, there is no post-disaster fix. **Satoshi's coins can't be moved.** ~1.1 million BTC in P2PK addresses with exposed keys. No one holds the keys — or Satoshi is absent. There is no clean solution. Those are real engineering problems. They deserve serious attention. But notice what's NOT on my worry list: "quantum computers will break Bitcoin in 5 years." The evidence doesn't support that timeline. The evidence barely supports that timeline in 20 years. And the evidence for "never" is stronger than most people realize. --- ## Part 7: The Actual Reason to Upgrade (It's Not Quantum) Here's the part that matters most, and it has nothing to do with quantum computers. Cryptographic systems broken by quantum computers to date: **zero**. Numbers factored by quantum computers: **21**. Numbers factored by a Commodore VIC-20 from 1981: **also 21, and larger**. Cryptographic systems broken by classical mathematics: **too many to count**. DES, MD5, SHA-1, RC4, SIKE, the Enigma machine — all fell to clever math, not quantum hardware. SIKE was a NIST post-quantum *finalist* that got destroyed in 2022 by a single researcher on a laptop in an hour. secp256k1 — the elliptic curve Bitcoin uses — could fall to a mathematical breakthrough tomorrow. No quantum computer needed. Just a sufficiently clever number theorist with a new insight into the discrete logarithm problem. Daniel Bernstein and Tanja Lange's SafeCurves project rates secp256k1 as failing 4 of 11 safety criteria — not because the math is broken, but because the curve makes it unnecessarily hard to write secure implementations. Bitcoin Core's libsecp256k1 library heroically mitigates these risks through constant-time algorithms and formal verification. But compiler updates have repeatedly broken these guarantees, requiring emergency patches. **This is the actual reason Bitcoin should adopt alternate cryptographic schemes.** Not because quantum computers are coming — they might never arrive. But because relying on a single cryptographic assumption for a $2 trillion network is exactly the kind of risk that serious engineering addresses proactively. The quantum FUD is a distraction from this quieter, more real concern. And ironically, the work being done to prepare for quantum threats — BIP-360, post-quantum signatures, hash-based alternatives — also addresses the classical cryptanalysis risk. The right thing is being done, for the wrong reason. That's fine, as long as it gets done. --- ## What You Should Do If you're a holder: stop reusing addresses. Watch for BIP-360. Keep long-term holdings in addresses you've never spent from. Be cautious with your xpub — in a post-quantum world, it's as sensitive as your seed phrase. And ignore the headlines. The actual papers are more interesting and less scary. If you're a developer: BIP-360 needs reviewers. The testnet is running. Start the governance conversation about legacy UTXOs. Research commit-delay-reveal and poison-pill emergency protocols. The 7-year timeline estimate should compress. If you just read a scary headline: remember that 59% of shared links are never clicked. The headline is designed to make you feel something. The paper underneath says something different. Go read the paper. --- ## The Honest Conclusion Here's where I ended up after 200+ hours and 85 research documents: The quantum computing industry is running one of the most successful marketing campaigns in the history of technology. Forty billion dollars in, under a billion out, insiders selling 216:1, every roadmap revised backward, every success criterion relaxed, and still the headlines say "almost there." The underlying physics might be real. The engineering might eventually work. But the timelines being sold to policymakers, investors, and the public are not based on evidence. They are based on the financial needs of an industry that has burned through more capital than it has produced value, by a ratio that should embarrass everyone involved. Bitcoin's cryptography will need upgrading eventually. Not because quantum computers are five years away — they almost certainly aren't. Not because the threat is imminent — the prediction markets say ~20% chance by 2030, and prediction markets are more reliable than experts. But because classical cryptanalysis has been killing cryptographic systems for as long as they've existed, because secp256k1 has known weaknesses that are mitigated heroically rather than resolved structurally, and because a $2 trillion network deserves defense in depth. The house isn't on fire. The house may never catch fire from this direction. But the smoke alarm salesmen are getting very rich telling you it might. --- *Sources: 85 research documents spanning quantum computing resource estimates, Bitcoin vulnerability analysis, technology prediction accuracy (PNAS, Tetlock), vendor incentive analysis, and cryptographer commentary. Key sources: Google Quantum AI (2026), Palmer RaQM (PNAS 2026), Fye et al. forecasting accuracy, Gutmann & Neuhaus VIC-20 replication (IACR 2025), Matthew Green (JHU), Justin Thaler (Georgetown/a16z), Bruce Schneier, BIP-360, SafeCurves, Manifold Markets, and QC industry insider trading data.* --- # I Read Every Bitcoin Quantum Proposal. Here's Where We Actually Are. *Part 3. [Part 1 here.](https://x.com/nvk/status/2041162989760590171) [Part 2 here.](https://x.com/nvk/status/2041644230620139787) The bullshit is squashed. Now let's talk engineering.* > *Last updated: 2026-04-11 — added Buchner's PQC precommitment slots (proposal #14). See changelog at the bottom.* --- ## TL;DR - There are **15+ named researchers** actively working on Bitcoin's post-quantum defense across 15+ Delving Bitcoin threads, a published BIP, a running testnet, and real transactions on Liquid. The "nobody is working on this" narrative is factually wrong. - The developers hold **three overlapping positions** — ship the format now, only trust hash-based crypto, or individual migration is meaningless — and the same person can lean different ways on different questions. This is how Bitcoin development works. - **Taproot's script-path is already post-quantum secure** — formally proven with a 2^81 security bound. 70-90% of existing Taproot outputs are key-path-only (BIP 86) and can't use the script-path escape hatch directly — but a new zk-STARK proof-of-concept shows BIP-32 wallet owners can prove seed ownership without revealing secrets, shrinking the confiscation surface from "most Taproot users" to "non-HD wallets and lost seeds." - The most promising Bitcoin-specific signature scheme (SHRINCS) produces **324-byte signatures** — only 5x larger than current Schnorr. It has real transactions on Liquid. Greg Maxwell calls progress "pretty reasonable." - A new approach — **Quantum Safe Bitcoin (QSB)** — achieves quantum-resistant transactions **today, with no soft fork**, using a hash-to-signature puzzle where security rests on RIPEMD-160 pre-image resistance, not elliptic curves. Cost: $75-$150 per transaction. Constraint: legacy script only, miner-direct submission. Not practical for everyday use, but it proves Bitcoin's existing scripting language already contains the building blocks for quantum defense — no permission required. - And a **fourteenth** proposal dropped on April 10: Daniel Buchner's [PQC precommitment slots](https://github.com/csuwildcat/pqc-precommitment-migration). Not a quantum-safe spend today — an ordinary Schnorr spend with tagged SLH-DSA and SHRINCS pubkeys sitting inside the tapscript leaf as "unknown key type" slots under BIP 342's existing rules. Spendable today with dummy witnesses. If and when a future soft fork binds real verification semantics to those tags, the exact same UTXO gains post-quantum protection with no migration spend. Cheap, voluntary, and doesn't require anyone to decide on the soft fork first. The first proposal designed specifically to let anxious holders *do something today* without betting on any particular soft fork. - The bottleneck is **both cryptography and governance**. Basic PQ signing exists, but the full toolkit — adaptor signatures (Lightning), key aggregation, threshold sigs — doesn't. And Bitcoin's last soft fork was November 2021. --- ## Why a Part 3 Parts 1 and 2 made the case that the quantum threat to Bitcoin is overhyped, that the industry selling quantum computers has a staggering financial incentive to maintain that hype, and that the real reason to upgrade Bitcoin's cryptography is classical cryptanalysis — not quantum. The most common response I got: *"OK, but what is Bitcoin actually doing about it?"* So I went and read everything. Every Delving Bitcoin thread. Every Bitcoin Optech newsletter mention. The BIP. The academic papers. The mailing list arguments. The testnet reports. The Liquid transactions. Here's what I found: the work is real, it's more advanced than I expected, and the people doing it are some of the smartest engineers in the Bitcoin ecosystem. But they can't agree on anything, they're building at least seven competing solutions, and the actual bottleneck is bigger than anyone on either side wants to admit. --- ## Part 1: The "Nobody Is Working on This" Myth Let me introduce you to the people actually building quantum defenses for Bitcoin. You've probably never heard of most of them, because they publish in IACR preprints and Delving Bitcoin threads, not on Bloomberg. **Ethan Heilman** — [BIP-360](https://bip360.org/) author, the leading quantum-resistant address format proposal. Also proposed [STARK-based signature compression](https://delvingbitcoin.org/t/post-quantum-signatures-and-scaling-bitcoin-with-starks/1584) that could get post-quantum transaction overhead down to 76 bytes. **Jonas Nick** (Blockstream Research) — Lead developer of [SHRINCS](https://blog.blockstream.com/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/) and [SHRIMPS](https://delvingbitcoin.org/t/shrimps-2-5-kb-post-quantum-signatures-across-multiple-stateful-devices/2355), the most Bitcoin-optimized post-quantum signature schemes in existence. 324-byte signatures. Real transactions on Liquid. **Pieter Wuille** (sipa) — Bitcoin Core's most senior cryptographer. Co-author of SegWit, Taproot, [BIP 340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki). Also the loudest critic of BIP-360. More on that later. **Matt Corallo** — Bitcoin Core contributor. Leading voice for the "only hash-based schemes are trustworthy" position. Distrusts everything that came out of the NIST standardization process. **Tim Ruffing** (Blockstream Research) — Co-author of the Taproot BIP itself. Published a [formal proof](https://eprint.iacr.org/2025/1307) that Taproot's script-path spending is post-quantum secure. This is the single most underappreciated finding in the entire debate. **conduition** — [Optimized SLH-DSA verification](https://conduition.io/cryptography/quantum-hbs/) to match ECC speed. Proposed Dynamic Script Endorsement as an alternative migration path. Built a working [WOTS+ prototype](https://delvingbitcoin.org/t/winternitz-one-time-signatures-contrasting-between-lisp-and-script/1255) using OP_CAT. **jesseposner** — Working on [post-quantum equivalents for HD wallets (BIP-32), silent payments (BIP-352), MuSig, and FROST](https://delvingbitcoin.org/t/post-quantum-hd-wallets-silent-payments-key-aggregation-and-threshold-signatures/1854) threshold signatures using lattice-based constructions. Progress is real but uneven — HD wallets were [just solved in March 2026](https://eprint.iacr.org/2026/380) using a non-NIST scheme (Raccoon-G), while adaptor signatures have no PQ construction at all. More on the gaps below. **Olaoluwa Osuntokun** (roasbeef) — Lightning Labs CTO, BIP editor. Built a [working zk-STARK proof](https://github.com/Roasbeef/bip32-pq-zkp/tree/main) that BIP-32 wallet owners can prove seed knowledge without revealing it — solving an open problem from [Sattath & Wyborski's seed-lifting paper](https://eprint.iacr.org/2023/362). Also maintains a [living tracker](https://gist.github.com/Roasbeef/563f173fe44e2005e003a082716e586f) of all PQ Bitcoin development. His framing: "loosely synchronized exploration" that "does need to shift to more unified proposals." **Robin Linus** (ZeroSync/Stanford) — Creator of BitVM. Published [Binohash](https://robinlinus.com/binohash.pdf) in February 2026 — a collision-resistant hash function built entirely within Bitcoin Script using FindAndDelete mechanics and proof-of-work signature grinding. ~$50 on cloud GPUs. [Mainnet proof-of-concept already mined.](https://delvingbitcoin.org/t/binohash-transaction-introspection-without-softforks/2288) This is the foundation that QSB builds on. **Avihu Levy** (StarkWare) — Co-author of [ColliderScript](https://eprint.iacr.org/2024/1802) (2024, with Heilman, Kolobov, and Poelstra), which proved covenants are possible on Bitcoin without soft forks. Published [Quantum Safe Bitcoin (QSB)](https://github.com/avihu28/Quantum-Safe-Bitcoin-Transactions/) in April 2026 — the first scheme for quantum-resistant Bitcoin transactions using only existing consensus rules. No soft fork. $75-$150 per transaction. Not yet broadcast on-chain. **Tadge Dryja** — Proposed OP_CIV for cross-input signature aggregation and commit-delay-reveal protocols for emergency quantum defense. **Greg Maxwell** (nullc) — Proposed cross-signature aggregation for SHRINCS that could dramatically reduce multi-input transaction costs. Explicitly endorses the SHRIMPS direction: *"I think progress looks pretty reasonable."* There are others — cryptoquick, AdamISZ, simul, AbdelStark, MartinS84, ClaraShk, show1225. [Bitcoin Optech](https://bitcoinops.org/en/topics/quantum-resistance/) has covered quantum developments in **20+ newsletter issues** from June 2024 through April 2026. There are **15+ active threads** on [Delving Bitcoin](https://delvingbitcoin.org/) dedicated to post-quantum proposals. The work is happening. It's just happening where Bitcoin development has always happened: in technical forums where nobody screams about timelines because they're too busy arguing about opcodes. --- ## Part 2: Three Positions, Not Three Camps Bitcoin doesn't have a CEO who picks a direction. It has a handful of developers who each hold positions across three ongoing debates — and the same person can lean different ways on different questions. These aren't tribes. They're tendencies. But they're real, and they shape everything. ### Position 1: Ship the format now, argue about algorithms later [BIP-360](https://delvingbitcoin.org/t/proposing-a-p2qrh-bip-towards-a-quantum-resistant-soft-fork/956) — which has been through four name changes in two years (P2QRH → P2TRH → P2TSH → P2MR) — removes the quantum-vulnerable key-path from Taproot. New address format. New SegWit version. The PQ signature algorithms go in a separate follow-up BIP. Ethan Heilman and cryptoquick lead this effort. They have a testnet running: BTQ Technologies v0.3.0, 50+ miners, 100,000+ blocks, five Dilithium post-quantum opcodes active. It works. The criticism: the thing they're deploying doesn't actually include post-quantum signatures. It's a shell. The address format is ready, but the cryptographic payload is deferred. It's like building a bomb shelter with a "door goes here" sign on the front wall. But Heilman isn't only in the "ship it" camp. He also proposed STARK-based signature compression and an algorithm agility framework mixing Schnorr with SLH-DSA for 75-year custody — hedging toward hash-based schemes, not married to lattice. ### Position 2: Only hash-based schemes are trustworthy Matt Corallo says it plainly: *"The only remotely-practical thing we can do is add something that we have high confidence will still be secure in two decades — which basically is only hash-based schemes."* The evidence for distrust is reasonable. [SIKE](https://eprint.iacr.org/2022/975) was a NIST post-quantum finalist — broken on a laptop in an hour. [Chen published a lattice algorithm scare](https://blog.cryptographyengineering.com/2024/04/16/a-quick-post-on-chens-algorithm/) in 2024 that lasted ten days before someone found a fundamental bug. Cloudflare's assessment: *"a reminder that we have a lot of eggs in the lattices basket."* The Wedges attack on multivariate schemes in 2025 was, per researchers, *"surprising it wasn't found before."* Post-quantum cryptography is young, and young cryptography breaks. The hash-based answer: build with SHA-256 only — the hash function Bitcoin already trusts for proof-of-work, Merkle trees, and address derivation. No new mathematical assumptions. No [NIST](https://csrc.nist.gov/nist-cyber-history/cryptography/chapter). No [NSA](https://blog.cr.yp.to/20220805-nsa.html). Jonas Nick's [SHRINCS](https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158) produces **324-byte signatures** at NIST Level 1 security. That's only **5x larger** than current Schnorr signatures (64 bytes). For comparison, the NIST-standard [SLH-DSA](https://csrc.nist.gov/pubs/fips/205/final) is 7,856 bytes — 24x larger than SHRINCS. It's running on Liquid with real transactions. Stateful signing takes 3.7 seconds, verification is sub-millisecond. SHRIMPS extends this to multiple devices: ~2,500-byte signatures from any backup device, 3x smaller than SLH-DSA. A combined deployment looks like: primary wallet → SHRINCS (324 bytes), backup device → SHRIMPS (2.5 KB), emergency restore → SPHINCS+ fallback (3-8 KB). All under a single public key. Greg Maxwell proposed cross-signature aggregation — multiple SHRINCS keys sharing a single recovery key, with consensus requiring only one recovery signature for multiple inputs. This could make multi-input post-quantum transactions practical. The problem: **state management is unsolved.** Stateful signatures mean your hardware wallet needs to remember which one-time keys it has used. If state gets corrupted — power failure, wallet cloned to another device, parallel signing from two apps — you could reuse a one-time key and expose your entire signing authority. conduition identified fault injection, wallet duplication, and parallel signing race conditions as serious pitfalls. The Delving Bitcoin thread ends without resolving any of them. SHRINCS is not production-ready. Jonas Nick himself labels it "work in progress." Note: Nick builds hash-based signatures at Blockstream, where Adam Back calls the quantum threat "decades away" and Tim Ruffing publishes proofs that Taproot already has PQ properties. The positions overlap and coexist, even within the same company. ### Position 3: Individual migration is meaningless Pieter Wuille (sipa) — Bitcoin Core's most senior cryptographer — delivers the strongest objection to BIP-360: it provides "false security." His argument is simple and devastating. Millions of BTC will remain in EC-protected outputs regardless of whether individuals migrate. Lost wallets, dormant coins, Satoshi's stash. P2QRH protects the people who adopt it, but the network's overall quantum exposure barely changes. His deeper point is architectural. Taproot was designed to incentivize key-path spending — it's cheaper, so everyone uses it, and the resulting uniformity maximizes privacy. P2QRH removes the key-path entirely, reversing this incentive structure. You're not just adding quantum protection. You're undoing a deliberate privacy design. sipa's catch-22: individual migration is pointless unless the network collectively disables EC spending. But collectively disabling EC spending requires confiscating coins from anyone who doesn't migrate — and that's politically impossible for Bitcoin. But sipa's critique implicitly points toward the Ruffing two-phase path — disable key-path network-wide — which is actually a *more* aggressive intervention than anything the BIP-360 proponents are proposing. He's a skeptic about the current approach, not necessarily about action itself. conduition straddles all three positions — built WOTS+ prototypes (hash-based purist), proposed Dynamic Script Endorsement for BIP-360 (builder), and endorsed Corallo's approach of disabling P2TR key-spend. The positions aren't camps you belong to. They're lenses you look through on different questions. **The honest assessment:** Each position is partially right. The "ship it" crowd is doing the work but deploying an empty shell. The hash-based purists have the best cryptography but can't solve state management. The "migration is meaningless" position correctly identifies the governance paradox but offers no path forward. This is how Bitcoin development has always worked. It's messy, contentious, and slow. It also produced SegWit and Taproot. --- ## Part 3: The Escape Hatch Nobody Talks About Here's the finding that should be getting more attention than anything else in this debate. Tim Ruffing — the person who co-authored Taproot itself (BIPs 340, 341, and 342) — published a formal proof in July 2025 that **Taproot's script-path spending is already post-quantum secure.** The paper ([IACR ePrint 2025/1307](https://eprint.iacr.org/2025/1307)) proves this in the Quantum Random Oracle Model, treating SHA-256 as secure against quantum-superposition queries. The binding property holds: a quantum attacker cannot forge Taproot outputs that open to unintended Merkle roots. The hiding property holds: quantum adversaries cannot extract information about unrevealed Merkle roots. The quantified security bound: a minimum of **2^81 SHA-256 evaluations** for a 50% chance of commitment forgery. That's not happening — not with quantum computers, not with anything. To be clear: a Taproot output today is still quantum-vulnerable. The output is a public key on-chain, and a quantum attacker could compute its private key and spend via key-path — the script tree is irrelevant if key-path is still open. What Ruffing proved is that the *architecture* survives quantum. The commitment scheme that encodes the script tree into the on-chain public key cannot be broken, forged, or reverse-engineered by a quantum computer. The scripts inside are safe. The lock on the front door isn't — yet. This enables a two-phase migration that's dramatically simpler than starting from scratch: 1. Add post-quantum signature verification to Bitcoin's script language (soft fork) 2. Disable the ECDSA/Schnorr key-path before quantum computers arrive (soft fork) After Phase 2, the only way to spend a Taproot output is through its script tree — and if one of those script leaves requires a post-quantum signature, the output is quantum-safe. No new address format needed. No decade-long migration to entirely new output types. One soft fork to add PQ opcodes, one to lock the front door. ### The BIP 86 Problem Here's the part Ruffing's proof can't fix. **70-90% of P2TR outputs on-chain are key-path-only.** [BIP 86](https://github.com/bitcoin/bips/blob/master/bip-0086.mediawiki) — the standard Taproot construction used by Sparrow, Ledger, Trezor, and every major wallet — creates outputs with an "unspendable script path." That's not a metaphor. The script-path commitment uses a provably-unspendable internal key. There is no script tree. There is no door to the fire escape. Disabling key-path spending doesn't make these coins spendable via script-path. It makes them **permanently unspendable.** You can't retroactively add a script path — it's cryptographically committed in the output key. Changing the script tree means a different address entirely. This creates a catch-22 worse than sipa's: 1. Users need key-path spending to migrate their BIP 86 coins to new outputs with real script paths. 2. But key-path spending is exactly what quantum computers break. 3. The migration window between Soft Fork 1 (add PQ scripts) and Soft Fork 2 (disable key-path) must be long enough for **every user** to move their funds. 4. Anyone who doesn't migrate in time — lost keys, dormant wallets, Satoshi's coins — gets burned. This makes the Ruffing escape hatch structurally equivalent to QRAMP for the vast majority of existing Taproot outputs. The same confiscation dynamic. The same political impossibility. Ruffing proved that Taproot's *architecture* is post-quantum compatible. But most existing Taproot deployments aren't positioned to benefit. The building has a fire exit — but 70-90% of the apartments were built without a door to the fire escape. ### The zk-STARK Door Handle On the day I was finalizing this article, roasbeef [published a proof-of-concept](https://groups.google.com/g/bitcoindev/c/Q06piCEJhkI) that changes this picture. The insight is simple and, in retrospect, obvious. [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) — the HD wallet standard used by virtually every Bitcoin wallet since 2012 — starts by running the wallet seed through SHA-512. Even if a quantum attacker derives your private key from your public key, they can't reverse SHA-512 to get the seed. The hash function is quantum-resistant. The seed is safe. So what if you could prove, in zero knowledge, that a given on-chain public key was derived from your BIP-32 seed — without revealing the seed itself? That's what [roasbeef built](https://x.com/roasbeef/status/2041940571720487192). A zk-STARK proof (STARKs are post-quantum — they use hash functions, no elliptic curves, no trusted setup) that proves: "public key P was generated using a private key k, which was derived via BIP-32/BIP-86 from a master secret S." The proof reveals nothing about S. The numbers: ~50 seconds to generate on an M4 Max. ~1:28 on an M1 Max ([independently reproduced](https://x.com/evankaloudis/status/2041975032667095341) by Evan Kaloudis, who ran the full PoC locally). Raw proof size: 1.7 MB — but [Luke Childs pointed out](https://x.com/lukechilds/status/2041963559152972227) that risc0's recursive proof composition (a [one-line SDK change](https://docs.rs/risc0-zkvm/3.0.5/risc0_zkvm/struct.SuccinctReceipt.html)) compresses this to ~200 KB. Multiple proofs can be aggregated across an entire block. This matters because it breaks the catch-22. If an emergency softfork disables key-path spending: 1. Wallets with script paths use Ruffing's escape hatch (script-path spend with PQ sig) 2. BIP 86 wallets — the 70-90% with no script path — submit a zk-STARK proof of seed ownership and migrate to a PQ-safe output 3. The only coins that stay locked are non-BIP-32 wallets (raw key imports, pre-2012 wallets) and genuinely lost seeds The confiscation surface shrinks from "most Taproot users" to a much smaller population. It's not zero — non-HD wallets are still stuck, and the proof requires a consensus change to verify on-chain. But it's a different political conversation. "Some old wallets get burned" is a hard sell. "Every wallet that's been using the standard since 2012 has an escape route" is much easier. roasbeef also [confirmed this extends beyond Taproot](https://x.com/roasbeef/status/2042006593680896450) — it works for any BIP-32 derived output: P2PK, P2PKH, P2SH, P2WSH. And [niftynei raised the possibility](https://x.com/niftynei/status/2041963916356461036) that Rusty Russell's GSR (Great Script Restoration) proposal could enable in-script STARK verification without needing a dedicated new opcode. roasbeef found an [existing benchmark](https://delvingbitcoin.org/t/benchmarking-bitcoin-script-evaluation-for-the-varops-budget-great-script-restoration/2094/17) on Delving Bitcoin where someone already tried getting a STARK verifier running with GSR. It's a proof of concept, not a production deployment. A specialized circuit would produce smaller, faster proofs. But the building blocks exist. The fire exit has a door handle. It's a prototype door handle, and it needs work, but it fits most apartments. conduition built on the Ruffing proof separately with "Dynamic Script Endorsement" — a proposal where users start embedding hash-based one-time-signature commitments in their Taproot script trees today, before PQ opcodes even exist. When PQ opcodes become available, wallets upgrade without moving funds. The catch: it only helps outputs created *after* wallets adopt it. But combined with roasbeef's zk-STARK scheme for existing BIP 86 outputs, the coverage starts to look real. ### The No-Fork Path: Quantum Safe Bitcoin (QSB) Every approach discussed so far requires a soft fork. Even the most conservative — the Ruffing two-phase path — needs one fork to add PQ opcodes and another to disable key-path. BIP-360 needs a new address format. SHRINCS needs new script verification. The governance bottleneck applies to all of them. What if you could skip it entirely? [Avihu Levy](https://github.com/avihu28/Quantum-Safe-Bitcoin-Transactions/) — a StarkWare researcher who co-authored [ColliderScript](https://eprint.iacr.org/2024/1802) with Heilman, Kolobov, and Poelstra — published a scheme that achieves quantum-resistant Bitcoin transactions using **only the consensus rules that exist today.** No soft fork. No new opcodes. No activation signal. No politics. The lineage matters: In 2024, ColliderScript proved that covenants are possible on Bitcoin without consensus changes, using 160-bit hash collisions — at a ludicrous cost of ~$50 million per transaction. In February 2026, Robin Linus published [Binohash](https://robinlinus.com/binohash.pdf), which collapsed that cost to ~$50 on cloud GPUs by exploiting FindAndDelete behavior in legacy `OP_CHECKMULTISIG`. Binohash has a [mainnet proof-of-concept transaction already mined](https://delvingbitcoin.org/t/binohash-transaction-introspection-without-softforks/2288). QSB takes Binohash's technique and applies it to quantum resistance specifically. **How it works:** The locking script embeds a hardcoded ECDSA signature with a known nonce. When you spend, you provide a public key that the script verifies against your transaction's sighash — binding the key to your specific transaction. The script then hashes that public key through RIPEMD-160 and *interprets the 20-byte output as another ECDSA signature.* A random 20-byte string satisfies DER encoding constraints with probability roughly 2^-46 — about 1 in 70 trillion. The spender grinds through transaction parameters (sequence number, locktime) until the hash output happens to be valid DER. Two additional rounds use subset selection from 150 embedded dummy signatures to produce a [HORS](https://en.wikipedia.org/wiki/Hash-based_cryptography#Few-time_signature_schemes)-like one-time signature digest. **Why this is quantum-safe:** The security rests entirely on hash pre-image resistance. Shor's algorithm breaks ECDSA by computing discrete logarithms — but here, ECDSA is just a computational vehicle. The actual puzzle is: find a transaction whose derived public key hashes to a valid DER signature. That's a hash pre-image problem. Shor's algorithm provides zero advantage against it. Grover's algorithm gives a quadratic speedup, reducing the effective security from ~138-bit to ~69-bit for second pre-image resistance — still far beyond feasibility. This is also what distinguishes QSB from Binohash. Binohash's security depends on the assumption that the spender is forced to use the smallest known ECDSA r-value. But Shor's algorithm can compute the discrete log of *any* elliptic curve point — including the point with the absolute smallest r. An adversary with a quantum computer could produce signatures with a shorter r than the assumed minimum, breaking the puzzle entirely. QSB's hash-to-signature puzzle doesn't depend on any EC assumption at all. The hash function is the security foundation. **The numbers:** GPU search achieves 238 million candidates per second on an RTX PRO 6000. Levy found a real DER hit at sequence=151205, locktime=656535577 after ~6 hours on 8 GPUs. Estimated cost for the full three-phase process: **$75-$150** in cloud GPU compute, scaling inversely with hardware thrown at it. **The catches — and they're real:** First, **legacy script only.** QSB relies on FindAndDelete and the SIGHASH_SINGLE signing bug — both absent from SegWit and Taproot. You can't use this with modern address formats. The scheme is limited to bare scriptPubKey outputs, which exceed the 520-byte P2SH redeem script limit. This means non-standard transactions that won't propagate through the normal Bitcoin P2P network. Second, **miner-direct submission.** Because the transactions are non-standard, you need to submit directly to a mining pool that accepts them — like Marathon's [Slipstream](https://slipstream.mara.com/). This is a meaningful centralization pressure. Normal Bitcoin transactions can be broadcast to any node; QSB transactions need a specific miner's cooperation. Third, **$75-$150 per transaction.** That's orders of magnitude more expensive than a standard Bitcoin transaction. It's acceptable for high-value cold storage protection — if you're securing 100 BTC, $150 is rounding error — but it doesn't scale to everyday payments or Lightning channel opens. Fourth, **not yet on-chain.** The paper and GPU search tools are complete. A real DER hit was found. But the full pipeline — transaction assembly and broadcast — hasn't been demonstrated. Binohash has a mainnet transaction. QSB doesn't. Yet. Fifth, **no formal security proofs.** The security analysis is detailed and the reasoning is sound, but formal proofs are listed as future work. **What this means for the broader debate:** QSB doesn't replace any of the soft-fork approaches. It's too expensive, too constrained, and too limited in scope to be a general solution. But it does something none of the others can: it's available *now*. Not after a BIP review process. Not after activation signaling. Not after a seven-year migration timeline. Right now, with existing Bitcoin, if you have $150 and access to a GPU farm. This is a philosophically significant development. The entire governance section of this article — Part 7, below — is about Bitcoin's inability to soft-fork in a timely manner. QSB is the first credible demonstration that quantum resistance can be achieved without asking anyone's permission. The cost will come down as hardware improves and the pipeline is optimized. The constraint to legacy script is fundamental to the current approach, but the underlying technique — hash-to-signature puzzles where security rests on hash functions, not curves — could inform future protocol designs that *do* include soft forks. The intellectual trajectory is worth tracking: $50 million (ColliderScript, 2024) → $50 (Binohash, February 2026) → $75-$150 for quantum safety (QSB, April 2026). Three orders of magnitude in two years. The technique is young. The costs compress fast. --- ## Part 4: The Math Is Progressing. It Is Not Done. I implied in Parts 1 and 2 that the cryptographic research was largely handled — that the remaining challenge was governance. That was wrong, or at least incomplete. Here's where the math actually stands: | Feature | PQ Status | Severity | |---------|-----------|----------| | **Basic signatures** | Exist but 40-120x larger (NIST) or 5x (SHRINCS) | Manageable | | **HD wallets (full BIP-32)** | Just solved March 2026; requires non-NIST scheme (Raccoon-G) | Significant | | **Adaptor signatures** | **No PQ construction exists** | **Critical** — breaks Lightning, DLCs, atomic swaps | | **Key aggregation (MuSig)** | Requires trusted third party | Incompatible with Bitcoin | | **Threshold sigs (FROST)** | Limited to t<=8, +1.4KB overhead | Partial | | **Cross-input aggregation** | Largely unsolved | Significant | The killer gap is **adaptor signatures.** Lightning Network — Bitcoin's primary scaling solution — depends on them. No PQ adaptor signature construction exists even in theory. This isn't "the math is almost done" — this is "the math for a critical subsystem hasn't started." The math for basic PQ transaction signing exists, with significant size penalties. But Bitcoin isn't just transaction signing. It's HD wallets (just solved in March 2026 using a non-standard scheme), threshold signatures (limited), key aggregation (requires trusted setup), and adaptor signatures (no PQ construction exists at all). Lightning Network — Bitcoin's scaling layer — has no known post-quantum path. The math is progressing. It is not done. --- ## Part 5: Fourteen Proposals, Fourteen Limitations Here's every proposal on the table, in plain English, with the limitation nobody wants to talk about. | Proposal | What It Does | Status | The Catch | |----------|-------------|--------|-----------| | **[BIP-360 / P2MR](https://bip360.org/)** | New address format (bc1z), Taproot minus key-path | Published BIP, testnet running | Doesn't include PQ signatures — those are deferred | | **[SHRINCS](https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158)** | 324-byte hash-based signatures | Real Liquid transactions | State management unsolved; "not production-ready" | | **[SHRIMPS](https://delvingbitcoin.org/t/shrimps-2-5-kb-post-quantum-signatures-across-multiple-stateful-devices/2355)** | 2.5 KB multi-device PQ signatures | Prototype | Extension of SHRINCS; inherits same state problems | | **QRAMP** | Hard fork, burn unprotected coins after deadline | Discussion only | Politically radioactive; nullc flags "backdoors and consent" | | **[Ruffing Taproot Proof](https://eprint.iacr.org/2025/1307)** | Script-path is already PQ-safe (2^81) | Peer-reviewed proof | 70-90% of P2TR outputs are key-path-only (BIP 86); migration = QRAMP | | **[zk-STARK BIP-32 Escape](https://github.com/Roasbeef/bip32-pq-zkp/tree/main)** | Prove seed ownership via STARK; migrate without key-path | **Working PoC** (Apr 2026) | ~200 KB proof; needs consensus change for on-chain verification | | **[Lifted Signatures](https://eprint.iacr.org/2023/362)** | Use existing HD wallet keys for PQ spending | Academic paper | Open problem solved by roasbeef's zk-STARK above | | **[OP_CTV Path](https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168)** | Quantum resistance with NO new crypto | Conceptual | Requires OP_CTV activation (its own political fight) | | **[STARK Compression](https://delvingbitcoin.org/t/proposal-op-stark-verify-native-stark-proof-verification-in-bitcoin-script/2056)** | Aggregate PQ sigs per block → 76 bytes/tx | Proposal + prototype | OP_STARK_VERIFY has unresolved transaction-binding bug | | **Yellowpages** | Off-chain PQ address registry | $6M funded, Cure 53 audit | Relies on social consensus; no protocol enforcement | | **[Hourglass V2](https://delvingbitcoin.org/t/proposal-per-block-legacy-transition-budget-as-quantum-mitigation-soft-fork/1929)** | Gradually restrict vulnerable address spending | Proposal | Still needs a soft fork | | **[Binohash](https://robinlinus.com/binohash.pdf)** | Collision-resistant hash in Bitcoin Script; transaction introspection without soft fork | **Mainnet tx mined** (Feb 2026) | Not quantum-safe — relies on EC r-value assumption breakable by Shor | | **[Quantum Safe Bitcoin (QSB)](https://github.com/avihu28/Quantum-Safe-Bitcoin-Transactions/)** | PQ transactions using only existing consensus rules — no soft fork | Paper + GPU tools complete (Apr 2026) | $75-$150/tx; legacy script only; miner-direct submission; not yet on-chain | | **[PQC Precommitment (Buchner)](https://github.com/csuwildcat/pqc-precommitment-migration)** | Forward-compatibility slots in tapscript: tagged SLH-DSA/SHRINCS pubkeys sit inside a BIP 342 leaf today as unknown-key types, upgradeable via soft fork without rewriting the output | **Draft BIP + spec** (Apr 2026) | Consensus-valid today only as an ordinary Schnorr spend with dummy slot witnesses; real PQ verification requires a future soft fork; doesn't address Taproot key-path; non-standard relay | Fourteen approaches. Zero consensus. Two of them don't need consensus at all. One of them is a forward-compatibility hook you can use today that gains real PQ verification whenever Bitcoin eventually soft-forks — whichever path it picks. Welcome to Bitcoin. ### The Precommitment Hook — "Do Something Today" Without Betting on a Soft Fork Every other proposal in that table either (a) needs a specific soft fork to activate and then a migration spend to move your coins into a new address format, or (b) is a one-off quantum-safe spend that costs $75–$150 and can't be relayed through normal channels. Both categories assume you know which fork path Bitcoin will take. Daniel Buchner's [draft BIP](https://github.com/csuwildcat/pqc-precommitment-migration) (April 10, 2026) skips that bet. It uses a corner of BIP 342 that nobody was really using: in current tapscript, any non-zero-length public key whose length is not 32 bytes is an *unknown* tapscript public key type, and signature validation for unknown key types is treated as successful whenever the provided signature element is non-empty. That corner was left deliberately open so future soft forks could add new signature algorithms without redesigning tapscript. Buchner's insight: you can use that corner *right now* as a forward-compatibility slot. Encode a real SLH-DSA or SHRINCS public key with a one-byte tag (`0x10`–`0x12` for SLH-DSA, `0x20`–`0x22` for SHRINCS), drop it into a tapscript leaf next to a real Schnorr key, and spend it today with a non-empty dummy witness. You get an ordinary Schnorr-secured spend under current rules, and you commit — on-chain, inside the script — to the exact post-quantum verification slots you'd want after activation. When (if) a later soft fork binds real semantics to those tags, with the full PQ signature material transported via the annex instead of the existing `sig` operand, the same UTXO becomes strictly PQ-verified with no migration spend required. What it doesn't do (Buchner is explicit): it does not solve Taproot's exposed key-path. It assumes something like BIP 360's `P2MR` handles long-range key-path exposure separately. It is also currently non-standard under Bitcoin Core default relay policy — unknown tapscript key types don't propagate through the normal mempool, so actually *spending* one of these outputs today means going direct to a mining pool that accepts non-standard transactions, the same way QSB needs Slipstream or equivalent. And the exact post-activation wire format is intentionally left for the future soft fork to pin down. What it does is make "I want to quell my quantum anxiety today without waiting on governance" into a cheap, on-chain action that survives whichever path Bitcoin picks later. You don't have to pick BIP 360 vs. SHRINCS vs. STARK compression first — the slots just sit there, pre-committed, and whichever scheme eventually gets real verification rules is the one that wakes them up. If Q-day never comes, you never spent extra on anything. If it does, the UTXO you parked in April 2026 just ... becomes quantum-safe on its own. It's the first proposal in this entire document that treats "what should a worried holder do right now" as a solvable problem with a one-line answer. --- ## Part 6: What to Actually Watch (And What to Ignore) ### Factoring Records: More Complicated Than I Said I said in Part 2 that the largest number factored by a quantum computer is 21. I was wrong. It's **15**. [Craig Gidney](https://algassert.com/post/2500) — who works on Google's quantum team — explains that the 2012 factoring of 21 baked the answer into the circuit. The expensive modular multiplications were bypassed. The result was circular. But here's the deeper point, and it's one I didn't appreciate until after Parts 1 and 2 were published. [Bas Westerbaan](https://bas.westerbaan.name/notes/2026/04/02/factoring.html) (Cloudflare) argues — with explicit support from Gidney, Aaronson, Jaques, and Zalcman — that factoring records are **fundamentally the wrong benchmark** for tracking Q-day. Error correction has a massive baseline overhead. Once that overhead is conquered, scaling from small numbers to RSA-2048 is fast. There won't be a gradual progression of factoring records — 15, then 50, then 200, then 500. There will be nothing for years, then a 32-bit number, then RSA-2048 soon after. Aaronson compares it to expecting a small nuclear explosion before the big one. The physics doesn't work that way. So the factoring scoreboard I used in Part 2 was rhetorically powerful but logically weak. The VIC-20 comparison is still funny. It's just not as comforting as I made it sound. **But the step function has width.** [Gidney's 2025 resource estimates](https://arxiv.org/pdf/2505.15917) show a 30x physical qubit increase and 32,000x gate increase between 32-bit and 2048-bit Shor's. Those are real engineering steps, not overnight. And Gidney himself said on Hacker News (as Strilanc) that factoring "will be okay for tracking progress later" — it's only a bad benchmark *now* because nothing uses error correction yet. Once fault-tolerant computation exists, factoring records will start being meaningful again. The step function is real — the QEC baseline overhead means the hardest single engineering step is achieving fault tolerance at all. By the time you can run Shor's on *anything* with real error correction, you're already in the danger zone. But the step isn't vertical. There's engineering distance between the first fault-tolerant factoring and breaking secp256k1. ### Watch: The ECDLP Challenge Suite A team published a purpose-built benchmarking suite targeting Bitcoin's exact curve — secp256k1 ([arXiv 2508.14011](https://arxiv.org/abs/2508.14011)). Graduated difficulty from 6-bit to 256-bit. Each challenge is deterministic and publicly attemptable. It's a "transparent ruler" for tracking quantum progress. Their conditional timeline finding: the full 256-bit challenge falls within a **2027-2033 window**, under assumptions about physical error rates and non-Clifford gate supply. That's more aggressive than expert surveys, but it's calibrated against actual hardware parameters, not vibes. **An important caveat:** ECDLP faces the same step-function problem as factoring. Both use Shor's algorithm. Both require the same error correction overhead. If factoring has a cliff — nothing, nothing, broken — then ECDLP does too. You can't dismiss factoring records while treating ECDLP milestones as an early warning system. The ECDLP ladder is better not because it avoids the step function, but because it provides **finer gradations above the QEC threshold.** The Luo et al. resource estimates show ECC-160 needs 849 logical qubits vs ECC-256's 1,333. More rungs on the ladder in the post-fault-tolerance scaling regime. Once fault tolerance arrives, the ECDLP suite gives you a better ruler for measuring how fast the approach is accelerating. But don't confuse the ruler for early warning. Neither factoring nor ECDLP gives you warning before the cliff. ### Watch: Error Correction Milestones | Milestone | Status (2026) | What It Means | |-----------|--------------|---------------| | Below-threshold QEC | [Achieved](https://arxiv.org/abs/2408.13687) (Google Willow) | Error correction works in principle | | Sustained fault-tolerant computation (minutes) | **Not achieved** (current: milliseconds) | Required for Shor's to actually run | | 1,200+ logical qubits | **Not close** (current: 48-94) | The threshold for breaking secp256k1 | The gap between "error correction works on 100 qubits" and "Shor's algorithm runs on 1,200 logical qubits for 9 minutes" is the gap between a Wright Flyer and a 747. ### Watch: Quantum Canaries [Sattath and Wyborski](https://eprint.iacr.org/2023/362) proposed posting classically-unsolvable but quantum-solvable puzzles on-chain. If someone solves one, quantum computers have arrived — but not yet at a scale that breaks ECDSA. This provides advance warning without relying on vendor announcements or expert surveys. Not deployed yet. Should be. ### Watch: Hardware Wallets [Trezor Safe 7](https://trezor.io/guides/trezor-devices/trezor-safe-7/the-first-quantum-ready-hardware-wallet) is the only shipping hardware wallet with any post-quantum cryptography. But it protects the firmware and boot process — **not** on-chain transaction signing. That distinction matters. Your PQ-verified bootloader doesn't help if the signature scheme that protects your Bitcoin is still ECDSA. Ledger has internal trials. Coldcard and Foundation have roadmap items. No one else has shipped anything. Institutional custodians need **2-3 years** to rotate key infrastructure once blockchain PQC standards finalize. The hardware, not the algorithms, is the practical bottleneck. --- ## Part 7: The Governance Problem This is the part that actually worries me. The cryptography is being worked on. Seventeen people are building thirteen solutions. Some of them are genuinely clever. SHRINCS is real engineering. The Ruffing proof is mathematically beautiful. The STARK compression is ambitious. QSB is a conceptual breakthrough. But two things have to be true at once for Bitcoin to survive quantum: the math has to work *and* it has to ship. The math isn't finished — Lightning has no post-quantum path, key aggregation needs trusted setup, adaptor signatures don't exist — and the shipping mechanism is broken. Bitcoin's last soft fork activated in **[November 2021](https://charts.bitbo.io/segwit-adoption/)**. That's four and a half years ago. Nothing has been activated since — not because nothing is ready, but because the community cannot agree on what to activate next. [Ethan Heilman, BIP-360's author](https://www.tradingview.com/news/cointelegraph:30729863f094b:0-bitcoin-may-take-7-years-to-upgrade-to-post-quantum-bip-360-co-author/), estimates **7 years** for full post-quantum migration. He admits that's "spitballing." Break it down: 2.5 years for BIP development and code review, 0.5 years for activation, 4 years for ecosystem migration. That gets you to 2033, four years after Google's internal PQC deadline. The realistic number is worse. SegWit took 2+ years of bitter debate, a UASF threat, and still caused a chain split. If BIP-360 is even half as contentious — and sipa's fundamental objection suggests it will be — add another 2-3 years of politics. Meanwhile: | Actor | PQ Migration | |-------|-------------| | Google | 2029 (internal deadline) | | US Federal agencies | April 2026 (transition plans due) | | [Cloudflare](https://blog.cloudflare.com/pq-2025/) | **65%** of traffic already PQ-encrypted | | Ethereum | Formal roadmap, weekly testnets, [pq.ethereum.org](https://pq.ethereum.org) hub | | **Bitcoin** | 0% mainnet PQ transactions (but a no-fork path now exists, and a forward-compat precommitment hook landed April 10) | QSB complicates this table. Bitcoin still has zero mainnet PQ transactions via protocol-level changes. But the no-fork path exists — it's expensive, it's limited to legacy script, and it needs miner cooperation for relay — but it's not zero. Someone with $150 and GPU access could, in principle, create a quantum-resistant Bitcoin transaction today. Buchner's April 10 precommitment BIP complicates it further: a worried holder can, right now, park coins into a tapscript leaf whose unknown-key slots already commit to the exact SLH-DSA or SHRINCS verification rules a future soft fork is likely to bind — and pay nothing beyond the small dummy-witness weight. The governance bottleneck is real, but it's no longer the *only* path, and it no longer has to be decided before individual holders can act defensively. sipa is right that the governance problem is the real problem. He's just wrong to conclude that the answer is doing nothing. nullc's framing is more useful. He says the work is happening, the progress is reasonable, and **[NIST's PQ standards](https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards) have the wrong tradeoffs for Bitcoin anyway** — they're optimized for TLS (fast signing, reusable keys, big signatures), while Bitcoin needs the opposite (small signatures, single-use keys, signing speed irrelevant). The Bitcoin-specific work — SHRINCS, SHRIMPS, the Ruffing proof — is more important than the NIST standards that the rest of the industry is scrambling to adopt. He also claims the urgency narrative is partly driven by "at least two distinct cons with an almost identical script" — fraud schemes raising substantial funds by promising to build quantum computers to steal Bitcoin. For every investor they convince, nullc estimates 99 others are panicked into believing the threat is imminent. The FUD is a byproduct of the fundraising. --- ## What You Should Actually Do **If you hold Bitcoin:** Stop reusing addresses. Keep long-term holdings in addresses you've never spent from — your public key is hidden behind a hash, but only until you spend. Once you spend from an address, the key is on-chain and any funds received afterward are exposed. Taproot (bc1p) is the exception — it exposes the tweaked public key immediately, no spending required. Be cautious with your xpub. When bc1z addresses become available, use them. And ignore the headlines — the papers are more interesting and less scary. **If you're a developer:** The SHRINCS Simplicity verifier is on GitHub. jesseposner's [PQ HD-wallet work](https://delvingbitcoin.org/t/post-quantum-hd-wallets-silent-payments-key-aggregation-and-threshold-signatures/1854) needs reviewers. The [OP_STARK_VERIFY](https://delvingbitcoin.org/t/proposal-op-stark-verify-native-stark-proof-verification-in-bitcoin-script/2056) transaction-binding bug needs a fix. Avihu Levy's [QSB pipeline](https://github.com/avihu28/Quantum-Safe-Bitcoin-Transactions/) needs someone to complete the transaction assembly and get the first quantum-safe transaction on-chain — that's a milestone worth chasing. The state management problem for stateful signatures is the biggest unsolved engineering challenge in this space — it's a career-making problem for someone who solves it. And BIP-360 needs constructive critics, not just cheerleaders. If you work on Lightning: the adaptor signature gap is your problem, and nobody else is solving it. **If you run an institution:** Start planning for a 2-3 year key rotation window. Track the [ECDLP challenge suite](https://arxiv.org/abs/2508.14011) for empirical threat progression. The [Trezor Safe 7](https://trezor.io/guides/trezor-devices/trezor-safe-7/the-first-quantum-ready-hardware-wallet) is the only hardware wallet shipping any PQC at all. And talk to your custodian about their quantum roadmap — if they don't have one, that's your answer. **If you just want one sentence:** The house isn't on fire, the builders are working, one of them just demonstrated a door that fits most apartments, and another proved you can barricade your own door without waiting for building management — it just costs more. --- ## The Honest Conclusion Here's where I ended up after reading every proposal, every thread, every mailing list argument. The quantum computing industry is still full of shit. That hasn't changed since Part 2. The timelines are still manufactured, the insiders are still selling, the roadmaps are still being revised backward. But the Bitcoin developers working on post-quantum defense are not full of shit. They're doing real work, with real math, producing real results. SHRINCS is clever engineering. The Ruffing proof is a genuine breakthrough. The STARK compression is ambitious but sound. Even the proposals I find least convincing — QRAMP, Yellowpages — represent serious people thinking about hard problems. The engineering is harder than either side admits. The step function means we won't get gradual warning — but the step has width, and factoring milestones with real error correction *would* be meaningful. The math for basic PQ signing exists — but the full toolkit (Lightning, HD wallets, multisig, privacy) doesn't. Not yet. Taproot has a PQ-compatible architecture — and roasbeef just demonstrated that most existing Taproot outputs *can* be rescued via zk-STARK seed proofs, even the BIP 86 ones everyone thought were stuck. Devs are working — and the work ahead is larger than any single proposal covers, but the pieces are starting to fit together. And now there's a parallel track. QSB proved that Bitcoin's existing scripting language — the one Satoshi shipped in 2009 — contains enough raw computational power to build quantum-resistant transactions without touching consensus. The cost trajectory from ColliderScript ($50M) through Binohash ($50) to QSB ($75-$150) shows how fast these techniques improve once the conceptual breakthrough lands. QSB isn't a replacement for soft-fork solutions — it's too expensive, too constrained, and too limited for general use. But it eliminates the argument that Bitcoin is *helpless* without governance action. Someone can act, today, without permission. That changes the political calculus, even if the technique itself remains niche. The threat they're defending against probably isn't coming in five years. It might not come in twenty. It might never come at all. But the defense-in-depth argument from Part 2 still holds: a $2 trillion network shouldn't rely on a single cryptographic assumption, regardless of whether quantum computers ever arrive. The actual race isn't Bitcoin vs. quantum computers. It's Bitcoin vs. its own governance speed. Seventeen developers, fourteen proposals, three overlapping positions (plus a fourth that says skip the politics entirely, and now a fifth that says pre-commit today and let the soft fork catch up later), one consensus mechanism, and a protocol that hasn't soft-forked in four and a half years. The house isn't on fire. The builders are working. They're building multiple fire exits and none of them leads to every apartment *yet*. One builder demonstrated a door that fits most apartments — a proof-of-concept that uses quantum-resistant math already embedded in every BIP-32 wallet since 2012. Another proved you can barricade your own door using nothing but the materials already in the walls — it costs more, it only works in certain apartments, but it works *today* and it doesn't require a vote from the building committee. And on April 10, a new builder proposed something quieter and arguably more useful: pre-install a reinforced frame around your door today, using an empty slot the original blueprints left behind, so that whenever the building committee eventually picks a lock standard, your door is ready — without ever moving your furniture. The building blocks are there. The work is happening where Bitcoin development always happens — in mailing lists, Delving Bitcoin threads, and GitHub repos where nobody screams about timelines because they're too busy writing proofs. The correct posture is not panic. It's not complacency. It's the tedious, expensive, unglamorous engineering that doesn't make headlines but eventually ships. --- ## Changelog - **2026-04-11 (v5)**: Added Buchner's PQC precommitment slots as the 14th proposal. Updated TL;DR, Part 5 table, Part 5 narrative section ("The Precommitment Hook"), Part 7 framing ("fourteen proposals"), and The Honest Conclusion. The underlying analysis of the other 13 proposals is unchanged. - **2026-04-09 (v4)**: Added roasbeef's zk-STARK BIP-32 escape hatch and QSB (Avihu Levy). Initial published version. --- *Sources: 95+ research documents including [Quantum Safe Bitcoin (QSB)](https://github.com/avihu28/Quantum-Safe-Bitcoin-Transactions/) (Avihu Levy, April 2026), [Binohash](https://robinlinus.com/binohash.pdf) (Robin Linus, February 2026; [Delving Bitcoin thread](https://delvingbitcoin.org/t/binohash-transaction-introspection-without-softforks/2288); [Bitcoin Optech #396](https://bitcoinops.org/en/newsletters/2026/03/13/)), [ColliderScript](https://eprint.iacr.org/2024/1802) (Heilman, Kolobov, Levy, Poelstra, 2024), [Heilman Lamport Signatures](https://mailing-list.bitcoindevs.xyz/bitcoindev/CAEM=y+XyW8wNOekw13C5jDMzQ-dOJpQrBC+qR8-uDot25tM=XA@mail.gmail.com/) (2024), [Ruffing Taproot PQ commitment](https://eprint.iacr.org/2025/1307) (IACR 2025/1307), [Dallaire-Demers ECDLP Challenges](https://arxiv.org/abs/2508.14011) (arXiv 2508.14011), [Sattath & Wyborski lifted signatures](https://eprint.iacr.org/2023/362) (ePrint 2023/362), [Gidney 2025 resource estimates](https://arxiv.org/pdf/2505.15917), Luo et al. 2026 ECDLP resource estimates, [ePrint 2026/380 Lattice HD Wallets](https://eprint.iacr.org/2026/380), [BIP 86](https://github.com/bitcoin/bips/blob/master/bip-0086.mediawiki)/[341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) specifications, [Westerbaan factoring benchmark critique](https://bas.westerbaan.name/notes/2026/04/02/factoring.html), Gidney (Strilanc) HN comment on factoring-as-benchmark, [roasbeef zk-STARK BIP-32 proof-of-concept](https://github.com/Roasbeef/bip32-pq-zkp/tree/main) (bip32-pq-zkp, April 2026), [roasbeef PQ Bitcoin work tracker gist](https://gist.github.com/Roasbeef/563f173fe44e2005e003a082716e586f), [Buchner PQC Precommitment draft BIP](https://github.com/csuwildcat/pqc-precommitment-migration) (April 2026), 15+ [Delving Bitcoin](https://delvingbitcoin.org/) threads, 20+ [Bitcoin Optech](https://bitcoinops.org/en/topics/quantum-resistance/) newsletters (#307-#399), [SHRINCS](https://blog.blockstream.com/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/)/[SHRIMPS](https://delvingbitcoin.org/t/shrimps-2-5-kb-post-quantum-signatures-across-multiple-stateful-devices/2355) Liquid deployment data, [BIP-360](https://bip360.org/) testnet reports, nullc HN commentary, and the complete source list from [Part 1](https://x.com/nvk/status/2041162989760590171) and [Part 2](https://x.com/nvk/status/2041644230620139787).* ---