Bitcoin Post-Quantum Migration May Take Several Years

Bitcoin’s quantum challenge: migration, not immediate collapse

Bitcoin’s post-quantum migration debate has shifted from pure cryptography to practical wallet safety and the safe handling of long-dormant coins. Ledger CTO Charles Guillemet, in a technical review published by Ledger, emphasized that the network faces a migration problem rather than an imminent quantum emergency. His analysis highlights that selecting a post-quantum signature scheme may be technically simpler than securely moving billions in BTC and coordinating software, hardware, and user behavior across the ecosystem.

Key takeaways

• Ledger CTO Charles Guillemet: Bitcoin faces a migration challenge, not an immediate quantum crisis.
• SHRINCS is a hybrid post-quantum design combining stateful signatures with a stateless fallback and relies on SHA-256 for current security assumptions.
• SHRINCS signatures in the draft range from 548 bytes to 5,777 bytes depending on the signing path, increasing transaction size relative to Schnorr.
• Reusing a stateful signing slot can enable forged signatures, posing serious wallet-level theft risks.
• BIP 360 and BIP 361 remain Drafts, leaving policy and migration mechanics unresolved across the Bitcoin network.

Why the urgency—and why panic is premature

Guillemet’s conclusion is simple but important for the Bitcoin community: there is no known cryptographically relevant quantum computer today that can break Bitcoin’s ECDSA or Schnorr keys using Shor’s algorithm. The threat is real in principle—Shor’s algorithm would allow a sufficiently powerful quantum machine to recover private keys from exposed public keys—but the timeline for such hardware remains uncertain.

This perspective mirrors other sober positions in academia and industry. Stanford cryptographer Dan Boneh has cautioned that Bitcoin should prepare for quantum risk while avoiding a rushed, poorly tested migration that could introduce catastrophic software bugs. Coinbase’s independent cryptography advisory board has likewise recommended planning well before an attacker with quantum capability appears, but left the hard questions about legacy and abandoned coins to the broader Bitcoin governance process.

SHRINCS: a Bitcoin-specific post-quantum proposal

SHRINCS is one of the more prominent draft designs tailored to Bitcoin. The specification is a hybrid: it combines a compact, stateful signing path with a much larger stateless fallback. It builds on SHA-256, the hash function already central to Bitcoin’s security model, and targets roughly 128 bits of classical security and around 64 bits of quantum security under its chosen parameters.

The current SHRINCS draft commits to a 48-byte public key that encodes two signing routes. The compact stateful path, using Flexible XMSS and WOTS+C, produces signatures that vary from 548 bytes up to 4,619 bytes depending on which one-time signing path is taken. The stateless fallback—conceptually related to SLH-DSA/SPHINCS+ ideas—yields a 5,777-byte signature in the draft’s configuration.

It’s important to note that previous public figures for SHRINCS included a much smaller 324-byte stateful signature. Guillemet and the authors of the draft explain that the design evolved: the draft available in September now starts at 548 bytes for the stateful route and the larger numbers reflect different security parameters and design trade-offs.

Why size matters for Bitcoin

Bitcoin’s current Schnorr signatures are 64 bytes; moving to signatures that are dozens or even thousands of bytes long will materially affect block space and fees. Blockstream Research has pointed out that hash-based signatures like those in SHRINCS are built on conservative assumptions and have relatively efficient verification (dominated by SHA-256 operations), but they are unavoidably larger than elliptic-curve signatures. Larger signatures increase transaction weight, reduce throughput, and raise economic costs for users.

Statefulness introduces new wallet failure modes

A central trade-off with SHRINCS’ compact route is that it is stateful. The scheme requires each one-time signing key to be used exactly once. Wallet software and hardware must maintain a counter or other persistent state to ensure the next unused one-time key is consumed before a signature leaves the device.

If a wallet reuses the same stateful signing slot for two different messages, an attacker observing the two signatures may be able to forge valid signatures for that key. Guillemet stresses that an attacker may not recover the entire seed, but sufficient information could leak to make funds spendable by adversaries. This opens a new class of wallet-specific attack that didn’t exist with stateless Schnorr or ECDSA signatures.

Backups, device cloning, and multi-device setups

Backups and multi-device workflows complicate the stateful approach. Restoring a wallet from an older backup could revert the state counter and enable reuse of one-time keys. Two devices initialized from the same seed and operating independently could each consume stateful slots without synchronizing, again risking key reuse.

Independent reviews—such as Project Eleven’s analysis by Alex Pruden and Conor Deegan—arrive at similar concerns: transferring a security-critical state requirement into end-user wallets and custodial systems increases risk when backups or state rollbacks occur.

SHRINCS attempts to mitigate this by offering a stateless fallback path: if a wallet’s state becomes uncertain, the original seed can derive a stateless signing key to spend coins using the larger 5,777-byte signature. However, the wallet must then permanently abandon the compact route for that key, since the state can no longer be trusted. This design reduces the chance that lost state makes funds irrecoverable, but it does shift costs and complexity onto wallet UX and upgrade processes.

