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)
• 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.

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.