There is not any concrete proposal for a post-quantum signature scheme in Bitcoin as we speak. Over the previous yr, our staff at Blockstream Research has been trying into precisely this downside. This publish shares what we have discovered, and argues that optimized hash-based signatures are a practical alternative for post-quantum Bitcoin that could possibly be deployed within the close to time period. It covers SHRINCS and SHRIMPS, at present the smallest post-quantum signature schemes constructed on mature cryptographic assumptions, after which sketches what a concrete proposal may seem like.

Modern Bitcoin outputs lock funds to a Schnorr key, and spending them requires a sound Schnorr signature. Schnorr signatures, nevertheless, are susceptible to quantum computer systems. The most pure manner so as to add post-quantum signature verification is to increase the Taproot tree with a post-quantum choice. After a comfortable fork, an output can decide to each a Schnorr key and a post-quantum key. Because Taproot solely reveals the trail that truly will get spent, customers can maintain spending with low-cost Schnorr signatures, and the transaction price stays basically unchanged. The post-quantum choice sits dormant within the tree. Only as soon as a sufficiently highly effective quantum laptop arrives do customers swap to the second path, spend with the post-quantum signature, and pay its transaction price.  

Failure Modes of a Post-Quantum Upgrade

A post-quantum improve can fail in a number of distinct methods, and avoiding every of them shapes the design decisions mentioned later on this publish.

• Throughput collapse. If signatures are too massive, block area fills up and lots of customers will not be capable to transact in any respect.
• Verification prices. If the computational necessities are too high, there will likely be much less full-node verification, which impacts decentralization.
• Signing prices. Hardware wallets and constrained units have to have the ability to sign up an affordable time.
• Broken cryptography, constructed on assumptions that do not maintain up over time.
• No adoption, as a result of the proposal is simply too advanced or would not combine with present infrastructure. If solely you undertake the proposal, that isn’t sufficient: if the remainder of the community will get compromised, your completely safe cash turn out to be economically nugatory.
• Implementation complexity. The implementation accommodates bugs or is susceptible to assaults, and somebody has to keep up this code in Bitcoin’s consensus guidelines perpetually with out by chance introducing even the slightest incompatibilities.

A proposal that avoids these pitfalls has the best probability of acquiring tough consensus.

Standard Candidates

The first set of candidates are schemes standardized by NIST. They exist already, have working implementations, and require comparatively little further effort to show right into a Bitcoin Improvement Proposal. The baseline for comparability is the Schnorr signature scheme utilized in Taproot. If each transaction used Schnorr signatures persistently, Bitcoin may help 6.5 transactions per second at present common transaction shapes. All TPS numbers on this publish assume a mean Bitcoin transaction with 2.27 inputs and a pair of.64 outputs (the 90-day common on 2026-03-30, per transactionfee.info), packed into the present block dimension restrict.

Schnorr signatures help the options that present pockets infrastructure depends on, specifically BIP 32 unhardened key derivation. They additionally allow effectivity upgrades that the ecosystem has deployed on high of Bitcoin in recent times, like MuSig, and deliberate privateness and effectivity enhancements resembling threshold signatures, silent funds, and cross-input signature aggregation.

• ML-DSA, primarily based on lattice assumptions. Throughput collapses to about half a transaction per second (at NIST safety stage 3), and all of Schnorr signatures’ options disappear, together with BIP 32 unhardened derivation.
• SLH-DSA, primarily based on hash features. Hash features are conservative assumptions that Bitcoin already trusts, which justifies concentrating on NIST safety stage 1. Throughput, nevertheless, drops additional to 0.36 transactions per second, and once more, the identical options are lacking.

Neither of those schemes is a drop-in answer, and each decimate community throughput. A block dimension improve may mitigate the throughput downside, however bundling a well timed, pragmatic post-quantum deployment with a controversial block dimension debate is unlikely to succeed. A block dimension improve is best left as a separate dialogue.

Candidates That Need More Research

The NIST schemes are simple to deploy, however their trade-offs are exhausting to swallow. Other candidates promise higher trade-offs, however require considerably extra analysis and time earlier than deployment is real looking.

• Falcon^WS, a latest lattice-based proposal. It presents considerably higher signature sizes (throughput round 1 TPS at NIST safety stage 5), however it’s far too immature to contemplate for deployment. It is included right here as an illustration of what may ultimately be potential with lattice-based schemes.
• Lattice schemes that match Schnorr signatures’ characteristic set, resembling unhardened BIP 32 or threshold signatures. This is a promising path for additional analysis. Unfortunately, including these options considerably will increase signature sizes in comparison with lattice schemes that omit them, in all probability placing throughput under Falcon^WS’s ~1 TPS. For instance, a modified Raccoon-G helps hierarchical deterministic key derivation (together with unhardened), however with 16 kB public keys and 20 kB signatures.
• SQIsign, primarily based on isogenies. Signature sizes are superb, with throughput as much as ~3.6 TPS at safety stage 5, and isogenies have the potential to help Schnorr signatures’ options. The catch is the cryptographic assumptions, that are far much less mature than lattice assumptions. There is an actual threat they may break, and that threat is not going to disappear anytime quickly. Building confidence in new cryptographic assumptions takes a few years.
• Block-wide signature aggregation, a single succinct proof (a SNARK) that aggregates each signature in a block. Conservatively assuming a 500 kB proof per block, throughput can be round 6.7 TPS. Recent proposals alongside these strains embrace BitZip and LeanVM. On high of open questions like who computes the proof and keep away from mining centralization, the engineering complexity is huge.

