OP_CHECKSHRINCS: Hash signature opcodes designed for Bitcoin's quantum resistance

Author: Jonas Nick

Source: https://blog.blockstream.com/op_checkshrincs-a-hash-based-signature-opcode-for-post-quantum-bitcoin/

Currently, there is no concrete solution for integrating post-quantum signatures into Bitcoin. Blockstream Research has been researching this issue for the past year. This article shares what we have learned and argues that optimized hash function-based signatures are a pragmatic choice for Bitcoin's quantum resistance and could be deployed soon. The article also introduces "SHRINCS" and "SHRIMPS," post-quantum signature schemes with minimal signature size built on well-established cryptographic assumptions; then, it outlines a preliminary proposal.

The latest type of Bitcoin output locks funds to a Schnorr public key, and spending these outputs requires a valid Schnorr signature. However, Schnorr signatures are vulnerable to quantum computers. The most natural way to add post-quantum signature verification is to use a post-quantum option to extend the Taproot script tree. After a soft fork upgrade, a Bitcoin output can simultaneously commit to a Schnorr public key and a post-quantum signed public key. Because Taproot only reveals the Merkle tree path of the script that is actually spent, users can continue to use Schnorr signatures to spend (which are smaller, so transaction fees will be cheaper), and the cost of transactions will remain almost unchanged. The post-quantum option can wait quietly on the script tree. Only when sufficiently powerful quantum computers become available will users need to switch to the second path: using post-quantum signatures to spend, at which point higher transaction costs will apply.

Failure scenarios after quantum upgrade

The upgrade to quantum resistance may fail for various reasons, and the proactive avoidance of these situations shapes the design choices that will be discussed later.

• Throughput plummeted . If the signature size is too large, block space can easily be exhausted, and many users will be unable to confirm transactions at all.
• Verification cost . If the computational requirements for verifying signatures are too high, the number of nodes capable of fully verifying signatures will decrease, which will affect the centralization of the network.
• Signature cost . Hardware signers and resource-constrained devices should be able to generate signatures within a reasonable timeframe.
• The cryptography was broken . It relied on the security assumption that the assumption could not remain true indefinitely.
• No one adopted it . The upgrade proposal was too complex or couldn't be integrated into the existing infrastructure. It's not enough for just you to adopt the proposal: if everyone else on the network is compromised, your coins, even if perfectly secure, are economically worthless.
• The complexity of implementation . The proposed implementation may contain bugs or be vulnerable to attacks, and due to the unique nature of Bitcoin's consensus rules, people will have to maintain this code indefinitely, without accidentally introducing even the slightest incompatibility.

Only proposals that can avoid these pitfalls have a chance of gaining a rough consensus.

Standard Candidate

The first group of candidates consists of schemes standardized by NIST (National Institute of Standards and Technology). These schemes already exist and have available implementations, which can be converted into Bitcoin Upgrade Proposals (BIPs) with minimal effort. The benchmark for comparison is the Schnorr signature scheme used in the Taproot output. If every transaction uses a Schnorr signature, the Bitcoin network could (equivalent to) 6.5 transactions per second, based on the current average transaction size. All TPS (transactions per second) used in this paper assume an average of 2.27 inputs and 2.64 outputs per transaction (a 90-day average measured as of March 30, 2026, according to transactionfee.info ), and that the Bitcoin block size limit remains constant.

Schnorr signatures support features upon which current wallet infrastructure relies, particularly BIP 32 unhardened key derivation. It has also facilitated efficiency upgrades deployed across the ecosystem on Bitcoin in recent years (such as MuSig2), as well as planned privacy and efficiency enhancements (such as threshold signatures, silent payments, and signature aggregation across inputs).

• ML-DSA , based on the "lattice" assumption, would reduce throughput to half a transaction per second (by NIST security level 3); furthermore, all features of Schnorr signatures would be lost, including BIP 32 unhardened key derivation.
• SLH-DSA is based on a hash function. The hash function is a conservative assumption that Bitcoin already relies on, thus allowing it to target NIST security level 1. However, throughput will drop further to 0.36 transactions per second; similarly, the properties of Schnorr signatures will be lost.