Compatibility losses: features users rely on today

Moving from elliptic-curve signatures to hash-based schemes would alter some of the conveniences Bitcoin users expect. Non-hardened BIP32 derivation currently lets an extended public key generate child public keys without revealing private keys—this underpins watch-only wallets and many custodial setups. A straightforward equivalent for hash-based signatures does not naturally exist.

Threshold signing is another area where parity is not guaranteed. Schnorr’s algebraic properties make compact, efficient threshold and multi-signature schemes possible. Known hash-based alternatives typically require larger signatures, greater storage and communication overhead, or different trust and coordination models. Guillemet cautions that SHRINCS should not be assumed to be a drop-in replacement for existing Schnorr-based threshold systems.

Hardware constraints and performance

Ledger’s tests and analysis indicate that some post-quantum operations—particularly key generation and the stateless SHRINCS path—can take minutes on secure hardware. The heavy use of SHA-256 and higher memory demands can strain constrained secure elements used in hardware wallets. That said, Blockstream’s research frames the trade differently: verification is SHA-256-heavy but computationally manageable, and the worst-case verification cost per signature byte in the current draft is claimed to be below that of BIP340 Schnorr.

In practice, the hardware performance trade-offs will affect bootstrapping, backup flows, and the user experience for signing transactions—areas where rigorous testing and optimization are essential.

Protocol-level migration proposals: BIP 360 and BIP 361

SHRINCS is only one piece of the broader migration conversation. BIP 360 (Pay-to-Merkle-Root) is a Draft proposal that aims to reduce Taproot’s quantum exposure by replacing the key-path spend with a Merkle-root-based approach. BIP 360 itself does not specify a post-quantum signature algorithm; rather, it reduces long-term exposure and creates a substrate where future post-quantum signing mechanisms could be layered.

BIP 361 tackles migration policy more directly. It proposes a phased approach to sunsetting legacy ECDSA and Schnorr spending mechanisms after a post-quantum-capable output type becomes available. The draft envisions an initial migration window followed by progressively stricter restrictions on legacy signatures.

A critical unresolved question for both drafts—and for the community at large—is what to do with coins that never migrate. These include funds controlled by lost keys, abandoned wallets, and other coins that remain on outputs whose owners cannot or will not participate in a coordinated upgrade. Different policy choices will have material effects on how the network treats dormant balances and on incentives for custodians and exchanges to migrate funds proactively.

Coordination, social consensus, and the slow grind of migration

One of Guillemet’s central points is that migration is as much a social and operational problem as it is a cryptographic one. Even if the community agreed on a single, well-vetted post-quantum signature algorithm tomorrow, the practical steps—updating full-node software, wallet backends, hardware wallets, exchanges, custodians, and millions of users—would take years and careful staging.

Any migration will need robust test vectors, open-source implementations, hardware firmware updates, UX design for backup and recovery, and an agreed-on policy for legacy coins. Mistakes in any of these areas could create widespread theft risks, denial-of-service vectors, or long-term loss of funds. The community’s cautious approach—testing widely, debating BIPs publicly, and avoiding rushed protocol changes—reflects the high stakes.

Next steps for developers and users

Developers should continue to audit post-quantum proposals like SHRINCS, complete formal security proofs, and benchmark performance on realistic hardware. Wallet and hardware-vendor teams must design robust state management, backup flows, and recovery paths that avoid one-time-key reuse. Exchanges and custodians should plan coordinated migration strategies, including options for hierarchical migration of custodial reserves and customer funds.

For users, the pragmatic advice is to stay informed and follow best practices for key hygiene: maintain secure, tested backups; avoid exposing public keys unnecessarily; and pay attention to official guidance from wallet vendors and exchanges.

Conclusion: prepare deliberately, test exhaustively

Bitcoin’s transition to post-quantum resilience is likely to be a multi-year, multi-stage process. The cryptographic community, wallet developers, hardware manufacturers, miners, and node operators must all align on standards, UX, and policy choices. SHRINCS is an important contribution to the discussion because it exposes real trade-offs—between signature size, verification cost, and operational statefulness—rather than proposing a silver-bullet fix.

As Guillemet summarized: Bitcoin does not have a quantum computer problem today; it has a migration problem. Thoughtful preparation, thorough peer review, and careful rollout will be essential to avoid introducing new systemic risks while hardening the network against future quantum threats.

Technical notes and references:

• SHRINCS draft specification (unnumbered, prototype cryptography)
• BIP 360: Pay-to-Merkle-Root (Draft)
• BIP 361: Post-Quantum Migration (Draft)
• NIST FIPS 205: SLH-DSA standardization (August 2024)
• Blockstream Research: SHRINCS verification experiments and Liquid sidechain tests
• Project Eleven review: statefulness and backup risk analysis

The Bitcoin BIP repository listed BIP 360 and BIP 361 as Draft as of Sept. 17, 2026. SHRINCS remains an unnumbered draft and its authors emphasize that the design requires further peer review and a completed formal security proof before any mainnet consideration.