A hardware wallet restored from a backup ought to help its owner recover safely. In one experimental approach to Bitcoin’s quantum defenses, that familiar action can also create a new security problem if the wallet resumes signing with outdated state.

That detail deserves attention because it makes the migration challenge tangible. Replacing Bitcoin’s signatures involves decisions about backup recovery, multiple devices and how a wallet remembers work that never appeared on the blockchain.

Ledger CTO Charles Guillemet examined those issues in a September 16 technical article about SHRINCS, a draft hash-based signature proposal. His assessment separates the present state of quantum hardware from the years of engineering and coordination required to change Bitcoin safely.

No publicly demonstrated quantum computer can currently derive a Bitcoin private key from its full-size elliptic-curve public key. There is no verified date when that changes.

The time pressure comes from a different, observable fact. Research, protocol review, wallet development and the movement of existing funds cannot all be completed on the day a capable attacker appears. Every year spent postponing preparation leaves less room under any fixed future threat scenario.

I read the current SHRINCS specification alongside BIP 360, BIP 361 and Ledger’s analysis. The documents contain useful progress and unresolved work. None establishes that Bitcoin has activated a complete post-quantum migration, and none justifies treating every laboratory quantum milestone as an imminent theft capability.

Bitcoin transactions use digital signatures to demonstrate authorization. Much of that authorization relies on elliptic-curve cryptography, including ECDSA and Schnorr signatures on secp256k1.

A sufficiently capable quantum computer running Shor’s algorithm could solve the relevant discrete-logarithm problem and recover a private key from its public key. That would let an attacker produce signatures that satisfy existing rules for vulnerable coins.

The distinction between signatures and encryption matters. Bitcoin’s transaction history is public. The core theft scenario concerns forging authorization, rather than decrypting a secret copy of the ledger.

Hashing presents a different set of questions. Bitcoin uses hashes for functions including commitments and proof of work. Quantum search algorithms can offer theoretical advantages for certain hash-search problems, but they are not the same attack as recovering an elliptic-curve signing key.

A claim that a quantum processor has improved at one task therefore needs a careful translation. Does it demonstrate the necessary algorithm? At what scale? With what error rate and runtime? Does the comparison involve physical qubits or error-corrected logical qubits?

Physical qubits are hardware resources. A useful logical qubit is maintained through error correction and substantial supporting operations. Their relationship depends on the architecture and error rates. Quoting a raw qubit count without those conditions does not establish a machine’s ability to attack Bitcoin.

The engineering still matters enormously. It should be discussed in the units that the cryptographic attack actually requires.

Bitcoin outputs do not all reveal the same information.

The current BIP 360 draft distinguishes long-exposure attacks from short-exposure attacks. In a long-exposure case, an attacker can work on public information already available for an extended period. A short-exposure attack must complete after a spending transaction reveals the relevant public key and before that transaction is confirmed.

Old pay-to-public-key outputs expose a public key directly. Taproot outputs also include a public key. These are important examples when discussing the long-exposure threat.

Other output types can initially hide a public key behind a hash or script commitment. That protection has conditions. Spending can reveal the key, and reusing the same key for remaining funds can leave those funds exposed. Extended public keys and wallet descriptors can also disclose relevant information outside the chain.

This is why address appearance alone is an incomplete risk assessment. A wallet can have revealed information through past transactions or through a service that received its public data.

Keeping a signing device offline still helps protect its private keys against many conventional threats. It does not conceal an already public key from an attacker who might someday be able to derive the corresponding private key mathematically.

Hardware security and future signature security address different parts of the problem. Both remain relevant.

BIP 360 currently proposes Pay-to-Merkle-Root, or P2MR. The design retains script-tree functionality while removing Taproot’s key-path spending route.

That change is intended to reduce the long-exposure attack surface associated with the output’s exposed key. It creates a possible foundation for later work using script paths.

The proposal explicitly says that protection against short-exposure attacks may require post-quantum signatures. P2MR is therefore not, by itself, a replacement signature algorithm.

Its status also matters. The canonical BIP repository lists it as Draft. A published BIP number gives a proposal a place for technical discussion; it does not mean the network has agreed to or activated the change.

For a reader deciding what to do with funds, this distinction is essential. The appearance of an address format in a draft does not make it a supported destination for ordinary payments. A proposed mechanism must pass through review, implementation and adoption before people can rely on its intended security properties.