Neither of these approaches is a quick fix, and both would cause a significant drop in network throughput. Increasing the block size limit could alleviate the throughput problem, but tying a time-sensitive, pragmatic post-quantum upgrade to a controversial block size increase is unlikely to succeed. It's best to discuss the block size limit separately.

Candidates requiring further research

The solutions standardized by NIST are easy to deploy, but their sacrifices are unacceptable. Other candidates promise better trade-offs, but require much more research and time before deployment becomes a reliable option.

• Falcon^WS is a relatively new lattice-based signature. It offers significantly better signature size (throughput reaching 1 TPS at NIST security level 5), but it is still too immature for deployment. It's included here to demonstrate what might ultimately be possible based on lattices.
• Lattice signatures matching the Schnorr signature feature set , such as BIP 32 and threshold signatures, are a promising direction worthy of further investigation. Unfortunately, adding these features significantly increases the signature size (compared to lattice schemes that ignore these features), potentially reducing throughput to approximately 1 TPS, lower than Falcon^WS. For example, a modified Raccoon-G scheme supports hierarchical deterministic key derivation (including unhardened derivation), but the public key size reaches 16 kB, and the signature size is 20 kB.
• SQIsign , based on "isogeneities," boasts elegant signature sizes and throughput reaching approximately 3.6 TPS (security level 5), with isogeny potentially supporting the characteristics of Schnorr signatures. The tricky part lies in its cryptographic assumptions, which are far less mature than lattice assumptions. The risk of being breached is real and likely cannot be eliminated in the short term. Building confidence in new cryptographic assumptions will take many years.
• Block-level signature aggregation uses a concise proof (a SNARK) to aggregate all signatures in a block. Conservatively estimated, each block requires a 500 kB proof, resulting in a throughput of approximately 6.7 TPS. Recent proposals along this path include BitZip and LeanVM . Several open questions remain, such as who will compute the proof, how to avoid mining centralization, and the engineering complexity is considerable.

Optimize hash function-based signatures and signature quotas

All these candidates exist within the same multidimensional trade-off space: security assumptions, efficiency, properties, and complexity. For hash function-based signatures, two directions seem particularly promising. First, we can add a new dimension: statefulness, thus opening up a completely new design space. Second, we can accept a slight increase in protocol complexity in exchange for significant performance improvements. Combining these two approaches, hash function-based signatures become an attractive candidate. They offer higher efficiency without incorporating new cryptographic assumptions, and their cryptography remains relatively easy to interpret and implement.

The "memory requirement" utilizes a concept built into every hash function-based signature scheme: the " signature quota ." This parameter indicates the number of times a single public key can securely sign a new message. In SLH-DSA, the quota is set to 2^64, which is virtually infinite for any practical application. Intentionally reducing the quota can make the final signature smaller; however, once the quota is exhausted, the security of a public key is compromised.

With a signature quota of 2^64, the size of an SLH-DSA signature is close to 8 kB, resulting in a throughput of 0.36 TPS. Reducing the quota to 2^40 (one trillion signatures per public key) is still sufficient: at the current block size, the quota could last for hundreds of years without being exhausted. With this smaller quota parameter, the signature size would decrease to 5.7 kB, increasing throughput by 33%.

SHRINCS

So how low can the signature quota be reduced? At the Bitcoin base layer, best security practices discourage address reuse, so a typical public key will only be used for signing a few times. Therefore, the signature budget can be very low. For users who need more than this, a backup option can be provided. This construction gives a public key two signature paths: a compact path, within the quota, producing small signatures; and a always-available backup path, producing signatures without needing to remember signature counts.

Compact paths come at a cost: signers must constantly track their signature count to prevent exceeding their quota. This counter is the state , and schemes that rely on it are stateful . In environments like desktop and mobile wallets, backup-import is a routine operation, making statefulness difficult to support. Re-importing an old backup can unknowingly roll back the counter to a previously used value. Subsequent signatures will reuse the state, potentially putting users' funds at risk. Bitcoin developers, including our team at Blockstream Research, have been working to ensure Bitcoin products are resistant to misuse. Stateful schemes are inherently more vulnerable (compared to stateless schemes). Initially, when exploring this direction, our view was that while it was an interesting technique, it wasn't very practical.

However, there is a mechanism to prevent users from accidentally corrupting the state: a dedicated signing device. After initialization, the device generates a seed term and sets an initial state, which then resides exclusively within that device and never leaves. This device produces a compact signature. Because this state is public, software wallets can add an extra security check to verify that a ready signature does not reuse state before transaction broadcasting. If this signing device is lost, damaged, or replaced, the user can import the seed term into a new device, which will automatically exit into a stateless path, producing a stateless, larger signature. By completely preserving the state on the device, the possibility of users corrupting it is eliminated.

We will name the resulting construct "SHRINCS". It relies on two core ideas:

• A public key can be used with two signing paths : a compact, stateful path and a stateless backup path.
• The design employs a highly efficient and compact path : the details of which are beyond the scope of this paper, but this construction is built directly on existing hash function-based signature schemes.

Throughput Comparison:

• SLH-DSA : 0.36 TPS
• The signature quota has decreased to 2^40 for SLH-DSA : 0.48 TPS
• SHRINCS compact path (signature size 580 bytes): Up to 3 TPS (assuming each signature uses a compact path)

SHRINCS's risk profile differs significantly from other post-quantum candidates. Those schemes carry systemic risks affecting every user on the network: low throughput, questionable cryptographic assumptions, and fragile consensus protocols. In contrast, SHRINCS relies on localized risks: state management on individual devices. Given the possibility of secure deployment and these throughput figures, SHRINCS is no longer just an interesting trick, but a pragmatic option for quantum resistance.

SHRIMPS

In the SHRINCS scheme, importing the seed term into a new device is expensive because it triggers a stateless backup path, resulting in a larger signature. However, this doesn't happen very often in the lifetime of a key. SHRINCS leverages this by adding a second, compact path specifically for these backup devices. Using a quota of 1000 signatures, this path produces a signature of approximately 3000 bytes. This is 5 times the size of the primary device signature, but still 2.5 times smaller than the backup path (SLH-DSA signature).

Optimize backup path

Incorporating statefulness is one of the two directions mentioned earlier. The second direction is optimizing the stateless backup path itself.

Starting from 7,872 bytes (0.36 TPS) of the SLH-DSA signature, these optimizations can be added:

• Reducing the signature quota to 2^40 will shrink the signature size to 5,792 bytes (0.48 TPS), a reduction of approximately 26%.
• WOTS+C (of which Blockstream cryptographer Mikhail Kudinov is a co-author) and PORS+FP are direct, readily available alternatives to SPHINCS+, but not adopted by the SLH-DSA scheme. This reduces the signature size to 5,060 bytes (0.54 TPS), a further reduction of approximately 13%, without impacting performance. The only drawback is that it deviates from the NIST standard.
• Accepting five times the length of signature and key generation time can result in an additional size reduction of approximately 11%, resulting in 4,496 bytes (0.60 TPS).
• Allowing the verification time per byte to rise to about 1.5 times that of Schnorr signatures , it can be further reduced by about 13%, resulting in 3,896 bytes (0.69 TPS).

All of these factors combined can reduce the size of a stateless hash function-based signature to half that of an SLH-DSA signature. Even more drastic measures can be taken, at the cost of longer signing or verification times, to further reduce the signature size.

A naive proposal

This proposal relies on two design principles.

First, it does not increase verification time (compared to the SLH-DSA scheme). This is to avoid making it even more difficult to increase block size limits in the future. It also significantly simplifies the generation of SNARK evidence if block-level signature aggregation can be adopted.

