Bitcoin transactions are protected by Schnorr and ECDSA signatures, both built on elliptic-curve cryptography. A sufficiently capable quantum computer could recover a private key from an exposed public key and spend the funds it protects. Nobody knows when or whether such a machine might exist or not, but migrating Bitcoin to new cryptography would take years, so the groundwork has to happen well before the threat does.
For a broader look at what quantum computing means for Bitcoin, start with Blockstream's quantum page.
SHRINCS is a hash-based signature scheme proposed by Blockstream Research as a practical post-quantum option for Bitcoin. It gives a single public key two signing paths: (1) a compact stateful path for everyday use, where signatures start at 324 bytes and grow by roughly 16 bytes with each additional signature, and (2) a stateless fallback that still works if the signer ever loses its state but at the cost of larger signature size. Its security rests only on the SHA-256 hash function, which Bitcoin already relies on for mining and addresses. Blockstream’s Director of Research Jonas Nick introduced the design in depth in his OP_CHECKSHRINCS post.
Each hash-based signature scheme has a set of parameters that define its shape, size, and the cost of its underlying functions (key generation, signature generation, and verification), and every parameter choice trades one metric against the others. On Bitcoin, where signature bytes compete for block space, where signatures need to be verified by all nodes of the network, and where signatures as well as keys need to be generated on resource-constrained devices (such as hardware wallets), those choices decide whether a post-quantum signature stays practical. The design choice behind SHRINCS was to find the shortest signature while keeping it practical for Bitcoin use cases.
In this blog post, we show how we swept over 25,935 candidates and arrived at a stateless fallback roughly 25% smaller than SLH-DSA and slightly cheaper from the signature generation and verification perspective. We also built an open-source explorer, so anyone can verify our choices.
Geometry of a Stateless Fallback
A SPHINCS+ signature consists of layers of Merkle trees (the hypertree), with few-time signatures (FORS) at the leaves. The layers are glued together by one-time Winternitz signatures. NIST standardized SPHINCS+ as SLH-DSA in FIPS 205, and we use that name below.
The hypertree structure of SLH-DSA
Parameters
The "geometry" of the tree is defined by five parameters:
- h - the hypertree height. The signature budget (how many signatures one key can safely produce) is defined as 2h, but the bigger h is, the bigger the signature size.
- d - the number of layers in the tree. The smaller d is, the smaller the signature. At the same time, a smaller d makes each layer's tree taller, which increases the cost of key and signature generation exponentially.
- k - the number of FORS trees. Each FORS tree contributes to security but increases the signature size.
- a - the height of the FORS tree. The same trade-off applies: the bigger a is, the fewer trees are needed for the same security level, but it increases key and signature generation complexity.
- w - the Winternitz parameter. A bigger w means fewer hash chains and therefore a shorter signature. At the same time, each chain becomes longer, so key and signature generation require more hashes.
SLH-DSA defines several parameter sets; we take SLH-DSA-SHA2-128s as our baseline, with (h, d, k, a, w) = (63, 7, 14, 12, 16). We are going to sweep over the parameters above (within particular ranges) to find more efficient candidates.
Requirements and Constraints
We fix four requirements before searching:
- Security must not fall below 128 bits (to satisfy NIST security Level 1).
- The structure of SLH-DSA remains unchanged (same algorithms, hash functions, addressing, etc.); we change only the parameters.
- The signature budget shouldn't be lower than 240 (practical for both on-chain and L2 cases).
- The signature must be smaller than the SLH-DSA-SHA2-128s signature (7,856 bytes), since otherwise there is no point.
For each candidate, we compute (1) signature size, (2) key generation cost, (3) signature generation cost, (4) verification cost, and (5) verification cost per signature byte. Costs are counted in SHA-256 compression calls, assuming the PK.seed midstate is cached (which FIPS 205 permits), so hashing two child nodes costs one compression.
The Search
Our sweep covers h ∈ [40, 50], d ∈ [2, 25], k ∈ [6, 24], a ∈ [8, 20], and w ∈ {16, 32, 256}; since d must divide h (all layers have the same height), this gives 25,935 candidates in total. The requirements above leave 9,182 candidates. The question is: "Which of them are the most practical?"
Our approach consists of two filtering steps (for more details, see the report). In the first, we define per-metric bounds: we use X_* coefficients to describe the bounds (relative to SLH-DSA) within which each candidate's metric should stay. For example, "X_kg = 2.0, X_sg = 0.75" should be read as "key generation cost shouldn't exceed 2x that of SLH-DSA, and signature generation cost should be at least 25% lower." All five bounds are applied in sequence, so we can see which candidates fail which limit.
The second step is a weighted distance calculation. Each metric is expressed as a ratio to the SLH-DSA value, and the user defines what matters more (key generation complexity, signature verification cost, etc.) by assigning each metric a weight. Our explorer then picks the survivor with the smallest weighted distance to the origin (the ideal point where every metric would be zero).
Results
Since our goal was the shortest signature that stays close to SLH-DSA metrics, we weighted signature size most heavily and identified two promising candidates.
| Metric / Signature | SLH-DSA | C1 (45,5,10,13,16) | C2 (45,5,8,16,16) |
|---|---|---|---|
| Signature size, B | 7,856 | 5,776 (0.74x) | 5,712 (0.73x) |
| KeyGen, C | 292,351 | 292,351 (1.00x) | 292,351 (1.00x) |
| SigGen, C | 2,218,483 | 1,707,512 (0.77x) | 3,034,618 (1.37x) |
| SigVer, C | 2,155 | 1,550 (0.72x) | 1,546 (0.72x) |
| SigVer, C/B | 0.496 | 0.48 (0.98x) | 0.48 (0.98x) |
* C is the cost in SHA-256 compression function calls; B is bytes
Candidate 1 (C1), at 5.7 KB, is smaller than SLH-DSA and cheaper to sign and verify. C2 saves a further 64 bytes at a 1.37x signing cost, which is reasonable in settings where signing complexity is secondary.
Stateful Part
The stateful part is more difficult to analyze. While the stateless part is considered only a backup option, the geometry of the stateful part is shaped by the use case. Most users will likely prefer UXMSS, the unbalanced variant of the eXtended Merkle Signature Scheme (XMSS) at the core of SHRINCS, because it's the smallest possible signature (≥ 324 bytes; each subsequent signature is 16 bytes bigger). For the Lightning Network or miners, it's reasonable to support as many signatures as possible with the same key and a constant signature size, so XMSS and its multi-tree variant XMSS-MT look better here (they are still much smaller than the stateless part). Also, users may have different equipment, which can speed up key generation and enable effective caching and parallelization for fast signing.
So we don't provide or recommend any specific candidates, but we let you compare them directly in the explorer. We applied the same methodology: the explorer compares candidates against SLH-DSA metrics and searches for the "closest" candidate according to the desired weights.
The Explorer
We built an open-source explorer for analyzing signature candidates. The user can set the bounds and weights and search for optimal candidates.
A small note: the numbers are model counts of compression calls, not benchmarks; they rank candidates faithfully but don't tell you how long operations would take in practice. But users can run SLH-DSA and multiply the numbers by the coefficients from the explorer to get close-enough estimates.
What This Means for Post-Quantum Bitcoin
Regardless of the parameters’ choice, we can’t make hash-based signatures as small as today’s Schnorr signatures (64 bytes). SHRINCS’s stateful signatures start from 324 bytes (5x bigger) with the stateless fallback near 5.7KB (~90x), even after our sweep. That gap is why the stateless path exists only as a backup mechanism.
Still, backup's price matters: compared to SLH-DSA, our candidates reduce the fallback signature size by about 2 KB and achieve an additional 28% reduction in verification cost.
None of these parameters are final, and the stateful side in particular depends on how an address gets used. The explorer is open-source and deployed, so wallet developers, protocol researchers, and anyone else can use it: set the bounds and weights that match the case and see which candidate survives. The explorer supports a shareable URL for every view (this one shows our picks). If your weights produce a candidate you find more convincing than ours, we would like to see it.
To dig in further:
- Explore the candidate space with your own bounds and weights.
- Read the technical report for the full methodology.
- Read the SHRINCS proposal on Delving Bitcoin.