Shrincs: A Bitcoin Post-Quantum Migration Proposal

Before You Dive In:

• SHRINCS is the first serious Bitcoin-specific post-quantum signature proposal. It pairs a compact, stateful signing path with a stateless fallback, so losing your device’s state costs you efficiency, not funds.
• Its signatures run 548 to 5,777 bytes against Schnorr’s 64, and safely tracking which one-time keys a wallet has already used turns wallet software into part of the security model, not just an interface to it.
• Picking the cryptography may be the easy part. Migrating existing coins and building wallets that never silently reuse a signing slot is the harder, unsolved problem.

The quantum threat to Bitcoin is not immediate, but planning for it is no longer optional.

Bitcoin’s ownership model ultimately relies on digital signatures. A cryptographically relevant quantum computer would break ECDSA and Schnorr signatures. Nobody has such a machine today, and nobody knows exactly when one will exist. But migrating Bitcoin takes years of research, implementation, deployment, and user adoption. Waiting for the threat to become concrete would be irresponsible.

I recently had the opportunity to discuss this migration with Jonas Nick, the anonymous developer conduition, and Dan Boneh. I am glad to see Bitcoin researchers, developers, and the broader community taking the problem seriously. This was much less visible one year ago.

I think the migration has three distinct questions:

1. Which post-quantum signature scheme should Bitcoin support?
2. What changes does that scheme impose on the protocol and wallet ecosystem?
3. How do we migrate existing coins, especially those that have never been moved by their owner?

The last two questions have not been ignored, but they remain unresolved. This is unsurprising. Choosing cryptographic parameters is difficult. Deciding what ultimately happens to quantum-vulnerable coins is politically and socially much harder. Reaching social consensus is the main challenge of this migration.

Still, we need to reason about the migration as a whole. A signature scheme cannot be evaluated independently from wallets, hardware devices, backup procedures, and protocols that will eventually use it.

SHRINCS

(One of) the first serious Bitcoin-specific proposals is SHRINCS, short for “Shrunken SPHINCS.”

SHRINCS is a draft BIP proposed by Conduition, Ethan Heilman, Mikhail Kudinov, Oleksandr Kurbatov, Jonas Nick, and remix7531. It is not a Bitcoin Core proposal in any institutional sense. Its specification is still evolving, and the figures below refer to the current draft as of September 2026.

The design starts from a conservative observation: Bitcoin already depends heavily on SHA-256. A hash-based signature scheme can therefore avoid introducing an additional hardness assumption, such as the lattice assumptions used by ML-DSA.

This does not mean that SHRINCS relies on no new cryptography. It combines:

• A compact, stateful component based on Flexible XMSS and WOTS+C.
• A larger, stateless fallback based on the NIST-standardized SLH-DSA algorithms, but using a non-standard parameter set.

The current draft targets NIST security category 1, described by the specification as roughly 128 bits of classical security and 64 bits of quantum security.

This is a conservative choice in terms of cryptographic assumptions, but not in terms of operational complexity, as we develop below.

Why Stateful Signatures?

Post-quantum signatures are much larger than Bitcoin’s current 64-byte Schnorr signatures. Because signatures consume block space, simply replacing Schnorr with a standard post-quantum scheme such as SLH-DSA (whose signatures are at least 7,856 bytes) would substantially reduce transaction throughput.

SHRINCS exploits a property that is common in Bitcoin wallets: a key is generally expected to sign very few times, and ideally only once.

Its compact path uses one-time signatures organized inside a Merkle tree. Each one-time key corresponds to one stateful signing slot. The signer must never use the same slot to sign two different messages.

With the unbalanced tree specified by the current draft, the first signatures are the smallest and subsequent signatures grow as their Merkle authentication paths become longer. A balanced tree can instead provide a larger budget of constant-size signatures, at the cost of more expensive key generation and larger initial signatures.

The verifier does not need to know which tree shape the signer selected. This flexibility is important because a personal wallet, a Lightning node, and a persistent identity do not have the same usage profile.

In the current draft:

• The public key is 48 bytes.
• Stateful signatures range from 548 to 4,619 bytes.
• The stateless signature is 5,777 bytes.

These figures are already a meaningful improvement over standardized SLH-DSA parameter sets, but they remain far larger than Schnorr/ECDSA secp256k1 signatures (64 to 72 bytes).

The often-quoted 324-byte SHRINCS signature refers to an earlier version of the proposal and should no longer be presented as the current figure.

The State Is a Security Boundary

For each SHRINCS key pair, the signer maintains a counter identifying the next unused one-time key.

This counter must never move backwards. It must be incremented in persistent storage before the signature is returned. Concurrent signing must be prevented, and the counter must not be restored from a backup.

If two different messages are signed using the same slot, observers may obtain enough information to forge signatures. They do not necessarily recover the complete private seed, but that distinction does not help the user whose coins can now be stolen.

State reuse can be detected by a wallet before a signature is published, because the signature identifies the one-time leaf it uses. This is useful for defense in depth, but it does not really solve the problem. The checking wallet must know about every previous signature, including signatures that were created but never broadcast.

This last point matters. Blockchain monitoring is insufficient. A signature may have been shared off-chain, used for message authentication, or partially signed TX, or attached to a transaction that was never mined. Once a signature has left the signing device, its slot must be considered consumed.

What Happens When The State Is Lost?

This is where SHRINCS is more robust than a purely stateful signature scheme.

