SHRINCS: an efficient hash-based signature scheme for Bitcoin (first draft)

[conduition]

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

[Antoine Riard]

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

[conduition]

Thanks for your reply Antoine. 

You're correct that we do not specify cost accounting. The SHRINCS BIP is currently purely cryptographic, and agnostic to how or where it is deployed. The role is meant to be analogous to BIP340: Specifying the signature scheme, key formats, and usage invariants, and nothing else.

For SHRINCS to be used on Bitcoin, we would also need an additional BIP that deploys SHRINCS into consensus somehow, and that BIP would need to handle size/compute cost accounting. 

> So it's a 90x-ish of the operational cost for the fee-bumping reserves all those protocols might have to keep

The stateless SHRINCS signature is 90x larger than Schnorr, but that doesn't translate directly to a 90x fee cost increase in real-world usage, even in the absence of a further witness discount. You have to account for the transaction weight too. 

Example: 2-input 2-ouput transaction:

- P2TR + Schnorr: 178 non-witness bytes + 64 x 2 witness bytes. Total weight: 178*4 + 128 = 840 WU

- P2MR + SHRINCS (stateless): 178 non-witness bytes + 5857 x 2 witness bytes. Total weight: 12426 WU.

- Difference: ~14.8x

Then you also need to account for the change in the fee market. If SHRINCS were in common usage with no block size increase or witness discount, it's reasonable to assume the fee market would inflate because network throughput will have dropped. I can't conjecture on how high fee rates might escalate in this scenario... I suppose it depends on how many people are able to use the stateful component, or if any other PQ signature algorithms are available at the time (such as Falcon/ML-DSA/SQIsign).

> By the way, there is no table of content in your document.

Thanks for the note, this will be populated automatically once we convert the document to mediawiki.

regards,

conduition

[Murch]

Hi Conduition et al,

I’m excited that your draft has progressed this far. Please feel free to
open a PR to the BIPs repository whenever you’re ready to do so. Please
note that we accept submissions using either MediaWiki or Markdown, so a
conversion to MediaWiki format is not necessary. For either document
type, GitHub makes an outline/navigation available by clicking the
“Outline” button at the right end of the bar above the document content.

Cheers,
Murch

On 2026-09-04 09:07, 'conduition' via Bitcoin Development Mailing List
wrote:

> Thanks for your reply Antoine.
>
> You're correct that we do not specify cost accounting. The SHRINCS BIP
> is currently purely cryptographic, and agnostic to how or where it is
> deployed. The role is meant to be analogous to BIP340: Specifying the
> signature scheme, key formats, and usage invariants, and nothing else.
>
> For SHRINCS to be used on Bitcoin, we would also need an additional BIP
> that deploys SHRINCS into consensus somehow, and that BIP would need to
> handle size/compute cost accounting.
>
> > So it's a 90x-ish of the operational cost for the fee-bumping
> reserves all those protocols might have to keep
>
> The stateless SHRINCS signature is 90x larger than Schnorr, but that
> doesn't translate directly to a 90x fee cost increase in real-world
> usage, even in the absence of a further witness discount. You have to
> account for the transaction weight too.
>
> Example: 2-input 2-ouput transaction:
> - P2TR + Schnorr: 178 non-witness bytes + 64 x 2 witness bytes. Total

> weight: 178*4 + 128 = *840 WU*

> - P2MR + SHRINCS (stateless): 178 non-witness bytes + 5857 x 2 witness

> bytes. Total weight: *12426 WU*.
> - Difference: ~*14.8x*

> <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

> inthis Delving thread <https://delvingbitcoin.org/t/shrincs-324-
> byte-stateful-post-quantum-signatures-with-static-
> backups/2158> and intheir joint paper <https://
> eprint.iacr.org/2025/2203.pdf>referenced therein. Also seethis
> 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 thedesign 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 <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+...@googlegroups.com
> <mailto:bitcoindev+...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> bitcoindev/2fb38fb8-2584-4550-b268-ee7138de419bn%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/2fb38fb8-2584-4550-b268-
> ee7138de419bn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[conduition]

Hey Murch, and thanks for confirming. We were under the impression BIP3 recommends standard (non-flavored) markdown:


> The author of this proposal has no opinion on Markdown flavors, but recommends that proposals stick to the basic Markdown syntax features commonly shared across Markdown dialects.

At the moment we're using features of github flavored markdown in a number of places.

regards,
conduition

> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/c0ff85ab-2b8b-4aea-8a04-e0e8a6be7c94%40murch.one.
>

[Murch]

Hey Conduition,

the reason for that comment was that if we ever move the BIPs to a
different platform, GitHub-flavored Markdown features may break.
However, it has gotten drastically cheaper to amend such issues in
documents, so if that’s the only reason you’re eyeing a translation to a
different format, please feel free to submit the Markdown instead.

Cheers,
Murch

On 2026-09-13 15:25, 'conduition' via Bitcoin Development Mailing List