From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 31 Aug 2026 16:34:57 -0700 Received: from mail-oa1-f61.google.com ([209.85.160.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1x1BWi-0002cx-9V for bitcoindev@gnusha.org; Mon, 31 Aug 2026 16:34:57 -0700 Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-46524220c5asf330008fac.0 for ; Mon, 31 Aug 2026 16:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1788219290; x=1788824090; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :sender:from:to:cc:subject:date:message-id:reply-to:content-type; bh=FlXFJCGzM8pciW5n7RGUnpxzl8NJuZKKlqyktxj6lfU=; b=XZn328yY+mv4ZBfFSPkB/OWCrrss2JqpurncNf5oXY6PhZXFErXn+jEsvBRFQNkLRs 6GHoVCd9ZlpFi4OUVwwrppvno50ByjkedyHGykXluVsG5m3LuGz5oksddhuauzLnJWLS UHeV9scYqgsZsDYVT8pqF0OmMUFkNMgfqlJ619P+O7+Cw7NrScJifR1QmBZStqRCq/6b bCyRUIOYWlo7Z9lq7LSpEf9gOvF5gsOSnXZ3O5oUJwcnMaKuzTH6pkm9tmAj4iKy229Z pER/kIIAdsEsP1KHVlm3QTarTPWErgzOxHU2nMscrm7aXByXG1Uxktq6lQpFLAN0wjRm wbBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788219290; x=1788824090; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to:content-type; bh=FlXFJCGzM8pciW5n7RGUnpxzl8NJuZKKlqyktxj6lfU=; b=VbfGrxiZs4lqI/gKDX3Q53+H5P8leSzO6gv67C6tytw5F//pyXCTJFXqCNBT/csaqA WK5O20c0iONfmMKleioWZ5nACGHk7LP1/bfG2bMCzTHNPG2pSKfa/Fj59RoKdrAhrt9k uwAyDSwxpc7dR5j7tuT8fbtywbUFIbsyg5TKUH+gFna9QLk3Aj97vpiWgwcBSCMrTwWt hzlOgj4OCx52NIXwhvKJwUIz4NOGonjM6KC/ertTvNbwI8VmwKM+5VRryc47Qel+Mbgq 99f8lnoZUg87++eSCmr9YVUKNLO7hcgcRNlS7fp3Tm647Ddu+QCRru2Hs54D1WzrDhS2 vZOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788219290; x=1788824090; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to:content-type; bh=FlXFJCGzM8pciW5n7RGUnpxzl8NJuZKKlqyktxj6lfU=; b=fA+t4jqGaCkuxic342Okc/Qz2JKrYynGKerzh3Cns0dG1kuGDDx+rsfv3UwR1W9U6n CoLMnxBslWEF5CuReFTc5+I1UG7Dc5GJ+BP4V0SFUwj0LZ7bA6kJ3/9yA3ZoQMeW/iBD shwVqzP7DFLggWBoy/B9PCDa+Nqj/lLUTwHJxTzjaobGFpvJK0oV3nDqbLVXlx1zxS9w X+d7LaBgCeLugyTGSlmay2SJgMzxhPlYp1U4jnP0R/Vbzmrexw692OzyzqE4qFnM0eC3 7xRiidQ/yTXG75j6heBugaqWkqt7MVj+o8E6Ug3UzSYD6FAKzWsKuN89IYLuqPvtXV3A Dung== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AKwUvBz3s34Alz4gA7Rq/dDyBcLb7huJXZvVi+jxdQbd3Dqwqq9Vm18SGdhRHheDiNuOdl3aPJzU4VAp+sDN@gnusha.org X-Gm-Message-State: AFuF++l9J3UhkuVmhyNEa3ZDNWUVDrviwh5xPIv4JKREWu+Mppwy5yB/ nkSr+aUHAd27Vuq0ZgsM5MzDSyzWlpfRh8bs1ahJ4AlY5Hgn0y4JA8sT X-Received: by 2002:a05:6871:3842:b0:46a:e05f:93b3 with SMTP id 586e51a60fabf-46ae05f94bcmr8827940fac.5.1788219290027; Mon, 31 Aug 2026 16:34:50 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdf8tuNPgXE+4XqSiQ/oK4UN5sEyGwj5DGl8QAfZCRpw4w==" Received: by 2002:a05:687c:41ce:10b0:456:775f:719f with SMTP id 586e51a60fabf-4670ff8b442ls3592081fac.0.-pod-prod-08-us; Mon, 31 Aug 2026 16:34:45 -0700 (PDT) X-Received: by 2002:a05:6808:1b8b:b0:4b2:e95f:380d with SMTP id 5614622812f47-4b397f9a39dmr32566137b6e.6.1788219284905; Mon, 31 Aug 2026 16:34:44 -0700 (PDT) Received: by 2002:a05:690c:e919:b0:84a:c43b:38df with SMTP id 00721157ae682-86079c6f0e9ms7b3; Mon, 31 Aug 2026 16:23:57 -0700 (PDT) X-Received: by 2002:a05:690c:6c12:b0:81e:76f0:dbce with SMTP id 00721157ae682-85d6e438c0dmr106679467b3.26.1788218636921; Mon, 31 Aug 2026 16:23:56 -0700 (PDT) Date: Mon, 31 Aug 2026 16:23:56 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <-w8D4WbD7zY2bfYQIES40iBZQWbZx6ab-S6EW8tWsMEFaHO9NEOLUkte_MZZgNQDd0pljCM2wD1Ccnk3BfjwLPgCiVz-NfTwjHJ4aZHUqUw=@proton.me> References: <-w8D4WbD7zY2bfYQIES40iBZQWbZx6ab-S6EW8tWsMEFaHO9NEOLUkte_MZZgNQDd0pljCM2wD1Ccnk3BfjwLPgCiVz-NfTwjHJ4aZHUqUw=@proton.me> Subject: [bitcoindev] Re: SHRINCS: an efficient hash-based signature scheme for Bitcoin (first draft) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_136388_727608311.1788218636447" X-Original-Sender: antoine.riard@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_136388_727608311.1788218636447 Content-Type: multipart/alternative; boundary="----=_Part_136389_1372834528.1788218636447" ------=_Part_136389_1372834528.1788218636447 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.=20 By the way, there is no table of content in your document. Thanks for the work overall, it's very interesting. Best, Antoine=20 OTS hash: 53902c7451df74e4046766d6df268b6aaae2916f1b3c6792880659e3efe56777 Le Wednesday, August 26, 2026 =C3=A0 10:38:01=E2=80=AFPM UTC+1, conduition = a =C3=A9crit : > Hi everyone, it's me again. > > On behalf of the SHRINCS Working Group, I am excited to announce a first= =20 > draft of a cryptographic BIP that fully specifies SHRINCS: A semi-statefu= l=20 > 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,= =20 > still in need of peer review. Formal security proofs are WIP.* > Features > > SHRINCS offers: > > > - *Compactness*. SHRINCS public keys are 48 bytes. Stateful signatures= =20 > are 548 bytes at the smallest, with a stateless fallback component bui= lt=20 > into every key pair by default that produces larger 5777-byte signatur= es. > - *NIST-I security (~128-bit classical and ~64-bit post-quantum)*.=20 > SHRINCS' security depends only on properties of the (truncated) SHA256= hash=20 > function which are believed to be post-quantum-secure. > - *Fast verification performance*. Amortized on a per-byte basis,=20 > SHRINCS signatures are 4x-16x faster to verify than BIP340 Schnorr=20 > depending on whether SHA256 hardware acceleration is available. At wor= st,=20 > verification costs 2792 SHA256 compressions with a 5777 byte stateless= =20 > signature. > - *Flexibility*. SHRINCS allows signers to control the shape and size= =20 > of their stateful keypair to best suit their use-case, while SHRINCS'= =20 > stateful verifier is agnostic to signer-side choices and contains only= a=20 > single code path to be scrutinized and optimized. > - *Good incentives*. SHRINCS with UXMSS provides the most compact=20 > signatures possible within the scheme, and the signatures grow as a ke= y is=20 > reused. If SHRINCS comes into common use, users will be economically= =20 > incentivized not to reuse addresses. Address reuse would still be poss= ible,=20 > either via stateful BXMSS keys, or via the stateless component. > > > Drawbacks > > SHRINCS has drawbacks: > > > - The efficient stateful component requires software that can manage= =20 > an incrementing state counter (essentially the number of signatures is= sued)=20 > for each keypair. If wallet software accidentally reuses the same stat= e=20 > counter on two distinct signatures under a key, any adversary who obse= rved=20 > both signatures can forge a new one. > - The key generation and signing algorithms are computationally=20 > expensive - Though this can be mitigated using SIMD, parallism, or har= dware=20 > acceleration techniques. > - SHRINCS lacks any algebraic structure allowing for public key=20 > rerandomization (to admit BIP32-style xpubs), multisignature schemes (= like=20 > MuSig), etc, in contrast to feature-rich cryptosystems like Schnorr. > > > Changes > > This new specification is the evolution and formalization of ideas=20 > originally put forward by Jonas Nick and Mikhail Kudinov in this Delving= =20 > thread=20 > and=20 > in their joint paper referenced= =20 > therein. Also see this related mailing list thread=20 > . > > Notable changes since the original proposals 8+ months ago include: > > > - *Black-box compatibility with SLH-DSA (FIPS-205) algorithms*. This= =20 > encourages interoperability with non-Bitcoin systems, and leans into= =20 > established security proofs. > - *Flexible XMSS (FXMSS)*. Prior descriptions of SHRINCS implied only= =20 > unbalanced stateful trees were allowed. We now allow stateful trees of= any=20 > structure. > - *New parameter sets*. The stateless component now uses a parameter= =20 > set allowing at most 2^40 stateless signatures, rather than 2^20. This= =20 > allows SHRINCS to be useful for protocols that require high-frequency= =20 > signing, such as Lightning. The stateful component now uses parameters= =20 > which offer much faster performance (at the cost of larger signatures)= =20 > compared to the original proposal. > > > Status > > This initial draft specification contains only the cryptography of the=20 > SHRINCS scheme, decoupled from consensus validation rules. Further BIPs= =20 > would be required to deploy the SHRINCS signature scheme on Bitcoin.=20 > Notably, we cannot safely deploy SHRINCS without introducing at least one= =20 > 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= =20 > 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,=20 > cryptography, and reference code, primarily for security, correctness,=20 > compatibility, consistency, and clarity, in that order. Insightful review= s=20 > will be highly appreciated and met with positive vibes and beers at the= =20 > next conference :) > > We also hope that seeing a concrete specification will spur further=20 > discussion of related problems, such as how PQ HD wallets will work, and= =20 > how to handle user experience of a semi-stateful signing scheme. > > We note that SHRINCS' parameters offer a complex multi-dimensional=20 > trade-off space between performance and signature size. The choice of=20 > parameter set therefore seems ripe for bikeshedding. We provide a forum= =20 > for parameter set discussion here=20 > , but we encourage=20 > prospective cyclists to first read the relevant sections of the design=20 > rationale=20 > ,= =20 > and invite readers to also play with our interactive stateless=20 > =20 > and stateful=20 > =20 > parameter set exploration tools. > > Those who prefer video format may be interested in this interview=20 > discussing the internals of SHRINCS:=20 > https://youtu.be/n-jGPICZMR0?si=3DNpfyTRB88-sUxtlh > > Related Work > > We are building libshrincs , an= =20 > attempt at a formally verified C implementation. One machine-checked Rocq= =20 > theorem covers WOTS+C, the one-time signature= =20 > in FXMSS: honest signatures verify, the linked C implements its four publ= ic=20 > contracts under CompCert's semantics (VST = ),=20 > and forging costs breaking truncated SHA256 (SSProve=20 > ). Still a prototype, more detail on= =20 > Delving=20 > > . > > Acknowledgements > > The SHRINCS specification is the result of several months' collaboration= =20 > between contributors across multiple organizations. The SHRINCS Working= =20 > 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 > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= b4bb949d-bd35-424d-a1d1-459e6cca263an%40googlegroups.com. ------=_Part_136389_1372834528.1788218636447 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Conduition,

From a first read of the document, there is no= thing so far
on the signature mode of accounting. If we go for an usag= e
of stateless for off-chain second-stage txn, be it lightning,
v= ault, 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
rese= rves 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 di= scount 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 overa= ll, it's very interesting.

Best,
Antoine
OTS hash: 53= 902c7451df74e4046766d6df268b6aaae2916f1b3c6792880659e3efe56777

<= /div>
Le W= ednesday, August 26, 2026 =C3=A0 10:38:01=E2=80=AFPM UTC+1, conduition a = =C3=A9crit=C2=A0:
Hi everyone= , it's me again.

On behalf of the SHRINCS Working Group, I am excited to announce a first dr= aft of a cryptographic BIP that fully specifies SHRINCS: A semi-stateful ha= sh-based signature scheme for Bitcoin.

https://github.com/SHRIN= CS/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:
<= div style=3D"font-family:Arial,sans-serif;font-size:14px">
  • Compactness. SHRINCS public keys are 48 bytes= . Stateful signatures are 548 bytes at the smallest, with a stateless fallb= ack component built into every key pair by default that produces larger 577= 7-byte signatures.
  • NIST-I security (~128-bit classical and ~64-bit post-quantum)= . SHRINCS' security depends only on properties of the (truncated) SHA25= 6 hash function which are believed to be post-quantum-secure.
  • Fast verification performance. A= mortized on a per-byte basis, SHRINCS signatures are 4x-16x faster to verif= y than BIP340 Schnorr depending on whether SHA256 hardware acceleration is = available. At worst, verification costs 2792 SHA256 compressions with a 577= 7 byte stateless signature.
  • Good incentives. SHRINCS with UXMSS provides th= e most compact signatures possible within the scheme, and the signatures gr= ow as a key is reused. If SHRINCS comes into common use, users will be econ= omically 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 mana= ge an incrementing state counter (essentially the number of signatures issu= ed) 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 computatio= nally expensive - Though this can be mitigated using SIMD, parallism, or ha= rdware acceleration techniques.
  • SHRINCS lacks any algebraic structure allowing for public key rerando= mization (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 formaliz= ation of ideas originally put forward by Jonas Nick and Mikhail Kudinov in<= span>=C2=A0this Delving thread=C2=A0and= in=C2=A0their= joint paper=C2=A0referenced therein. Also see=C2=A0this related mailing list thread.

Notable changes since the original proposals 8+ mon= ths ago include:

=
  • Black-box compatibility with SLH-DSA (FIPS-205) a= lgorithms. This encourages interoperability with non-Bitcoin systems, a= nd leans into established security proofs.
  • Flexible XMSS (FXMSS). Prior descr= iptions of SHRINCS implied only unbalanced stateful trees were allowed. We = now allow stateful trees of any structure.
  • New parameter sets. The stateless com= ponent now uses a parameter set allowing at most 2^40 stateless signatures,= rather than 2^20. This allows SHRINCS to be useful for=C2=A0protocols that= require high-frequency signing, such as Lightning. The stateful component = now uses parameters which offer much faster performance (at the cost of lar= ger signatures) compared to the original proposal.

Status

This initial draft specification contains on= ly the cryptography of the SHRINCS scheme, decoupled from consensus validat= ion rules. Further BIPs would be required to deploy the SHRINCS signature s= cheme on Bitcoin. Notably, we cannot safely deploy SHRINCS without introduc= ing 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
  • M= ediawiki or Markdown format compliance

We are posting here to seek review of SHRINCS' design, parameters, = cryptography, and reference code, primarily for security, correctness, comp= atibility, consistency, and clarity, in that order. Insightful reviews will= be highly appreciated and met with positive vibes and beers at the next co= nference :)

We al= so hope that seeing a concrete specification will spur further discussion o= f 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=C2=A0multi-dimensi= onal trade-off space between performance and signature size. The cho= ice of parameter set therefore seems ripe for bikeshedding. We provide a forum for parameter set discussion here, but we enco= urage prospective cyclists to first=C2=A0read the relevant sections of the<= span>=C2=A0design rationale, and invite readers to also play= with=C2=A0our interactive stateless and stateful parameter set = exploration tools.

Those who prefer video format may be interested in this interview discussin= g the internals of SHRINCS:=C2=A0https://yo= utu.be/n-jGPICZMR0?si=3DNpfyTRB88-sUxtlh

Related Work=

=
We are bui= lding libshrincs, an attempt at a formally veri= fied C implementation. One machine-checked Rocq=C2=A0theorem covers WOTS+C, the o= ne-time signature in FXMSS: honest signatures verify, the linked C implemen= ts its four public contracts under CompCert's semantics (VST), and f= orging costs breaking truncated SHA256 (SSProve). S= till a prototype, more detail on Delving.

Acknowledgements

The SHRINCS specification is the result of several months' collaboratio= n between contributors across multiple organizations. The SHRINCS Working G= roup 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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/b4bb949d-bd35-424d-a1d1-459e6cca263an%40googlegroups.com.
------=_Part_136389_1372834528.1788218636447-- ------=_Part_136388_727608311.1788218636447--