A review of SHRINCS

SHRINCS has officially been proposed for Bitcoin. While it's an elegant proposal that satisfies the goal of achieving quantum resistance for Bitcoin without necessarily requiring a blocksize increase, there are real tradeoffs. Most notably, this shifts the primary responsibility of security from the protocol to the wallets.

Even though SHRINCS is meant to be a solution to the problem of securing Bitcoin in the post-quantum era, a primary design goal of SHRINCS seems to be optimizing block space, a shared and currently abundant resource. In doing so, it introduces a potential failure mode that is silent, irreversible, and borne by individuals at the exact layer where their money lives.

For an asset used overwhelmingly as a store of value, where conservative security assumptions are paramount, the added complexity of SHRINCS may paradoxically weaken security for the end user. That risk, along with the economics of wallets and custody providers, makes it unlikely that the extra flexibility this approach buys will, in our view, translate into the cost savings the authors intend to achieve.

Why hash-based signatures are good for Bitcoin

Hash-based signatures rest on hash functions, the most scrutinized and widely deployed primitive in cryptography, and Bitcoin already relies on SHA-256 in consensus. SHRINCS is instantiated entirely with SHA-256, so it introduces no new family of mathematical assumptions into Bitcoin. For outputs that may sit untouched for decades, that is attractive.

Even better: the best-known quantum attack on a hash function, Grover's algorithm, gives a far smaller speedup than Shor's algorithm gives against ECDSA, so a hash-based scheme can be kept secure by adjusting parameters rather than replacing assumptions. That is a more conservative security model than the one Bitcoin relies on today, and more conservative than lattice-based cryptography.

Verification also maps well onto Bitcoin. SHA-256 is heavily optimized, hardware acceleration is widely available, and the verification cost per byte is low. The BIP makes a reasonable argument that this could justify different witness accounting, because signature size grows much faster than verification work. The 48-byte public key is very competitive for a post-quantum construction.

The biggest tradeoffs in hash-based signatures are performance and signature size, and SHRINCS is designed to address both.

SHRINCS: a recap

If you haven't reviewed the proposal already, it's worth taking the time to do that before continuing: github.com/SHRINCS/shrincs-bip/blob/main/SHRINCS.md (opens in a new tab)

The construction has two signing paths. The primary path is stateful, built from FXMSS (flexible XMSS) with WOTS+C, and can produce signatures as small as 548 bytes. The fallback is stateless, based on SLH-DSA (standardized by NIST as FIPS-205 (opens in a new tab)) with a custom parameter set, and produces 5,777-byte signatures. For comparison, SLH-DSA-SHA2-128s signatures are 7,856 bytes.

There is a lot to like. The public key is only 48 bytes. Verification is cheap and consists almost entirely of SHA-256. The stateless fallback means losing the signing state does not mean losing the ability to spend. And the flexible XMSS construction lets signers trade off signature size, signing budget, and computation depending on how the key will be used.

The performance benefits of SHRINCS are largely derived from the stateful path. But the cost of that lands on the wallet, not the protocol. SHRINCS optimizes block space, a shared and currently abundant resource, by introducing a failure mode that can be silent, irreversible, and borne by individuals at the layer where their money lives. It shifts the primary responsibility for post-quantum safety from the protocol to the wallets.

What statefulness costs

The compact path uses one-time WOTS+C keys, so every stateful signature must consume a fresh leaf from the FXMSS tree. WOTS stands for Winternitz one-time signatures, and the fact that these are "one-time" is where the complexity comes in.

The signer has to maintain a counter that only ever moves forward, to ensure that no signature is ever used twice. If the same state is used to sign two different messages, the same one-time key is reused, potentially breaking the security of the scheme and allowing an attacker to forge signatures and steal funds. That counter is a security invariant of the scheme, not an implementation detail.

With Schnorr today, restoring an old wallet backup does not make previously generated signatures cryptographically unsafe. With stateful SHRINCS, restoring the old signing state and then continuing to use the stateful path can.

The BIP recognizes this explicitly. It requires the counter to be incremented in persistent storage before returning a signature, prohibits concurrent stateful signing, and says state must not be restored from backups. If the implementation cannot be certain its state is correct, it must stop using the stateful path and fall back to stateless signing. That is the right behavior, but it means the protocol gets smaller and the wallet inherits the complexity: a state-management invariant that must never break.

Consumer wallets are particularly difficult

Consider a hardware wallet. An attacker gets a copy of the device's encrypted SHRINCS state. The owner then signs a transaction, moving the counter forward. If the attacker can later restore the old state to the device, the wallet can reuse a WOTS+C leaf the next time it signs. The attacker does not need to extract the private key. All they need is the ability to roll back security-critical state.

Software wallets have a more mundane version of the same problem: backups. A wallet is backed up to iCloud. The user signs transactions and advances the SHRINCS state, later loses their phone, and restores an older backup. Unless the wallet has some independent rollback-resistant mechanism, its local state is now behind the actual signing history. No attacker required. Normal disaster recovery creates exactly the condition SHRINCS is trying to prevent.

Seed portability raises a similar issue. Bitcoin users expect to be able to restore a seed into another wallet. A seed can recover the SHRINCS secret material, but it cannot tell the new wallet which stateful WOTS+C leaves have already been used. The BIP handles this correctly by requiring stateless signing when the counter is unavailable or uncertain.

Good state management is possible to engineer. A coordinated setup can catch reuse before broadcast: a software wallet can refuse to relay a signature that its paired hardware device produced from a stale index. But safety then depends on additional coordinated infrastructure that the protocol does not prescribe, and it does nothing for an air-gapped single signer, a seed restored onto a fresh device with no memory of prior use, or two devices initialized from the same backup.

There is also an incentive problem. The proposal implicitly relies on wallet implementers to absorb this complexity, but their incentives to do so are limited. Wallets do not typically monetize fees, and fees are low anyway. After a seed-only recovery the BIP already forces the stateless path, since the new wallet cannot know which leaves were consumed. So the stateful path is expensive to implement correctly, and any recovery demotes the key to stateless regardless. We suspect many consumer wallets will not implement it at all. At that point signatures are 5,777 bytes rather than roughly 548, and a large part of the size advantage disappears.

The institutional custody problem

Institutional custody is a more interesting case because these systems can actually build strong state guarantees. An HSM-backed custody system can maintain monotonic state far more reliably than a consumer wallet: durable storage, transactional updates, tightly controlled signing infrastructure. So we don't think stateful SHRINCS is inherently unsuitable for institutional custody. The question is what it does to the architecture.

Institutional custody is deliberately designed around redundancy: multiple HSMs, geographically separated signing systems, hot and cold failover, backups, disaster recovery procedures, replicated services. SHRINCS adds a requirement across all of it: two valid instances of the same key must never consume the same state.

Suppose two HSMs hold the same SHRINCS key for failover. They cannot independently maintain their own counters. If both believe the next unused state is 42 and sign different messages, the one-time key at that state is reused. You therefore need coordination around signing state, or an architecture that guarantees only one stateful signer can ever operate at a time. Failover has to preserve that invariant. So do disaster recovery, backup restoration and concurrency. That is possible, but it turns an operational consistency problem into a cryptographic security problem.

There is also a distinction between losing state and rolling it back. Losing state is recoverable, because SHRINCS can switch to its stateless path. Believing that stale state is current is more dangerous, because the signer may keep producing compact signatures while reusing one-time keys.

More broadly, clients of institutional Bitcoin custody solutions that use HSMs are typically not conducting a high volume of transactions. Fees matter far less to them than security, where failure is unacceptable. So institutional custodians (already low-margin businesses) have little incentive to invest in something that their customers are unlikely to care about.

The "fallback" is therefore likely to become the default.

The stateless "fallback"

The strongest part of the design is that statefulness is not all-or-nothing. Traditional stateful hash-based signatures create an uncomfortable recovery problem: lose the state and the key may no longer be safe to use. SHRINCS avoids that. If the signer loses its state, or cannot prove it is current, it can still produce a valid stateless signature under the same public key. The failure mode changes from "lost state may mean lost funds" to "lost state means larger signatures".

It also gives a sensible operational rule. Stateful signing is an optimization, available only while the implementation can prove its state-management guarantees hold. Stateless signing is the safe fallback.

The fallback should not be confused with standardized SLH-DSA-SHA2-128s. SHRINCS uses the SLH-DSA algorithms with a non-standard parameter set, reducing the signature budget from 2^64 to 2^40 signatures per public key, which shrinks the signature from 7,856 bytes to 5,777. For Bitcoin, that is an understandable trade; 2^40 is still roughly 1.1 trillion signatures under one public key.

But it means SHRINCS is not simply XMSS plus standardized SLH-DSA. Both its stateful component and the parameterization of its stateless component are new cryptographic design choices that need further analysis. The current BIP is explicit that the security proof, comprehensive test vectors, and the optimized implementation are all still outstanding, and that the supplied Python implementation is an executable specification, not production code. This is an important consideration when judging how mature the proposal is today.

Who bears the risk

The strongest defense of the stateful path is that its risk is local to the signer and can be minimized with careful engineering. We would invert that framing. A signer-local risk is invisible to the network, borne by the individual. Exceed a stateless budget and security degrades gradually; reuse a stateful leaf and security can fail catastrophically, with an attacker able to forge signatures.

Even if that is framed as an individual responsibility, this is the layer where the money actually lives. A network-level cost such as larger signatures is visible, debated in the open, and absorbed collectively. For holders who will never read a spec, the risk of losing their coins is clearly worse than the diffuse impact of slightly higher fees or increased state bloat.

The fee argument

The economic argument for the stateful path is that witness data is priced per byte and stateful signatures are roughly ten times smaller. That argument assumes throughput is scarce. Today, it is not. Fees have averaged around forty cents for months. This is a clear market signal that block space is nowhere close to theoretical capacity today. The gap between theoretical and realized capacity is wide enough that a stateless-default post-quantum scheme could be absorbed now with little practical effect on the people who actually transact.

Bitcoin is, in practice, a high-value, low-velocity settlement asset. Its holders are paying for credibly neutral, final, secure custody, not for cheap high-frequency transfers. Even substantially higher fees and lower throughput would leave much of the store-of-value proposition intact, because the marginal holder optimizes for security and finality rather than transactions per second. Fewer transactions per block is a real consequence, but it lands almost entirely on a use case Bitcoin is not primarily serving.

Who is "the user" this proposal serves?

Some signers genuinely need a large budget. A machine signing continuously, or a high-frequency channel operator, would exhaust a small stateless allotment.

But that argues against building statefulness into the standard, not for it. The dominant use case is a saver whose wallet signs rarely, not a service signing trillions of UTXOs.

Statefulness as an expert's opt-in tool is defensible. Statefulness as a protocol-standard path that every wallet is expected to implement and every user might inadvertently rely on is not.

Where we land

In our view, SHRINCS is elegant engineering, and evidence that serious people in the Bitcoin community are taking Q-Day seriously. But the case for the additional benefits, and complexity, that statefulness brings is not primarily a security argument. It is largely an attempt to avoid a political one.

Bitcoin blocksize has been a lightning rod for over a decade. Whether or not the authors intended it, a reviewer of SHRINCS' design might conclude that this extra complexity reflects a desire to avoid the elephant in the room: whether Bitcoin's blocksize should increase to accommodate the practical performance constraints of post-quantum signature algorithms. By giving SHRINCS a stateful path with minimal on-chain footprint, the authors can plausibly say that this concern is addressed.

But just because it fits Bitcoin's political constraints does not mean it is the most secure solution. And just because the option exists does not imply that anyone will actually use it. Taproot offers a useful analogy: despite the many features and performance benefits enabled by that upgrade, only a small fraction of Bitcoin wallets have implemented support for it, and even fewer BTC holders actually use it.

An alternative approach in which Bitcoin adopts only a stateless scheme while allowing for an increased blocksize should be considered. The broad consensus in the cryptography community is that stateful signatures should be avoided entirely except for relatively narrow and specific use cases. Removing that feature would arguably give Bitcoin the most conservative security assumptions among major cryptocurrencies, consistent with its longstanding design philosophy.

---

Thanks to Jonas Nick (@n1ckler), Mikhail Kudinov (@kudinov_mikhail), and @conduition_io for their discussion. The counterarguments addressed above are our attempt to represent them fairly.