The SHRINCS public key commits to both the stateful and stateless components. If the state is lost, corrupted, or uncertain, the signer must permanently stop using the compact path for that key. But the seed can still derive the stateless key and produce a valid 5,777-byte signature.

State loss therefore does not mean loss of funds. It means loss of efficiency.

This fallback is one of the strongest parts of the design. It preserves static seed recovery while keeping normal signatures relatively compact.

For now, there is no additional unique “wallet ID” in the SHRINCS specification. Recovery still requires the chosen tree structure, just as Bitcoin already requires derivation paths and script policies. That structure can be standardized. What cannot be standardized is the signing state. After a restore, you cannot know that a one-time leaf was never used. A signature may have been created and never broadcast. Scanning the chain is not enough.

The spec’s answer is to refuse the compact path when the state is uncertain, and recover with the large stateless signature. Funds are recoverable. Cheap signing is not.

The remaining failure mode is a wallet that resumes compact signing from “what I saw on chain” and collides with an unpublished signature.

Recovering funds from 24 words plus a small set of standard practices is a must. With SHRINCS, that means: restore, then spend on the expensive path. Compact signing after recovery is not free.

The Wallet Problem

Hash-based signatures are expensive on hardware signers: a lot of RAM, and a lot of hashes. Dedicated accelerators are uncommon. Where they exist, they often target Keccak, not SHA-256, which is what SHRINCS uses. On current secure hardware, keygen and especially the stateless path can take on the order of minutes. The compact stateful path is cheaper, but still far from Schnorr.

Also, managing the state is challenging. The operational difficulty is not the size of one counter. It is safely maintaining counters across an entire wallet.

A user may have hundreds of UTXOs and therefore hundreds of derived key pairs. A hardware wallet supporting several accounts and blockchains may need to track a much larger number.

One possible architecture would commit these counters in a Merkle tree and store only the root in rollback-resistant hardware. The software wallet would provide a proof for the counter being updated, and the hardware device would atomically update the root before releasing the signature.

This is technically possible, but synchronization becomes part of the security model.

Two software wallets cannot independently drive the same hardware state unless they exchange the updated tree. Two devices restored from the same seed cannot both safely use the compact path without coordination. If the state is uncertain, they must use the stateless path.

A separate proposal called SHRIMPS explores multi-device signing, but this is not a property provided by SHRINCS itself.

The broader point is that wallet state is no longer merely application data. It becomes a cryptographic state whose rollback can compromise funds.

Other Features We Lose

Hash-based signatures do not efficiently reproduce every property Bitcoin currently gets from elliptic-curve cryptography.

Non-hardened BIP32 derivation is the clearest example. Today, an extended public key can derive child public keys without access to the private key. This enables watch-only wallets and several useful wallet architectures. Efficient public child derivation does not appear to translate to hash-based signatures.

Threshold signatures are also more difficult. Hash-based multisignature constructions exist, and multiple independent signatures remain possible, but we should not expect a compact drop-in equivalent to Schnorr threshold signing. Known constructions either provide limited gains, introduce substantial storage and communication costs, or require a trusted dealer.

This does not make SHRINCS a bad proposal. It means the cost of the migration cannot be measured only in signature bytes.

Verification Cost & Block Space

SHRINCS signatures are large, but their verification consists mostly of SHA-256 computations. According to the current draft, their worst-case verification cost per signature byte is lower than that of BIP340 Schnorr signatures.

This matters. Bitcoin’s witness discount and resource accounting do not need to price every byte identically if some bytes are cheap to verify. A dedicated witness discount for post-quantum signatures could recover part of the lost transaction capacity without increasing verification work proportionally.

However, computation is not the only constraint. Larger blocks also increase bandwidth, propagation time, storage, and initial synchronization costs. These affect who can run a node and therefore affect decentralization.

Hardware has improved enormously since 2009, but “hardware is 20 to 50 times faster” is not, by itself, a sufficient argument for increasing block capacity. Different resources have improved at different rates, and Bitcoin’s network today processes a very different adversarial workload.

We should quantify the acceptable budgets for verification, bandwidth, storage, and synchronization. Block size should not be a sacred cow, but neither should the resource constraints behind it be dismissed.

Where This Leaves Us

SHRINCS is the first Bitcoin post-quantum proposal I have seen that makes a serious end-to-end trade-off.

It provides compact signatures under conservative hash assumptions, relatively cheap verification and a stateless recovery path. But it also introduces a cryptographic state-management problem into every wallet, produces signatures far larger than Schnorr, weakens existing wallet derivation patterns, and does not preserve today’s threshold-signature capabilities.

The specification itself is still a draft. Its SLH-DSA path uses a non-standard parameter set, its stateful component uses constructions outside the NIST standard, and the current document explicitly says that the security proof is pending. These are not reasons to dismiss the work. These are reasons not to describe it as finished.

SHRINCS optimizes strongly for protocol-level cryptographic security. That is necessary but not sufficient. Bitcoin’s security also depends on whether real wallets can implement the protocol without routinely exposing users to catastrophic state-reuse failures.

If users frequently lose money because the wallet state was rolled back, cloned, or incorrectly synchronized, the fact that Bitcoin’s consensus rules are quantum-resistant will have been for nothing.

The uncomfortable part is that selecting the signature scheme may be the easiest question in the migration.

---

Charles Guillemet, Ledger CTO