BIP 360 is evidence that developers are specifying concrete options. It should be evaluated on what the draft actually claims to solve.

A new signature type would give people a destination. It would not automatically move funds already controlled by older rules.

BIP 361 is a separate Draft proposal concerning migration and a sunset of legacy signatures. It depends on a future post-quantum output mechanism. Its proposed schedule includes a first phase roughly 160,000 blocks after activation, followed by a later phase approximately two years afterward.

That is a conditional proposal. No clock began merely because the document was published in 2026.

The underlying policy problem is difficult. Some owners can promptly upgrade their wallets and move funds. Others may be unavailable, unaware or dependent on slow institutional approval. Some coins may have genuinely lost keys, although outsiders cannot reliably infer that from inactivity alone.

Leaving every vulnerable output spendable under old rules creates a future theft opportunity if quantum key recovery becomes practical. Restricting old spending rules can affect legitimate owners who have not migrated. A recovery procedure has to distinguish those owners from an attacker who has learned a signing key.

The draft discusses rescue mechanisms that might use information an authentic holder knows and a quantum attacker does not. Their coverage and implementation remain research questions. They should not be described as guaranteed recovery for all old coins.

These choices touch ownership expectations and the legitimacy of consensus changes. Software can enforce a rule after agreement. It cannot manufacture the agreement that the rule deserves to be enforced.

SHRINCS explores hash-based signatures built around SHA-256, a hash function already deeply used in Bitcoin. Its design combines a compact stateful component with a larger stateless fallback.

“Stateful” means the signer must reliably remember which one-time signing slots have been consumed. Each slot must be used only once for the relevant signing operation.

In the September specification discussed by Ledger, the public key is 48 bytes. Stateful signatures range from 548 to 4,619 bytes, and the stateless signature is 5,777 bytes. Bitcoin’s standard Schnorr signature is much smaller at 64 bytes, excluding the optional sighash byte.

Older coverage used a 324-byte figure for an earlier SHRINCS version. Ledger explicitly warns that this is no longer the current draft’s minimum. That is a good example of how quickly precise technical numbers become stale during research.

Even the updated size comparison is only part of the evaluation. A proposal must be assessed for security assumptions, implementation difficulty, verification costs and behavior when a user makes an ordinary operational mistake.

The current SHRINCS draft has no assigned BIP number and explicitly says its security proof remains to be completed. Its use of ideas related to standardized hash-based signatures does not make the entire custom construction a finalized NIST standard.

It is serious research with work still to do.

A stateful signer maintains a counter identifying the next unused slot. Ledger’s analysis says that counter must advance persistently before a signature is released.

Suppose a device creates a signature, then a user restores an older backup that predates the counter update. If the device signs another message using the same slot, the two signatures may reveal enough information to enable forgery.

The attacker need not recover the entire seed for that to threaten funds. The ability to forge the required signature is already a serious failure.

Watching the blockchain does not fully solve the problem. A signature can leave a device without its transaction ever being confirmed. It might be shared with another participant, included in an abandoned transaction or used in an offchain interaction. The slot has still been consumed.

Multiple devices create a related risk. Two devices restored from the same seed cannot independently assume that the next compact signing slot is unused. They need a safe coordination mechanism, or a different signing path.

SHRINCS addresses uncertain state with its stateless fallback. The seed can derive that path without trusting the old counter. Ledger’s description says the signer must permanently stop using the compact path for that key once state becomes uncertain.

That preserves a recovery route at the cost of a larger signature. The protection depends on wallet implementations recognizing uncertainty and using the fallback correctly.

This is the practical meaning of a migration that takes years. Engineers must make a cryptographic design behave safely through restoration, interrupted writes and everyday device use. A specification that works under ideal conditions is only the start.

Signature bytes consume network resources. Larger transactions require bandwidth, propagation and storage, and can affect how many transactions fit within a block’s resource limits.

Ledger’s analysis notes that SHRINCS verification is dominated by SHA-256 operations. Relatively cheap verification can make a large signature less demanding computationally than its byte count might suggest.

The bytes still have to travel and be stored. Changing accounting rules to accommodate a scheme would require evaluating those other costs, including initial synchronization and the practicality of operating a node.

