⚡Bitcoin & Quantum
Part 3

I Read Every Bitcoin Quantum Proposal. Here's Where We Actually Are.

by @nvk · April 9, 2026 · Updated April 11, 2026
I Read Every Bitcoin Quantum Proposal. Here's Where We Actually Are. Read the original thread on X

Part 3. Part 1 here. Part 2 here. 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.

What’s new — April 11, 2026

Added a 14th proposal: Daniel Buchner’s PQC Precommitment for Post-Quantum Migration (draft BIP, April 10). It uses a corner of BIP 342 to let you pre-commit to SLH-DSA or SHRINCS verification slots inside a tapscript leaf today — spendable with dummy witnesses now, upgradeable via a future soft fork without rewriting the output. It’s the first proposal designed to let a worried holder do something today without betting on which soft fork Bitcoin eventually picks.

Jump to: TL;DR bullet · proposals table · The Precommitment Hook · changelog

The other 13 proposals and the broader analysis are unchanged since April 9.

TL;DR

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 author, the leading quantum-resistant address format proposal. Also proposed STARK-based signature compression that could get post-quantum transaction overhead down to 76 bytes.

Jonas Nick (Blockstream Research) — Lead developer of SHRINCS and SHRIMPS, 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. 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 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 to match ECC speed. Proposed Dynamic Script Endorsement as an alternative migration path. Built a working WOTS+ prototype using OP_CAT.

jesseposner — Working on post-quantum equivalents for HD wallets (BIP-32), silent payments (BIP-352), MuSig, and FROST threshold signatures using lattice-based constructions. Progress is real but uneven — HD wallets were just solved in March 2026 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 that BIP-32 wallet owners can prove seed knowledge without revealing it — solving an open problem from Sattath & Wyborski’s seed-lifting paper. Also maintains a living tracker 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 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. This is the foundation that QSB builds on.

Avihu Levy (StarkWare) — Co-author of ColliderScript (2024, with Heilman, Kolobov, and Poelstra), which proved covenants are possible on Bitcoin without soft forks. Published Quantum Safe Bitcoin (QSB) 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 has covered quantum developments in 20+ newsletter issues from June 2024 through April 2026. There are 15+ active threads on Delving Bitcoin 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 — 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 was a NIST post-quantum finalist — broken on a laptop in an hour. Chen published a lattice algorithm scare 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. No NSA.

Jonas Nick’s SHRINCS 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 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) 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 — 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 that changes this picture.

The insight is simple and, in retrospect, obvious. BIP-32 — 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. 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 by Evan Kaloudis, who ran the full PoC locally). Raw proof size: 1.7 MB — but Luke Childs pointed out that risc0’s recursive proof composition (a one-line SDK change) 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 — it works for any BIP-32 derived output: P2PK, P2PKH, P2SH, P2WSH. And niftynei raised the possibility 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 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 — a StarkWare researcher who co-authored ColliderScript 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, 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. 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-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. 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:

Post-Quantum Feature Status for Bitcoin

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 updated apr 11

Here’s every proposal on the table, in plain English, with the limitation nobody wants to talk about.

Bitcoin Post-Quantum Proposals: 13 approaches

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 new apr 11

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 (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 — 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 (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 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). 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

Error Correction Milestones

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 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 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. 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, 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:

PQ Migration comparison across Google, Cloudflare, Ethereum, Bitcoin

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 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 needs reviewers. The OP_STARK_VERIFY transaction-binding bug needs a fix. Avihu Levy’s QSB pipeline 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 for empirical threat progression. The Trezor Safe 7 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

Sources: 95+ research documents including Quantum Safe Bitcoin (QSB) (Avihu Levy, April 2026), Binohash (Robin Linus, February 2026; Delving Bitcoin thread; Bitcoin Optech #396), ColliderScript (Heilman, Kolobov, Levy, Poelstra, 2024), Heilman Lamport Signatures (2024), Ruffing Taproot PQ commitment (IACR 2025/1307), Dallaire-Demers ECDLP Challenges (arXiv 2508.14011), Sattath & Wyborski lifted signatures (ePrint 2023/362), Gidney 2025 resource estimates, Luo et al. 2026 ECDLP resource estimates, ePrint 2026/380 Lattice HD Wallets, BIP 86/341 specifications, Westerbaan factoring benchmark critique, Gidney (Strilanc) HN comment on factoring-as-benchmark, roasbeef zk-STARK BIP-32 proof-of-concept (bip32-pq-zkp, April 2026), roasbeef PQ Bitcoin work tracker gist, Buchner PQC Precommitment draft BIP (April 2026), 15+ Delving Bitcoin threads, 20+ Bitcoin Optech newsletters (#307-#399), SHRINCS/SHRIMPS Liquid deployment data, BIP-360 testnet reports, nullc HN commentary, and the complete source list from Part 1 and Part 2.

Enjoyed this? Discuss it where it was born.

Read the X thread