Secondly, the idea of "one signature for all purposes" is abandoned, and multiple signature schemes are introduced for specific application scenarios.

• Desktop and mobile layer-1 wallets cannot securely store state, but they typically have faster CPUs. They can use stateless signing schemes that sacrifice signing time for compactness: with a signing quota of 2^40, the signature size is approximately 4,496 bytes. This quota is well beyond the number of times it might be accidentally reached.
• Dedicated signing devices can be designed to securely preserve state, but their processors are typically weak, so increasing the cost of signing is not a viable strategy. SHRINCS and SHRIMPS use stateful signing to ensure small signature sizes and fast signing speeds. A stateless alternate path uses a 2^32 signature quota (nobody would press a button 4 billion times on a hardware signer); the primary device's signature size is approximately 580 bytes; the alternate device's (compact) signature size would be approximately 3,000 bytes, and the alternate path's signature size would be approximately 4,336 bytes.
• Lightning nodes are inherently stateful and benefit from faster signature speeds. Channel updates use the same stateless scheme as the backup path for dedicated signature devices: a signature quota of 2^32, approximately 4,336 bytes of signature. Nodes approaching 4 billion signatures can rotate to the new public key. Cooperative channel closure should be possible using the SHRINCS compact path (approximately 580 bytes).

The result is four combined proprietary signature variants. Actual throughput ranges from 0.60 to 3.04 TPS, far exceeding the standard SLH-DSA scheme's 0.36 TPS.

Open questions and shortcomings

This proposal is more of a starting point than a completed design. It also has its limitations and some unresolved issues:

• Verification time takes precedence over size : This proposal can further optimize signature size, at the cost of verification time. Currently, the verification cost per byte is 6 times lower than that of Schnorr signatures, so theoretically, the block size could be increased by 6 times without increasing block verification time. More rigorous justification requires better benchmarking. (Translator's note: Network bandwidth bottlenecks will not allow us to do such a crazy thing.)
• Reduced homogeneity and privacy : Allowing the combination of multiple signature schemes instead of using only one will simultaneously reduce the privacy of these schemes.
• Coverage and Layer 2 : Are there any application scenarios that this proposal does not cover? How will this proposal interact with Layer-2 protocols?
• How should signature schemes be designed to prepare for potential future SNARK-based signature aggregations that may be introduced through soft forks? Should this be a consideration today?
• Signature time : How long is acceptable for signing on different computing platforms? Better signature time benchmarks will allow us to significantly reduce signature size.
• Reference Implementation : C++ Code, or a Formal Specification? In the era of LLM (Large Language Model), formal verification of consensus-critical code is more feasible than ever before.

What's next?

The design space for Bitcoin's post-quantum upgrade is vast, and no single signature scheme is clearly the right choice. Even so, optimized, stateful hash-based signatures offer better trade-offs than today's standard schemes. They hold the promise of keeping Bitcoin usable without relying on future soft forks. Meanwhile, research into longer-term improvements, such as better lattice-based schemes, signature aggregation, and homology-based cryptography, should proceed in parallel.

Fortunately, deployment issues are largely independent of the choice of signature scheme: new hash function-based opcodes can be released via Taproot, Taproot v2 , or BIP 360 "Pay to Merklegen".

The optimizations brought about by statefulness on top of hash function-based signature schemes are still largely unexplored. Are there other potential optimizations that statefulness can bring? Can careful engineering design guarantee the security of stateful devices? Can various layer-2 protocols directly utilize stateful signatures?

To learn about hash function-based signatures and their parameters, you can read our paper, " Considering Hash Function-Based Signatures for Bitcoin ." The script here can be used to derive the numbers appearing in this article. A C++ implementation of SHRINCS , a validator in the Simplicity language , and a draft specification can also be found on GitHub. SHRINCS is already deployable in production: we've demonstrated it on the Liquid sidechain , and everyone can try it out themselves.

(over)