Podcast Summary: TFTC #700 — Preparing Bitcoin for the Quantum Era with Jonas Nick & Mikhail Kudinov
Date: December 31, 2025
Host: Marty Bent
Guests: Jonas Nick & Mikhail Kudinov
Overview
This episode examines Bitcoin’s vulnerability to future quantum computers and explores hash-based signature schemes as a potential quantum-resistant solution. Marty Bent is joined by cryptographers Jonas Nick and Mikhail Kudinov, whose recent research focuses on adapting hash-based cryptographic signatures for Bitcoin. The conversation covers the basics of hash-based cryptography, its relevance to Bitcoin, the trade-offs of migration, implications for wallets and the user experience, and broader reflections on timelines and preparedness for quantum threats.
Main Discussion Points
1. Why Quantum-Resistant Signatures Matter for Bitcoin
- Bitcoin’s Current Vulnerability: Today’s Bitcoin signatures (ECDSA/Schnorr) are based on elliptic curve cryptography, which will be broken by sufficiently advanced quantum computers.
- Hash-Based Signatures: These use only cryptographic hash functions for security, making them much more resistant to quantum attacks.
- “The security of the signature scheme is based on the security of the hash function.” — Jonas (03:19)
2. Introduction to Hash-Based Signature Schemes
- Rationale: Bitcoin already relies on SHA-256 for mining and Merkle roots, making hash-based schemes a logical extension.
- “If SHA-256 is broken, arguably we have even bigger problems than just transaction authorization not working.” — Jonas (04:23)
- Conservatism: Relies on fewer, more robust assumptions compared to lattice-based alternatives.
3. Quantum Computing Threats: Myth, Timeline, and Reality
- What Quantum Computers Threaten
- They can break elliptic curve cryptography, making today’s signatures insecure.
- Hash-based functions are much harder for quantum computers to break.
- Post-Quantum Cryptography Defined: Cryptographic schemes secure even in quantum presence. But finding the right set of trade-offs is challenging.
- No Imminent Panic, But Preparation Vital:
- “10 years in Bitcoin is not such a long time if we need to prepare for an upgrade like that…” — Jonas (45:41)
- “I wouldn't lose my sleep over it for sure as well. But… the more time they have [to migrate], the better.” — Jonas (45:41)
- Quantum Progress Hard to Predict:
- “If I had told anyone… we would have ChatGPT-3 by 2022, they would have ridiculed me.” — Jonas (66:05)
4. Hash-Based Signature Schemes in Practice
- SPHINCS+ as Baseline: Standardized by NIST, but developed for use cases like software signing, not blockchains.
- The researchers explored modifying SPHINCS+ and other schemes to better fit Bitcoin’s unique needs. (10:22)
- Signature Size Trade-Off:
- Standard SPHINCS+ signatures are large (~7,800 bytes), but researchers found ways to shrink them to 3,400-4,000 bytes — still much larger than current ECDSA.
- Why Size Matters: Larger signatures mean fewer transactions per block unless the block size limit is raised. (12:13)
- Reducing Supported Signatures:
- SPHINCS+ supports up to 2^64 signatures per key (huge overkill for Bitcoin’s use). Lowering this lets you shrink signature size.
- “In Bitcoin … we usually only want to use [an address] once; we don't want address reuse ...” — Jonas (17:16)
5. Trade-Offs & Downsides of Hash-Based Approaches
- Signature Size & Block Space: Larger signatures reduce the number of possible transactions per block.
- Limited Key Reuse: Each public key can support only a fixed (limited) number of signatures.
- Exceeding this degrades security: "…if you have that limit… you should not exceed it. You must not exceed it.” — Jonas (18:16)
- Performance Optimization Ideas:
- Advanced techniques (“Watts+, C4S+, FP+”) can make signatures smaller and the system more efficient, but often require more computation at signing time.
- “By doing extra work on the signer part, we reduce the size and we reduce verification time.” — Mikhail (22:51)
- Advanced techniques (“Watts+, C4S+, FP+”) can make signatures smaller and the system more efficient, but often require more computation at signing time.
- User Experience Impacts:
- Increased signing time affects wallets, especially DLCs or hardware wallets that might need to pre-sign many transactions.
- “It might take much longer to sign [transactions] than it takes currently.” — Jonas (25:10)
- Downsides of Hash-Based Schemes:
- No support for many existing Bitcoin features:
- Hierarchical deterministic (HD) wallets
- Flexible multi-signature and aggregate signature schemes
- Taproot’s privacy improvements
- “We cannot use any of the tricks that we've developed over the past years in Bitcoin. And that includes HD wallets. It includes multi-signatures, threshold signatures…” — Jonas (31:27)
- Hardware Wallet Experience: XPUBS can’t be used as today; would require exporting a long list of public keys instead.
- No support for many existing Bitcoin features:
6. Stateful vs. Stateless Signature Schemes
- Stateless: Like ECDSA, where the private key does not change with each use.
- Stateful (Hash-Based): Private key must be updated every time it’s used; mismanaging this state can compromise security.
- “Statefulness is pretty fragile and it's one of those things that won't work for every signer.” — Jonas (30:04)
- Restoring from an old backup can leak keys and allow theft if not managed perfectly.
7. Migration and Upgrade Paths
- Incremental Approaches Possible:
- Adding a new opcode for hash-based signatures (e.g., in Taproot script paths) lets wallets add post-quantum spends now without requiring an immediate network-wide switch.
- “What people could do today already… generate a post quantum public key, a hash-based public key, and then add this public key along with this new opcode in a Taproot Merkle tree…” — Jonas (56:08)
- Emergency Response vs. Long-Term Standardization:
- Hash-based signatures are more emergency tools, whereas lattice-based or new schemes could support richer features but need more vetting.
- Parameter optimization, real-world benchmarking, and more research are the next steps.
8. Open Questions & Community Engagement
- Balancing Risks:
- Moving too quickly introduces protocol complexity and maintenance overhead.
- Moving too slowly risks unpreparedness.
- “There's a lot of value in the Bitcoin protocol being as simple as possible… Whenever we add something… there is a risk.” — Jonas (63:23)
- Privacy Implications:
- Multiple parallel signature schemes may degrade privacy, undermining standardization efforts like Taproot. (43:59)
- Responsibility to Prepare:
- “If you don't prepare and then suddenly you find out you were wrong…” — Mikhail (67:41)
- Need for Ongoing Discussion:
- Encouragement for wallet developers and others to engage with the research, test schemes, and suggest improvements.
- "Let’s have it with a good pace; not rushing, but also not putting it away and saying like, 'this will never happen.'" — Mikhail (71:05)
Notable Quotes & Memorable Moments
-
On Bitcoin’s existential security:
“If SHA-256 is broken then arguably we have even bigger problems than just transaction authorization not working… we don't have consensus on the blockchain anymore.” — Jonas (04:23) -
Determining Signature Size Needs for Bitcoin:
“If we set this bar lower and… have a limit on less number of signing operations, we can significantly decrease the signature size.” — Mikhail (13:27) -
On preparing for the unknown:
“I'm skeptical of people saying... there's no clear path towards a cryptographically relevant quantum computer ... there could be one anytime.” — Jonas (66:05) -
The protocol upgrade dilemma:
“What could be just as dangerous as moving too fast... there's this sort of trade off between urgency and complacency.” — Marty (62:14) -
On the risks of failing to migrate:
"What happens with the coins that don't migrate... this will be extremely painful. But that's not something that cryptography can solve, unfortunately." — Jonas (50:28)
Key Timestamps
- [01:43] — What are hash-based signatures and why consider them for Bitcoin?
- [05:51] — The real threat quantum computers pose to Bitcoin
- [09:53] — The rationale for SPHINCS+ and Bitcoin-specific adaptations
- [12:13] — Signature size trade-offs and block space implications
- [17:16] — Technical limitations of hash-based signatures on address reuse and key limits
- [22:51] — Technical optimizations and their impacts
- [25:08] — Wallet implications: increased signing times
- [28:00] — Why statefulness matters and its risks for backup & wallet management
- [31:27] — Limitations on current Bitcoin features (HD, multisig, Taproot) with hash-based signatures
- [45:41] — Timeframes for a quantum threat and urgency to act
- [56:08] — Upgrade path: adding hash-based signature script paths via Taproot
- [63:23] — Dangers of moving too fast vs. too slow on protocol upgrades
- [66:05] — Personal anecdote on technological surprises (e.g., AI as a parallel to quantum advances)
- [71:05] — Guests’ closing calls for measured, collaborative discussion
Conclusion & Calls to Action
- Further Research: Jonas and Mikhail will next explore lattice-based schemes.
- Community Feedback Needed: Implementation experiments, wallet developer input, and parameter optimization are crucial.
- No Urgent Rush, But No Complacency: Balanced preparation, discussion, and incremental steps will help Bitcoin meet the coming quantum era without sacrificing usability or security.
- Invitation to Engage: Both guests stress the importance of open, meritocratic community participation in these decisions.
Final Note:
If you want to understand the technical underpinnings of how Bitcoin plans to remain secure in a quantum future, this episode provides both a blueprint of current research and honest reflection on the complex trade-offs being weighed. The conversation is accessible yet deeply technical, for anyone interested in Bitcoin’s long-term resilience.
