Bitcoin Devs Have Been Building Quantum Defenses for Years. Here's What They've Got.
Let's start with what's real. Google Quantum AI published a paper showing theoretical progress toward breaking ECDSA, the digital signature scheme Bitcoin uses. They claim a reduction in qubit requirements from roughly 20 million to 1,200. That is genuine progress on the theoretical side, and pointing it out is not FUD. What is irresponsible is claiming that elliptic curve cryptography will be broken in X years, because nobody can honestly predict the rate of breakthroughs required to get from theoretical math to a functioning quantum computer with the persistent uptime necessary to wage these attacks. The chasm between a paper and a machine is enormous.
Now, here's what the critics aren't telling you: Jonas Nick and Mikhail Kudinov at Blockstream Research have been publishing open, peer-reviewed work on post-quantum signature schemes specifically optimized for Bitcoin. Their research stack is now three layers deep. First, in December 2025, they published a comprehensive paper showing that by applying recent optimizations to SPHINCS+ (a NIST-standardized hash-based signature scheme), signature sizes for Bitcoin can be reduced from nearly 8 KB to approximately 3 to 4 KB, comparable to lattice-based alternatives. Then Nick proposed SHRINCS, a hybrid scheme that achieves 324-byte quantum-proof signatures on a primary device, with a stateless fallback for backups. That's only about 5x larger than today's Schnorr signatures.
Five days ago, Nick published the next evolution: SHRIMPS, which solves the multi-device problem. With SHRINCS, restoring a backup or using a second hardware wallet meant falling back to large stateless signatures. SHRIMPS fixes this by combining two SPHINCS+ instances under a single public key: a compact path for normal use (2,564 bytes at 128-bit security) and a fallback for edge cases. That's three times smaller than the NIST standard. Combined with SHRINCS, a primary device still gets 324-byte signatures while any backup device produces signatures under 3 KB. The security relies only on hash functions, the same mathematical foundation Bitcoin already trusts through SHA-256.
Separately, Nick and Kudinov are also exploring lattice-based cryptography as a potential alternative path, evaluating ML-DSA (formerly CRYSTALS-Dilithium), which NIST selected as its primary post-quantum recommendation. Lattice-based schemes offer advantages in verification speed and signature aggregation, but they carry a tradeoff: they rely on newer mathematical assumptions that haven't been battle-tested as long as hash functions. In fact, NIST tested 69 post-quantum candidate algorithms during its standardization process, and two of them, Rainbow and SIKE, were broken with classical computers during testing. The fact that Blockstream Research is exploring multiple approaches simultaneously, hash-based and lattice-based, publishing everything openly, and inviting cryptanalysis is exactly what responsible preparation looks like.
Meanwhile, Hunter Beast and Ethan Heilman are leading BIP-360, which creates the P2QRH (Pay to Quantum Resistant Hash) address format. This removes Taproot's quantum-vulnerable key-spend path and lays the groundwork for future post-quantum signature opcodes. Nick is presenting OP_SHRINCSVERIFY, the actual Bitcoin opcode proposal for verifying these signatures on-chain, at OPNEXT on April 16 in New York.
Here's the part that matters most: the people demanding that "Bitcoin developers" move faster are being disingenuous in several ways. First, the Bitcoin Improvement Proposal process is open to anyone. If critics have a viable post-quantum solution, nothing stops them from submitting it. That is literally how Bitcoin works. Second, not every Bitcoin protocol developer is a hardcore cryptographer versed in quantum-resistant signature schemes. The protocol has many layers, from P2P networking to mempool policy to wallet standards, and post-quantum cryptography requires deep specialization. The relatively small group of cryptographers who are equipped to push this forward, people like Jonas Nick, Mikhail Kudinov, Ethan Heilman, and Hunter Beast, are doing exactly that. Wagging your finger at the entire Bitcoin developer community and telling them to "do something" is unproductive and overlooks these realities.
There's also a circular logic at play that deserves to be called out. Some critics claim Bitcoin Core is a "cabal" of five or six developers who would never accept a quantum-resistant proposal. So the argument becomes: Bitcoin developers need to do something, but when developers say "we're working on it, and if you have a better solution, propose it through the BIP process," the response is "we won't propose anything because the cabal will just shoot it down." Call it Schrödinger's BIP: it must exist, but the people most worried about quantum won't bring it forth because they've already decided it will be rejected. How do you know that unless you actually try? This gives critics rhetorical leverage to fear monger on all sides without ever putting skin in the game. It is bike-shedding and hand-waving, nothing more. The BIP process is open. The mailing list is public. If you have a solution, submit it.
Finally, and this is critical: there is a real danger in rushing this. Post-quantum cryptography could itself be a Trojan horse. New digital signature schemes could contain backdoors, whether intentional or as yet undiscovered vulnerabilities. This is not an accusation against anyone working on these proposals, but it is a statement of fact about the risks. NIST's own testing process proved that "quantum-resistant" does not mean "proven secure." A rush to change Bitcoin's signature scheme haphazardly could introduce more damage than the quantum threat itself. Bitcoin development should be cautious, methodical, and adversarial in its review process, because there remains a real possibility that quantum computers capable of breaking ECDSA are years out, or may never arrive at all. You do not want to create a real problem in an attempt to solve a hypothetical one.
As we covered yesterday, the theoretical threat is advancing. But so is the defense. The work is happening in public, it is being done by the right people, and the deliberate pace is a feature, not a bug.
|