These instructions are promising for the longer term, however none of them is prepared as we speak.

Optimizing Hash-Based Signatures and the Signing Budget

All of those candidates stay in the identical multi-dimensional trade-off area: assumptions, effectivity, options, and complexity. For hash-based signatures particularly, two instructions look notably promising. First, we are able to add a brand new dimension: statefulness, which opens up new design area. Second, we are able to settle for a minor improve in protocol complexity in alternate for important effectivity beneficial properties. Together, these instructions make hash-based signatures a beautiful candidate. They provide significantly better effectivity with out a new cryptographic assumption, and the cryptography stays comparatively simple to clarify and implement.

Statefulness makes use of an idea constructed into each hash-based signature scheme: the signature funds, a parameter that dictates what number of occasions a single key can securely signal a message. In SLH-DSA, the funds is about to 2^64, successfully limitless for any sensible goal. Shrinking the funds intentionally makes signatures smaller, however by chance exceeding it breaks the scheme’s safety.

SLH-DSA’s signature funds of two^64 yields a signature dimension of practically 8 kilobytes and throughput of 0.36 transactions per second. Reducing the funds to 2^40, a couple of trillion signatures per key, continues to be greater than sufficient: at present block sizes that’s a whole lot of years of nonstop signing. At that smaller funds, signature dimension drops to five.7 kilobytes, enhancing throughput by about 33%.

SHRINCS

How low can we push the signature funds? On Bitcoin’s base layer, greatest observe discourages tackle reuse, so a typical key indicators solely as soon as or just a few occasions. The signature funds can due to this fact be made very small. For customers who do must exceed it, a fallback choice is offered. The building makes use of a single public key with two signing paths: a compact path producing small signatures whereas the funds holds, and a stateless fallback that’s all the time obtainable.

This compact path comes with a price: the signer should persistently observe what number of occasions they’ve signed, in order to not exceed the funds. That counter is state, and a scheme that depends on it’s stateful. Statefulness is troublesome to help in environments like desktop or cell wallets, the place backups are routine. Restoring an outdated backup silently rolls the counter again to a worth that has already been used. A subsequent signature reuses that state, which may compromise the consumer’s funds. Bitcoin builders, together with our staff at Blockstream Research, have labored exhausting to make sure that Bitcoin is misuse-resistant. A stateful scheme is inherently extra fragile than a stateless one. When we first explored this path, our view was that it was a neat trick, however not likely sensible.

There is, nevertheless, one setup the place the consumer can not by chance corrupt state: a devoted signing system. On initialization, the system generates the seed and units the preliminary state, which then lives solely on the system and by no means leaves it. The system produces compact signatures. Because the state is public, a software program pockets can add an additional security verify by verifying {that a} candidate signature doesn’t reuse state earlier than broadcasting it. If the system is misplaced, breaks, or is changed, the consumer hundreds the seed into a brand new system, which routinely falls again to the stateless path and produces a bigger signature. By retaining the state solely on the system, the setup eliminates any alternative for the consumer to deprave it. 

We name the ensuing building SHRINCS. It rests on two core concepts:

• Two signing paths below a single public key: a compact stateful path and a stateless fallback.
• A notably environment friendly compact path. The specifics are past the scope of this publish, however the building builds straightforwardly on present hash-based signature strategies.

Throughput in comparison with the schemes seen to this point:

• SLH-DSA: 0.36 TPS.
• SLH-DSA with the signing funds diminished to 2^40: 0.48 TPS.
• SHRINCS compact path (580-byte signatures): as much as 3 TPS if each signature makes use of the compact path.

The threat profile of SHRINCS is notably completely different from that of the opposite PQ candidates. Those options carry systemic dangers affecting each consumer on the community: low throughput, questionable crypto assumptions, or fragile consensus protocols. SHRINCS carries localized threat as an alternative: state administration on particular person units. With the opportunity of protected deployment and these throughput numbers, SHRINCS now not seems like a neat trick, however a practical post-quantum choice.

SHRIMPS

In SHRINCS, loading a seed into a brand new system is dear as a result of it triggers the stateless fallback, which produces massive signatures. The variety of such occasions throughout a key’s lifetime may be bounded, nevertheless. SHRIMPS exploits this by including a second compact path particularly for these backup units. With a funds of 1 thousand signatures, this path produces signatures of about 3000 bytes. This is roughly 5 occasions bigger than the first system’s signature however two and a half occasions smaller than an SLH-DSA fallback.

Optimizing the Fallback Path

Statefulness was the primary of the 2 instructions recognized earlier. The second is to optimize the stateless fallback path itself.