Signing hardware has different constraints from a server verifying transactions. Secure devices have limited memory and may lack the relevant acceleration. Ledger says key generation and the stateless path can take minutes on some current secure hardware. That is an implementation observation, not a universal benchmark for every future device.

Existing wallet features also require attention. Familiar public-child-key derivation and compact threshold-signing techniques depend on mathematical properties of current systems. Hash-based replacements do not automatically preserve them with the same efficiency.

A custodian supporting many accounts cannot evaluate the change by comparing one signature on a laptop. It has to examine device policy, authorization, backups, monitoring and recovery at its own operating scale.

NIST finalized three major post-quantum standards in August 2024. ML-KEM addresses key encapsulation. ML-DSA and SLH-DSA address digital signatures.

That distinction prevents a common mistake. A tool suitable for establishing a shared secret is not automatically a replacement for transaction authorization.

The standards provide reviewed cryptographic building blocks for broader systems. Deploying one inside Bitcoin would still require compatible consensus rules and an ecosystem capable of producing, validating and recovering the relevant transactions.

The broader financial sector faces comparable coordination work. In a September 11 speech, RBI Deputy Governor Shirish Chandra Murmu described quantum risk as a preparation challenge because payment infrastructure has long technology cycles. He also discussed the bank’s Quantum Secure and Adaptive Financial Ecosystem expert committee.

For confidential information, organizations worry about encrypted data collected now and decrypted later. Bitcoin has a distinct exposure involving public signing keys and spendable funds. Both motivate advance planning, but they should not be collapsed into an identical attack story.

Ordinary holders should keep recovery procedures sound and follow supported wallet updates. They should avoid treating experimental address formats or third-party “quantum migration” offers as an approved network upgrade.

Limiting unnecessary key reuse and exposure can reduce particular risks, but it does not substitute for a future protocol-level solution. Changing an address without understanding its script type and prior key exposure can produce false confidence.

Institutions can begin with an inventory. Which outputs do they control? Which keys or descriptors have been disclosed? Which hardware, signing policies and external services would need to change? How long would an authorized migration take under current procedures?

Those are operational questions that can be answered before anyone claims to know the arrival date of a capable quantum computer.

Developers need measured implementations, adversarial review and recovery tests. Policy discussions need honest treatment of legacy holders. Researchers need space to revise a promising scheme when new analysis changes its parameters.

The migration window is getting tighter in the sense that preparation consumes real time while the threat date remains uncertain. There is no scientifically established expiry date for Bitcoin’s current security.

The useful response is sustained preparation with clear milestones. A future defense must survive the cryptographic attack it was designed for and the ordinary recovery mistakes that users already make.

No publicly demonstrated machine can perform the required attack against Bitcoin’s full-size elliptic-curve keys. A sufficiently capable future machine could threaten exposed keys. Its arrival date is unknown.

An offline signer protects private keys against many conventional attacks. It does not remove the mathematical exposure of a public key already available to a sufficiently capable future quantum attacker.

The canonical document remains Draft as reviewed on September 18, 2026. It proposes P2MR to address long-exposure risk and does not itself introduce a post-quantum signature algorithm.

No network-wide countdown follows from BIP 361’s publication. Its phased schedule is part of a draft that depends on additional mechanisms and future activation.

It is experimental specification work. The current document has no assigned BIP number and an unfinished security proof. The wallet-state and recovery requirements also need careful implementation and review.

A migration requires more than choosing an algorithm. Consensus review, software deployment, signing hardware, custody procedures, user recovery and the transfer of existing funds must work together. Handling unmigrated coins also raises unresolved policy questions.

Ledger’s September 16, 2026 SHRINCS analysis, by Charles Guillemet, including current signature sizes, wallet-state requirements and recovery costs.

Current SHRINCS draft specification, including its experimental status and incomplete security proof.

BIP 360 in the canonical Bitcoin BIP repository, on P2MR and long- versus short-exposure attacks.

BIP 361 in the canonical Bitcoin BIP repository, on proposed migration phases and legacy-signature restrictions. Its motivating forecasts are the authors’ arguments, not an established quantum-computer deadline.

NIST’s finalized post-quantum standards announcement, August 13, 2024, distinguishing key encapsulation and signature standards.

RBI deputy governor’s September 11, 2026 speech, paragraphs 27 through 30 on quantum readiness and migration in payment infrastructure.