From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 04 Sep 2026 09:08:43 -0700 Received: from mail-oa1-f63.google.com ([209.85.160.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1x2WT3-0001su-Q8 for bitcoindev@gnusha.org; Fri, 04 Sep 2026 09:08:43 -0700 Received: by mail-oa1-f63.google.com with SMTP id 586e51a60fabf-458326d2d9asf1752571fac.2 for ; Fri, 04 Sep 2026 09:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1788538116; x=1789142916; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to: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=LEA9macDCXEhGGU+nWVYCuBxUBzeQJPlE0Y6EIBWnMc=; b=oBU4C2TWu+wU4SnTvbnEiNoxtIpmdH3WiDArTEgZjzjYvGuWBFPRKqYEAdTOs6Fjmp YG1SaxuMBZc0nNWqqYuPMDHAE45C+y0txgl8EuakR+GEzbRclsaHtuUpVn3PVuxSWZao gqwS7XfQ3PQWM/mXhsX6NwU3PlAi10oriQd6rCFlgkj+hprPfaJ/PZJP0ifRBa8qceuK PXBt+GObhIoAS4uix5xWBTSkvNoKoTprvPVBOlqrgntsiG29PPjW2o1CUsuMtWKAIbmB Cw6fSr15SEor+kHbdDBqDuUrtnqfTJTTQqCx50Am4/g3Jw6fiC2Rhj6jfub78t14YZsK LtGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788538116; x=1789142916; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :content-type:mime-version:subject:references:in-reply-to:message-id :to:from:date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=LEA9macDCXEhGGU+nWVYCuBxUBzeQJPlE0Y6EIBWnMc=; b=sOGvdN5P/yRneShZhKdTnds6AOPSGD8O07Gh4EYDwWZpG3tlY8GSJaTFO0r33E89Y9 n10ADrt1cjCMuMRW11COOp8f0vnF/ptk9bfh+UfNijEvAGTEPX2AYArR4RQDSpxdWRrA Sp1kYWVvXxvOuZ+kXY37kCkz9SH212sMxECPqGyCCV2PjXYQmpDlxQHHBeu7J4PfX9hd iQfK/ZhcqA4yKW28ZGSeq6nV4bRSsXZw0nmIiDq4FQCssRa3wSTqfdIRKdZP92tGLnKI WMb/mnBMyOd7+mTKgSYLNgW6dqhIG0V/1RMzOlhMxnGdnIJuG0UggCTJJjA2JI9ShCdu 0sEA== X-Forwarded-Encrypted: i=1; AKwUvBxBDyIqUpCrCTnJuHqPc9jcKqCv3dOTM5eHQQ/FJcmeZzkR3ZT7jrDFJY0QZDUxnAgaK0LV4cyYorUl@gnusha.org X-Gm-Message-State: AFuF++kxRbIjeLCyEI0CG8DlCZpa+qkrvNwzab0rRa279Hrq4pjI3ND2 STTNN87eVLT4nGXHZelbHYjCCX4sNn9neOADMh6e04zYyhCaL8Woi/dm X-Received: by 2002:a05:6871:80a:b0:456:b6b3:5b64 with SMTP id 586e51a60fabf-47550698087mr5659255fac.1.1788538115250; Fri, 04 Sep 2026 09:08:35 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLddc7Am/8nCfizABteCh+Vo1HXzgWjGM1qRmPH803Pr3eA==" Received: by 2002:a05:6871:89ce:10b0:456:ce3d:ba46 with SMTP id 586e51a60fabf-4753550e498ls1067986fac.0.-pod-prod-06-us; Fri, 04 Sep 2026 09:08:30 -0700 (PDT) X-Received: by 2002:a05:6808:221b:b0:493:a860:5809 with SMTP id 5614622812f47-4b95e5d0020mr5910199b6e.4.1788538109972; Fri, 04 Sep 2026 09:08:29 -0700 (PDT) Received: by 2002:a05:690c:950e:b0:84a:c43b:38df with SMTP id 00721157ae682-86fdb56cfcbms7b3; Fri, 4 Sep 2026 09:07:12 -0700 (PDT) X-Received: by 2002:a05:690c:88:b0:864:6f4d:ef7f with SMTP id 00721157ae682-87121acbbc5mr40151027b3.7.1788538029674; Fri, 04 Sep 2026 09:07:09 -0700 (PDT) Date: Fri, 4 Sep 2026 09:07:09 -0700 (PDT) From: "'conduition' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: <2fb38fb8-2584-4550-b268-ee7138de419bn@googlegroups.com> In-Reply-To: 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_57576_2036021108.1788538029382" X-Original-Sender: conduition@proton.me X-Original-From: conduition Reply-To: conduition 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: -1.0 (-) ------=_Part_57576_2036021108.1788538029382 Content-Type: multipart/alternative; boundary="----=_Part_57577_155369470.1788538029382" ------=_Part_57577_155369470.1788538029382 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for your reply Antoine.=20 You're correct that we do not specify cost accounting. The SHRINCS BIP is= =20 currently purely cryptographic, and agnostic to how or where it is=20 deployed. The role is meant to be analogous to BIP340: Specifying the=20 signature scheme, key formats, and usage invariants, and nothing else. For SHRINCS to be used on Bitcoin, we would also need an additional BIP=20 that deploys SHRINCS into consensus somehow, and that BIP would need to=20 handle size/compute cost accounting.=20 > So it's a 90x-ish of the operational cost for the fee-bumping reserves=20 all those protocols might have to keep The stateless SHRINCS signature is 90x larger than Schnorr, but that=20 doesn't translate directly to a 90x fee cost increase in real-world usage,= =20 even in the absence of a further witness discount. You have to account for= =20 the transaction weight too.=20 Example: 2-input 2-ouput transaction: - P2TR + Schnorr: 178 non-witness bytes + 64 x 2 witness bytes. Total=20 weight: 178*4 + 128 =3D *840 WU* - P2MR + SHRINCS (stateless): 178 non-witness bytes + 5857 x 2 witness=20 bytes. Total weight: *12426 WU*. - Difference: ~*14.8x* Then you also need to account for the change in the fee market. If SHRINCS= =20 were in common usage with no block size increase or witness discount, it's= =20 reasonable to assume the fee market would inflate because network=20 throughput will have dropped. I can't conjecture on how high fee rates=20 might escalate in this scenario... I suppose it depends on how many people= =20 are able to use the stateful component, or if any other PQ signature=20 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= =20 the document to mediawiki. regards, conduition On Monday, August 31, 2026 at 4:34:50=E2=80=AFPM 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.=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: 53902c7451df74e4046766d6df268b6aaae2916f1b3c6792880659e3efe5677= 7 > > Le Wednesday, August 26, 2026 =C3=A0 10:38:01=E2=80=AFPM UTC+1, conduitio= n 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-statef= ul=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=20 >> signatures are 548 bytes at the smallest, with a stateless fallback= =20 >> component built into every key pair by default that produces larger= =20 >> 5777-byte signatures. >> - *NIST-I security (~128-bit classical and ~64-bit post-quantum)*.=20 >> SHRINCS' security depends only on properties of the (truncated) SHA25= 6 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 wo= rst,=20 >> verification costs 2792 SHA256 compressions with a 5777 byte stateles= s=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 onl= y 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 k= ey is=20 >> reused. If SHRINCS comes into common use, users will be economically= =20 >> incentivized not to reuse addresses. Address reuse would still be pos= sible,=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 i= ssued)=20 >> for each keypair. If wallet software accidentally reuses the same sta= te=20 >> counter on two distinct signatures under a key, any adversary who obs= erved=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 ha= rdware=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 o= f 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. Thi= s=20 >> allows SHRINCS to be useful for protocols that require high-frequency= =20 >> signing, such as Lightning. The stateful component now uses parameter= s=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 on= e=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 repositor= y=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 revie= ws=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 Roc= q=20 >> theorem covers WOTS+C, the one-time signature= =20 >> in FXMSS: honest signatures verify, the linked C implements its four pub= lic=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/= 2fb38fb8-2584-4550-b268-ee7138de419bn%40googlegroups.com. ------=_Part_57577_155369470.1788538029382 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for your reply Antoine.=C2=A0

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

For SHRI= NCS to be used on Bitcoin, we would also need an additional BIP that deploy= s SHRINCS into consensus somehow, and that BIP would need to handle size/co= mpute cost accounting.=C2=A0

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

The stateless SHRINCS signa= ture is 90x larger than Schnorr, but that doesn't translate directly to a 9= 0x 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.=C2=A0=

Example: 2-input 2-ouput transaction:
- P2TR + Schnorr: 178 non-witness bytes + 64 x 2 witness bytes. Total weig= ht: 178*4 + 128 =3D 840 WU
- P2MR + SHRINCS (stateless): 1= 78 non-witness bytes + 5857 x 2 witness bytes. Total weight: 12426 WU.
- Difference: ~14.8x

Then yo= u 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 reasona= ble 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 th= is 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 a= t 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.

rega= rds,
conduition

=
On Monday, August 31, 2026 at 4:34:5= 0=E2=80=AFPM UTC-7 Antoine Riard wrote:
Hello Conduition,

From a first read of th= e 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 i= t 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
w= e might still go for falcon or whatever, which is more compact,
or the o= ther way discount severely those fields, at the other
downside of increa= sing the DoS surface of validating nodes.

By the way, there is no t= able of content in your document.

Thanks for the work ov= erall, it's very interesting.

Best,
Antoine
OTS hash: 539= 02c7451df74e4046766d6df268b6aaae2916f1b3c6792880659e3efe56777

=
Le Wednes= day, August 26, 2026 =C3=A0 10:38:01=E2=80=AFPM UTC+1, conduition a =C3=A9c= rit=C2=A0:
Hi everyone, it's me a= gain.

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<= span>=C2=A0their join= t paper=C2=A0referenced therein. Also see=C2= =A0this related mailing list thread.

Notable changes since the original proposals 8+ months ago= include:
<= br>
  • Black-box compatibility with SLH-DSA (FIPS-205) algorith= ms. This encourages interoperability with non-Bitcoin systems, and lean= s into established security proofs.
  • Flexible XMSS (FXMSS). Prior descriptions= of SHRINCS implied only unbalanced stateful trees were allowed. We now all= ow 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=C2=A0protocols that requir= e high-frequency signing, such as Lightning. The stateful component now use= s parameters which offer much faster performance (at the cost of larger sig= natures) compared to the original proposal.

Status

This initial draft specification contains only the = cryptography of the SHRINCS scheme, decoupled from consensus validation rul= es. Further BIPs would be required to deploy the SHRINCS signature scheme o= n 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 t= o 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 encoura= ge prospective cyclists to first=C2=A0read the relevant sections of the=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://youtu.= be/n-jGPICZMR0?si=3DNpfyTRB88-sUxtlh

Related Work=

=
We are bui= lding libshrincs, an attempt at a formally verifie= d C implementation. One machine-checked Rocq=C2=A0theorem covers WOTS+C, the one-time = signature in FXMSS: honest signatures verify, the linked C implements its f= our 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' 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/2fb38fb8-2584-4550-b268-ee7138de419bn%40googlegroups.com.
------=_Part_57577_155369470.1788538029382-- ------=_Part_57576_2036021108.1788538029382--