Starting from SLH-DSA at 7,872 bytes (0.36 TPS), a number of optimizations stack on high:

• Reducing the signing funds to 2^40 brings the scale to five,792 bytes (0.48 TPS), a ~26% discount.
• WOTS+C (coauthored by Blockstream cryptographer Mikhail Kudinov) and PORS+FP, drop-in optimizations to the underlying SPHINCS+ scheme that weren’t adopted into SLH-DSA. These carry the scale to five,060 bytes (0.54 TPS), an additional ~13% discount, with no efficiency penalty. The solely draw back is deviating from the NIST commonplace.
• Accepting 5× longer signing and key era time yields one other ~11%, to 4,496 bytes (0.60 TPS).
• Allowing per-byte verification time as much as ~1.5× that of Schnorr signatures yields one other ~13%, to three,896 bytes (0.69 TPS).

Together these roughly halve the scale of a stateless hash-based signature scheme in comparison with SLH-DSA. Pushed additional, at the price of even longer signing or verification occasions, signatures may shrink extra nonetheless.

A Toy Proposal

The proposal rests on two design rules.

First, don’t improve verification time in comparison with SLH-DSA. This avoids making any future block dimension improve tougher. It additionally considerably simplifies SNARK proof era ought to block-wide signature aggregation ever be adopted.

Second, abandon the thought of a one-size-fits-all signature, and introduce a number of signature schemes tailor-made to particular use instances.

• Desktop and cell layer-1 wallets can not safely maintain state, however they usually have quick CPUs. They use a stateless scheme that trades signing time for compactness: ~4,496-byte signatures at a 2^40 signing funds. This funds is much above something that could possibly be hit by chance.
• Dedicated signing units may be designed to maintain state securely, however their processors are sometimes weak, so high signing price isn’t an choice right here. SHRINCS and SHRIMPS as an alternative use statefulness to maintain signatures small whereas signing stays quick. The stateless fallback makes use of a 2^32 funds (nobody will bodily press a button on a {hardware} pockets 4 billion occasions); signatures are ~580 bytes from a major system, ~3,000 bytes from a backup system, and ~4,336 bytes from the fallback.
• Lightning nodes are stateful by building and profit from quick signing. Channel updates use the identical stateless scheme because the fallback for devoted signing units: 2^32 funds, ~4,336 bytes. A node that in some way reaches 4 billion signatures can roll over to a brand new key. Cooperative channel closes ought to be capable to use the SHRINCS compact path (~580 bytes).

The result’s 4 specialised signature variants working collectively. Effective throughput ranges from 0.60 to three.04 TPS, nicely above the 0.36 baseline of normal SLH-DSA.

Open Questions and Downsides

The proposal is a place to begin fairly than a completed design. It comes with downsides and raises a lot of open questions:

• Verification time prioritized over dimension: the proposal could possibly be extra size-optimized, at the price of verification time. The per-byte verification price is greater than 6× decrease than that of Schnorr signatures, so the block dimension may theoretically be elevated by an element of 6 with out rising block verification time. A extra rigorous argument requires higher benchmarks.
• Reduced fungibility and privateness: giving the choice of mixing a number of signature schemes as an alternative of a single one weakens each.
• Coverage and layer 2: which use instances are not lined by the proposal, and the way does it work together with layer-2 protocols?
• Future SNARK aggregation: how ought to the signature schemes be designed so they’re prepared for SNARK-based aggregation in a possible future comfortable fork? Should that even be a consideration as we speak?
• Signing time: how a lot signing time is tolerable on completely different platforms? Better signing benchmarks would allow us to cut back signature sizes considerably.
• Reference implementation: C++, or a proper specification? In the age of LLMs, formal verification of consensus-critical code is extra possible than ever.

What’s Next?

The design area for a post-quantum improve to Bitcoin is massive, and no single signature scheme is clearly the best alternative. Even so, optimized, stateful hash-based signatures can provide higher trade-offs than the usual schemes obtainable as we speak. They have an opportunity at retaining Bitcoin useful with out counting on future comfortable forks. At the identical time, analysis into longer-term enhancements resembling higher lattice-based schemes, aggregation, and isogeny-based cryptography ought to proceed in parallel.

Fortunately, the deployment query is basically orthogonal to the selection of signature scheme: a brand new hash-based opcode may ship by way of Taproot, Taproot v2, or BIP 360 pay-to-merkle-root.

The area of helpful statefulness-based optimizations to hash-based signature schemes has not been absolutely explored. What different optimizations utilizing statefulness are potential? How can cautious engineering assure the security of stateful setups? Can layer-2 protocols instantly leverage stateful signatures?

For an introduction to hash-based signatures and their parameters, see our paper Hash-based Signatures for Bitcoin. The scripts used to generate the numbers on this publish, a C++ implementation of SHRINCS, a Simplicity verifier, and a draft specification are all obtainable on GitHub. SHRINCS is already deployable in manufacturing: we have demonstrated it on Liquid, and anybody else can do the identical as we speak.