* [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; 7+ 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] 7+ 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
2026-09-04 16:07 ` 'conduition' via Bitcoin Development Mailing List
0 siblings, 1 reply; 7+ 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] 7+ messages in thread
* [bitcoindev] Re: SHRINCS: an efficient hash-based signature scheme for Bitcoin (first draft)
2026-08-31 23:23 ` [bitcoindev] " Antoine Riard
@ 2026-09-04 16:07 ` 'conduition' via Bitcoin Development Mailing List
2026-09-11 22:54 ` Murch
0 siblings, 1 reply; 7+ messages in thread
From: 'conduition' via Bitcoin Development Mailing List @ 2026-09-04 16:07 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 11001 bytes --]
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
On Monday, August 31, 2026 at 4:34:50 PM UTC-7 Antoine Riard wrote:
> 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/2fb38fb8-2584-4550-b268-ee7138de419bn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 20082 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Re: SHRINCS: an efficient hash-based signature scheme for Bitcoin (first draft)
2026-09-04 16:07 ` 'conduition' via Bitcoin Development Mailing List
@ 2026-09-11 22:54 ` Murch
2026-09-13 22:25 ` 'conduition' via Bitcoin Development Mailing List
0 siblings, 1 reply; 7+ messages in thread
From: Murch @ 2026-09-11 22:54 UTC (permalink / raw)
To: bitcoindev
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*
>
> 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
>
> On Monday, August 31, 2026 at 4:34:50 PM UTC-7 Antoine Riard wrote:
>
> 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
> <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+unsubscribe@googlegroups.com
> <mailto:bitcoindev+unsubscribe@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>.
--
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/c0ff85ab-2b8b-4aea-8a04-e0e8a6be7c94%40murch.one.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Re: SHRINCS: an efficient hash-based signature scheme for Bitcoin (first draft)
2026-09-11 22:54 ` Murch
@ 2026-09-13 22:25 ` 'conduition' via Bitcoin Development Mailing List
2026-09-15 22:39 ` Murch
0 siblings, 1 reply; 7+ messages in thread
From: 'conduition' via Bitcoin Development Mailing List @ 2026-09-13 22:25 UTC (permalink / raw)
To: Murch; +Cc: bitcoindev
[-- Attachment #1.1: Type: text/plain, Size: 14888 bytes --]
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
On Friday, September 11th, 2026 at 5:57 PM, Murch <murch@murch.one> wrote:
> 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*
> >
> > 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
> >
> > On Monday, August 31, 2026 at 4:34:50 PM UTC-7 Antoine Riard wrote:
> >
> > 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
> > <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+unsubscribe@googlegroups.com
> > <mailto:bitcoindev+unsubscribe@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>.
>
> --
> 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/c0ff85ab-2b8b-4aea-8a04-e0e8a6be7c94%40murch.one.
>
--
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/gQG2loLv5XaZrJVFrD_nVtP1m-yTF89A-phqkz-V5qA8VpmygXJnyRG6_nU73Hb-C4ZbIEZghvEj6rEulV2TqtLQHUisu5xIg8Ak-1J4Q3o%3D%40proton.me.
[-- 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] 7+ messages in thread
* Re: [bitcoindev] Re: SHRINCS: an efficient hash-based signature scheme for Bitcoin (first draft)
2026-09-13 22:25 ` 'conduition' via Bitcoin Development Mailing List
@ 2026-09-15 22:39 ` Murch
2026-09-19 2:07 ` 'conduition' via Bitcoin Development Mailing List
0 siblings, 1 reply; 7+ messages in thread
From: Murch @ 2026-09-15 22:39 UTC (permalink / raw)
To: bitcoindev
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
wrote:
> 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
>
> On Friday, September 11th, 2026 at 5:57 PM, Murch <murch@murch.one> wrote:
>
>> 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*
>>>
>>> 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
>>>
>>> On Monday, August 31, 2026 at 4:34:50 PM UTC-7 Antoine Riard wrote:
>>>
>>> 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
>>> <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+unsubscribe@googlegroups.com
>>> <mailto:bitcoindev+unsubscribe@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>.
>> --
>> 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/c0ff85ab-2b8b-4aea-8a04-e0e8a6be7c94%40murch.one.
>>
--
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/70cc8e00-e4fd-46de-b9b4-27bc39bfcbe8%40murch.one.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Re: SHRINCS: an efficient hash-based signature scheme for Bitcoin (first draft)
2026-09-15 22:39 ` Murch
@ 2026-09-19 2:07 ` 'conduition' via Bitcoin Development Mailing List
0 siblings, 0 replies; 7+ messages in thread
From: 'conduition' via Bitcoin Development Mailing List @ 2026-09-19 2:07 UTC (permalink / raw)
To: Murch; +Cc: bitcoindev
[-- Attachment #1.1: Type: text/plain, Size: 17171 bytes --]
Hey Murch,
That's great news for us if GFMD is acceptable. I have made a note in the appropriate issue: https://github.com/SHRINCS/shrincs-bip/issues/21
Before we submit a PR though, we would still like some time to review public feedback and assess whether any significant changes should be made to the SHRINCS BIP draft before we PR it into the BIPs repo.
Some off-thread feedback I feel obliged to share:
- https://x.com/P3b7_/status/2100243609861693898
- https://x.com/projecteleven/status/2093450676529774992
regards,
conduition
On Tuesday, September 15th, 2026 at 4:12 PM, Murch <murch@murch.one> wrote:
> 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
> wrote:
> > 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
> >
> > On Friday, September 11th, 2026 at 5:57 PM, Murch <murch@murch.one> wrote:
> >
> >> 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*
> >>>
> >>> 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
> >>>
> >>> On Monday, August 31, 2026 at 4:34:50 PM UTC-7 Antoine Riard wrote:
> >>>
> >>> 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
> >>> <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+unsubscribe@googlegroups.com
> >>> <mailto:bitcoindev+unsubscribe@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>.
> >> --
> >> 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/c0ff85ab-2b8b-4aea-8a04-e0e8a6be7c94%40murch.one.
> >>
>
> --
> 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/70cc8e00-e4fd-46de-b9b4-27bc39bfcbe8%40murch.one.
>
--
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/tGemKORoxpaqKlU6SZ9gYoMAj3VVzWB7gDGr49qxd4gq1IACbTdUhJmf7T3gbrUmREluNMVVal12sftAeaRiJIAWKOH_1caL_Fit2gdVouo%3D%40proton.me.
[-- 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] 7+ messages in thread
end of thread, other threads:[~2026-09-19 2:47 UTC | newest]
Thread overview: 7+ 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
2026-09-04 16:07 ` 'conduition' via Bitcoin Development Mailing List
2026-09-11 22:54 ` Murch
2026-09-13 22:25 ` 'conduition' via Bitcoin Development Mailing List
2026-09-15 22:39 ` Murch
2026-09-19 2:07 ` 'conduition' via Bitcoin Development Mailing List
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox