* [bitcoindev] SHRINCS: an efficient hash-based signature scheme for Bitcoin (first draft)
@ 2026-08-26 21:17 'conduition' via Bitcoin Development Mailing List
2026-08-31 23:23 ` [bitcoindev] " Antoine Riard
0 siblings, 1 reply; 2+ messages in thread
From: 'conduition' via Bitcoin Development Mailing List @ 2026-08-26 21:17 UTC (permalink / raw)
To: bitcoindev@googlegroups.com
[-- Attachment #1.1.1: Type: text/plain, Size: 6657 bytes --]
Hi everyone, it's me again.
On behalf of the SHRINCS Working Group, I am excited to announce a first draft of a cryptographic BIP that fully specifies SHRINCS: A semi-stateful hash-based signature scheme for Bitcoin.
https://github.com/SHRINCS/shrincs-bip/blob/main/SHRINCS.md
Disclaimer: Do NOT use in production. SHRINCS is prototype cryptography, still in need of peer review. Formal security proofs are WIP.
Features
SHRINCS offers:
- Compactness. SHRINCS public keys are 48 bytes. Stateful signatures are 548 bytes at the smallest, with a stateless fallback component built into every key pair by default that produces larger 5777-byte signatures.
- NIST-I security (~128-bit classical and ~64-bit post-quantum). SHRINCS' security depends only on properties of the (truncated) SHA256 hash function which are believed to be post-quantum-secure.
- Fast verification performance. Amortized on a per-byte basis, SHRINCS signatures are 4x-16x faster to verify than BIP340 Schnorr depending on whether SHA256 hardware acceleration is available. At worst, verification costs 2792 SHA256 compressions with a 5777 byte stateless signature.
- Flexibility. SHRINCS allows signers to control the shape and size of their stateful keypair to best suit their use-case, while SHRINCS' stateful verifier is agnostic to signer-side choices and contains only a single code path to be scrutinized and optimized.
- Good incentives. SHRINCS with UXMSS provides the most compact signatures possible within the scheme, and the signatures grow as a key is reused. If SHRINCS comes into common use, users will be economically incentivized not to reuse addresses. Address reuse would still be possible, either via stateful BXMSS keys, or via the stateless component.
Drawbacks
SHRINCS has drawbacks:
- The efficient stateful component requires software that can manage an incrementing state counter (essentially the number of signatures issued) for each keypair. If wallet software accidentally reuses the same state counter on two distinct signatures under a key, any adversary who observed both signatures can forge a new one.
- The key generation and signing algorithms are computationally expensive - Though this can be mitigated using SIMD, parallism, or hardware acceleration techniques.
- SHRINCS lacks any algebraic structure allowing for public key rerandomization (to admit BIP32-style xpubs), multisignature schemes (like MuSig), etc, in contrast to feature-rich cryptosystems like Schnorr.
Changes
This new specification is the evolution and formalization of ideas originally put forward by Jonas Nick and Mikhail Kudinov in this Delving thread and in their joint paper referenced therein. Also see this related mailing list thread.
Notable changes since the original proposals 8+ months ago include:
- Black-box compatibility with SLH-DSA (FIPS-205) algorithms. This encourages interoperability with non-Bitcoin systems, and leans into established security proofs.
- Flexible XMSS (FXMSS). Prior descriptions of SHRINCS implied only unbalanced stateful trees were allowed. We now allow stateful trees of any structure.
- New parameter sets. The stateless component now uses a parameter set allowing at most 2^40 stateless signatures, rather than 2^20. This allows SHRINCS to be useful for protocols that require high-frequency signing, such as Lightning. The stateful component now uses parameters which offer much faster performance (at the cost of larger signatures) compared to the original proposal.
Status
This initial draft specification contains only the cryptography of the SHRINCS scheme, decoupled from consensus validation rules. Further BIPs would be required to deploy the SHRINCS signature scheme on Bitcoin. Notably, we cannot safely deploy SHRINCS without introducing at least one new output type, which we do not define in this BIP.
The draft BIP-SHRINCS is not ready to be submitted to the BIPs repository yet. We still have much work to do. Notably absent from this draft are:
- Test vectors
- Unit tests
- A security proof
- An optimized implementation
- Mediawiki or Markdown format compliance
We are posting here to seek review of SHRINCS' design, parameters, cryptography, and reference code, primarily for security, correctness, compatibility, consistency, and clarity, in that order. Insightful reviews will be highly appreciated and met with positive vibes and beers at the next conference :)
We also hope that seeing a concrete specification will spur further discussion of related problems, such as how PQ HD wallets will work, and how to handle user experience of a semi-stateful signing scheme.
We note that SHRINCS' parameters offer a complex multi-dimensional trade-off space between performance and signature size. The choice of parameter set therefore seems ripe for bikeshedding. We provide a forum for parameter set discussion here, but we encourage prospective cyclists to first read the relevant sections of the design rationale, and invite readers to also play with our interactive stateless and stateful parameter set exploration tools.
Those who prefer video format may be interested in this interview discussing the internals of SHRINCS: https://youtu.be/n-jGPICZMR0?si=NpfyTRB88-sUxtlh
Related Work
We are building libshrincs, an attempt at a formally verified C implementation. One machine-checked Rocq theorem covers WOTS+C, the one-time signature in FXMSS: honest signatures verify, the linked C implements its four public contracts under CompCert's semantics (VST), and forging costs breaking truncated SHA256 (SSProve). Still a prototype, more detail on Delving.
Acknowledgements
The SHRINCS specification is the result of several months' collaboration between contributors across multiple organizations. The SHRINCS Working Group is, in alphabetical order:
- Mike Casey (OpenChain)
- Conduition (Brink)
- Ethan Heilman (Cloudflare)
- Mikhail Kudinov (Blockstream)
- Oleksandr Kurbatov (Blockstream)
- Boris Nagaev (Independent)
- Jonas Nick (Blockstream)
- remix7531 (OpenSats)
regards,
conduition
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/-w8D4WbD7zY2bfYQIES40iBZQWbZx6ab-S6EW8tWsMEFaHO9NEOLUkte_MZZgNQDd0pljCM2wD1Ccnk3BfjwLPgCiVz-NfTwjHJ4aZHUqUw%3D%40proton.me.
[-- Attachment #1.1.2.1: Type: text/html, Size: 16023 bytes --]
[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* [bitcoindev] Re: SHRINCS: an efficient hash-based signature scheme for Bitcoin (first draft)
2026-08-26 21:17 [bitcoindev] SHRINCS: an efficient hash-based signature scheme for Bitcoin (first draft) 'conduition' via Bitcoin Development Mailing List
@ 2026-08-31 23:23 ` Antoine Riard
0 siblings, 0 replies; 2+ messages in thread
From: Antoine Riard @ 2026-08-31 23:23 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 8833 bytes --]
Hello Conduition,
From a first read of the document, there is nothing so far
on the signature mode of accounting. If we go for an usage
of stateless for off-chain second-stage txn, be it lightning,
vault, whatever as one might wish to replicate them on many
towers and not have to synchronize state management, that's
5777 bytes...
So it's a 90x-ish of the operational cost for the fee-bumping
reserves all those protocols might have to keep...Of course
we might still go for falcon or whatever, which is more compact,
or the other way discount severely those fields, at the other
downside of increasing the DoS surface of validating nodes.
By the way, there is no table of content in your document.
Thanks for the work overall, it's very interesting.
Best,
Antoine
OTS hash: 53902c7451df74e4046766d6df268b6aaae2916f1b3c6792880659e3efe56777
Le Wednesday, August 26, 2026 à 10:38:01 PM UTC+1, conduition a écrit :
> Hi everyone, it's me again.
>
> On behalf of the SHRINCS Working Group, I am excited to announce a first
> draft of a cryptographic BIP that fully specifies SHRINCS: A semi-stateful
> hash-based signature scheme for Bitcoin.
>
> https://github.com/SHRINCS/shrincs-bip/blob/main/SHRINCS.md
>
>
> *Disclaimer: Do NOT use in production. SHRINCS is prototype cryptography,
> still in need of peer review. Formal security proofs are WIP.*
> Features
>
> SHRINCS offers:
>
>
> - *Compactness*. SHRINCS public keys are 48 bytes. Stateful signatures
> are 548 bytes at the smallest, with a stateless fallback component built
> into every key pair by default that produces larger 5777-byte signatures.
> - *NIST-I security (~128-bit classical and ~64-bit post-quantum)*.
> SHRINCS' security depends only on properties of the (truncated) SHA256 hash
> function which are believed to be post-quantum-secure.
> - *Fast verification performance*. Amortized on a per-byte basis,
> SHRINCS signatures are 4x-16x faster to verify than BIP340 Schnorr
> depending on whether SHA256 hardware acceleration is available. At worst,
> verification costs 2792 SHA256 compressions with a 5777 byte stateless
> signature.
> - *Flexibility*. SHRINCS allows signers to control the shape and size
> of their stateful keypair to best suit their use-case, while SHRINCS'
> stateful verifier is agnostic to signer-side choices and contains only a
> single code path to be scrutinized and optimized.
> - *Good incentives*. SHRINCS with UXMSS provides the most compact
> signatures possible within the scheme, and the signatures grow as a key is
> reused. If SHRINCS comes into common use, users will be economically
> incentivized not to reuse addresses. Address reuse would still be possible,
> either via stateful BXMSS keys, or via the stateless component.
>
>
> Drawbacks
>
> SHRINCS has drawbacks:
>
>
> - The efficient stateful component requires software that can manage
> an incrementing state counter (essentially the number of signatures issued)
> for each keypair. If wallet software accidentally reuses the same state
> counter on two distinct signatures under a key, any adversary who observed
> both signatures can forge a new one.
> - The key generation and signing algorithms are computationally
> expensive - Though this can be mitigated using SIMD, parallism, or hardware
> acceleration techniques.
> - SHRINCS lacks any algebraic structure allowing for public key
> rerandomization (to admit BIP32-style xpubs), multisignature schemes (like
> MuSig), etc, in contrast to feature-rich cryptosystems like Schnorr.
>
>
> Changes
>
> This new specification is the evolution and formalization of ideas
> originally put forward by Jonas Nick and Mikhail Kudinov in this Delving
> thread
> <https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158> and
> in their joint paper <https://eprint.iacr.org/2025/2203.pdf> referenced
> therein. Also see this related mailing list thread
> <https://groups.google.com/g/bitcoindev/c/gOfL5ag_bDU/>.
>
> Notable changes since the original proposals 8+ months ago include:
>
>
> - *Black-box compatibility with SLH-DSA (FIPS-205) algorithms*. This
> encourages interoperability with non-Bitcoin systems, and leans into
> established security proofs.
> - *Flexible XMSS (FXMSS)*. Prior descriptions of SHRINCS implied only
> unbalanced stateful trees were allowed. We now allow stateful trees of any
> structure.
> - *New parameter sets*. The stateless component now uses a parameter
> set allowing at most 2^40 stateless signatures, rather than 2^20. This
> allows SHRINCS to be useful for protocols that require high-frequency
> signing, such as Lightning. The stateful component now uses parameters
> which offer much faster performance (at the cost of larger signatures)
> compared to the original proposal.
>
>
> Status
>
> This initial draft specification contains only the cryptography of the
> SHRINCS scheme, decoupled from consensus validation rules. Further BIPs
> would be required to deploy the SHRINCS signature scheme on Bitcoin.
> Notably, we cannot safely deploy SHRINCS without introducing at least one
> new output type, which we do not define in this BIP.
>
> The draft BIP-SHRINCS is not ready to be submitted to the BIPs repository
> yet. We still have much work to do. Notably absent from this draft are:
>
>
> - Test vectors
> - Unit tests
>
>
> - A security proof
>
>
> - An optimized implementation
> - Mediawiki or Markdown format compliance
>
>
> We are posting here to seek review of SHRINCS' design, parameters,
> cryptography, and reference code, primarily for security, correctness,
> compatibility, consistency, and clarity, in that order. Insightful reviews
> will be highly appreciated and met with positive vibes and beers at the
> next conference :)
>
> We also hope that seeing a concrete specification will spur further
> discussion of related problems, such as how PQ HD wallets will work, and
> how to handle user experience of a semi-stateful signing scheme.
>
> We note that SHRINCS' parameters offer a complex multi-dimensional
> trade-off space between performance and signature size. The choice of
> parameter set therefore seems ripe for bikeshedding. We provide a forum
> for parameter set discussion here
> <https://github.com/SHRINCS/shrincs-bip/issues/32>, but we encourage
> prospective cyclists to first read the relevant sections of the design
> rationale
> <https://github.com/SHRINCS/shrincs-bip/blob/main/SHRINCS.md#rationale>,
> and invite readers to also play with our interactive stateless
> <https://blockstreamresearch.github.io/SPHINCS-Parameters/site/stateless.html>
> and stateful
> <https://blockstreamresearch.github.io/SPHINCS-Parameters/site/stateful.html>
> parameter set exploration tools.
>
> Those who prefer video format may be interested in this interview
> discussing the internals of SHRINCS:
> https://youtu.be/n-jGPICZMR0?si=NpfyTRB88-sUxtlh
>
> Related Work
>
> We are building libshrincs <https://github.com/remix7531/libshrincs>, an
> attempt at a formally verified C implementation. One machine-checked Rocq
> <https://rocq-prover.org/> theorem covers WOTS+C, the one-time signature
> in FXMSS: honest signatures verify, the linked C implements its four public
> contracts under CompCert's semantics (VST <https://vst.cs.princeton.edu/>),
> and forging costs breaking truncated SHA256 (SSProve
> <https://github.com/SSProve/ssprove>). Still a prototype, more detail on
> Delving
> <https://delvingbitcoin.org/t/libshrincs-a-c-implementation-with-a-machine-checked-security-proof/2795>
> .
>
> Acknowledgements
>
> The SHRINCS specification is the result of several months' collaboration
> between contributors across multiple organizations. The SHRINCS Working
> Group is, in alphabetical order:
>
> - Mike Casey (OpenChain)
> - Conduition (Brink)
> - Ethan Heilman (Cloudflare)
> - Mikhail Kudinov (Blockstream)
> - Oleksandr Kurbatov (Blockstream)
> - Boris Nagaev (Independent)
> - Jonas Nick (Blockstream)
> - remix7531 (OpenSats)
>
>
> regards,
> conduition
>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/b4bb949d-bd35-424d-a1d1-459e6cca263an%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 17749 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-08-31 23:34 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-26 21:17 [bitcoindev] SHRINCS: an efficient hash-based signature scheme for Bitcoin (first draft) 'conduition' via Bitcoin Development Mailing List
2026-08-31 23:23 ` [bitcoindev] " Antoine Riard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox