Blockstream narrows a post-quantum signature trade-off
Blockstream Research says it swept 25,935 parameter candidates for SHRINCS, a hash-based post-quantum signature proposal aimed at Bitcoin. The work focuses on the stateless fallback path, where the team reports a signature around 5.7 KB, roughly a quarter smaller than the SLH-DSA baseline it used for comparison. The result is not a Bitcoin upgrade and does not finalize parameters. It is a research step toward understanding whether a practical quantum-resistant signature path can fit Bitcoin’s block-space and verification constraints.Why the SHRINCS parameter search matters
Bitcoin currently relies on Schnorr and ECDSA signatures, both based on elliptic-curve cryptography. Blockstream frames the research around a long-range risk: a sufficiently capable quantum computer could recover a private key from an exposed public key, but the timing and feasibility of such a machine remain unknown.The operational issue is lead time. Migrating a decentralized network to new cryptography would take years, so researchers need to test practical options before any urgent threat appears. In Bitcoin, signature bytes consume block space, verification must be handled by every full node, and keys or signatures may need to be generated on constrained hardware such as signing devices. A post-quantum scheme that is secure but too large or too costly would be difficult to deploy widely.
SHRINCS is Blockstream Research’s proposed hash-based approach. Its security is described as resting only on SHA-256, a hash function already used in Bitcoin mining and addresses. That design choice matters because it narrows the cryptographic assumptions, but it does not remove the engineering trade-off around signature size and computation.
What Blockstream says it searched
The research compares SHRINCS fallback candidates with SLH-DSA, the NIST-standardized form of SPHINCS+ in FIPS 205. Blockstream used SLH-DSA-SHA2-128s as its baseline, with a 7,856-byte signature and parameters listed as h, d, k, a and w.The sweep covered h from 40 to 50, d from 2 to 25, k from 6 to 24, a from 8 to 20, and w values of 16, 32 and 256, with the additional rule that d must divide h. That produced 25,935 candidates. Four requirements filtered the search: at least 128-bit security, unchanged SLH-DSA structure apart from parameters, a signature budget not below 2^40, and a signature smaller than SLH-DSA-SHA2-128s.
After those requirements, Blockstream says 9,182 candidates remained. The team then evaluated signature size, key generation cost, signing cost, verification cost and verification cost per signature byte, counting costs in SHA-256 compression calls rather than measured runtime benchmarks.
The reported candidate improves size, not parity with Schnorr
Blockstream reports that its preferred stateless fallback candidate is near 5.7 KB, about 25% smaller than SLH-DSA and cheaper for signing and verification under its model. A second candidate reportedly saves another 64 bytes but raises signing cost to 1.37 times the baseline comparison used by the researchers.That is a meaningful reduction for a backup path, but it is not close to today’s Bitcoin signatures. The source states that current Schnorr signatures are 64 bytes, while SHRINCS stateful signatures start at 324 bytes and the stateless fallback remains near 5.7 KB after the sweep. Blockstream describes that fallback as a backup mechanism rather than the everyday path.
The difference explains why parameter selection is more than a theoretical exercise. If a fallback signature is used rarely, larger size may be tolerable. If it becomes common, the cost in transaction weight, node verification and wallet behavior would become much more visible.
Stateful use cases remain less settled
SHRINCS has two signing paths under Blockstream’s description. The compact stateful path is intended for ordinary use, with signatures starting at 324 bytes and growing by roughly 16 bytes for each additional signature. The stateless fallback is designed to keep working if the signer loses state, but it carries the larger size penalty.Blockstream says the stateful side is harder to reduce to a single answer because the right geometry depends on use case. Many users may prefer UXMSS, described as the smallest signature option in the proposal, while Lightning Network users or miners may prefer XMSS or XMSS-MT when they need many signatures under the same key with constant signature size.
That distinction is useful for wallet and protocol developers. A cold-storage wallet, a Lightning node and a mining setup do not necessarily optimize for the same balance of key generation, signing speed, verification cost and signature bytes.
Open explorer turns the paper into a reproducible tool
Blockstream also released an open-source explorer for the candidate space. The tool lets users set metric bounds and weights, then search for candidates that survive those constraints and minimize a weighted distance score against the selected metrics.The post cautions that the cost numbers are model counts of SHA-256 compression calls, not benchmarks. That means they can rank candidates consistently inside the model, but they do not directly state how long an operation will take on real hardware. Users can run SLH-DSA and apply the explorer’s coefficients to estimate practical performance.
This is the strongest near-term implication of the release. The post does not ask the Bitcoin ecosystem to accept a final parameter set. It gives wallet developers, protocol researchers and reviewers a way to test their own assumptions against the same candidate space.
Conclusion
Blockstream’s SHRINCS parameter sweep shows measurable room to reduce the size of a hash-based stateless fallback for Bitcoin, while preserving the basic SLH-DSA structure and a 128-bit security target. The reported result is still far larger than today’s Schnorr signatures, so it should be read as engineering progress inside a constrained design space, not as a ready deployment plan.The research also clarifies the central post-quantum Bitcoin trade-off: smaller signatures, cheaper verification, signing cost and operational safety cannot all be optimized at once. By publishing an explorer, Blockstream has made that trade-off easier to inspect, reproduce and challenge before any protocol decision is on the table.
Sources
Editorial Team - CoinBotLab