From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 11 Sep 2026 15:57:57 -0700 Received: from mail-ot1-f64.google.com ([209.85.210.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1x5ABw-0003B8-QN for bitcoindev@gnusha.org; Fri, 11 Sep 2026 15:57:57 -0700 Received: by mail-ot1-f64.google.com with SMTP id 46e09a7af769-7f8931a803csf1258281a34.0 for ; Fri, 11 Sep 2026 15:57:56 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1789167470; cv=pass; d=google.com; s=arc-20260327; b=lI+1FzqoUNfJ9NK4x3Hsmhxnk/hhLPSOw6KZhR9K/XbF2G0qSycNv1avSvoNae6buU +qEkW3E84FzRsFM28Pet4f4sqF666gmzyjqHJMsKsCIcQvaiGQyBhs4NfnatdilO2Muk 5jx7ypexcq9CnUAT/aR5uqZWUk1E45P4fcO3kbheL5DDKaHbGhkZxQhu13l682sjwSvG r77VSH9VTsTFrS28dA5g7BqaBVMzEZ1ca9YpxoReKLCLTJrhoCN97CDNbgBem33nuzc1 EIZDnmLcrrAdvhNQDL0UNAeCO1OSLSaaUWrzZiMKJbfIK5ZDf49BXkASsOek9nS4K+sK fgiQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:content-transfer-encoding :in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:sender:dkim-signature; bh=VfydW8R1j1P2/dL8Pz/YHGvMsoHyY86MS9JLRviI92U=; fh=+iNTFt5paVgtB0M1bOtQItEGkjF+q4OsdLpGlPbpd/0=; b=Tpp+6ohLIJ+gworxRcslKbaiRfa8z4bnqVyPuhFv5+S4LTIgAskZw39ePDBnhg3o8n tX3RirH5zJrERM95Bsp6o5OVa0xPce6znd9wsOF+WcbpQL6/71giLdyFEY61vEqMy9jX BorSeyEjSWrCrtGFdeY6EG44a3LDwmV2YFR8eVsIamhhSePwY/dkNnRXDHX+m+R0TifR 2jx0TQ95Eun8HiSVolobkSnR//uJdCq+sksg4EGvUAtGe9YOTjzqdcoNXIFIHsxnrJxK UnwsTRklFenNAfKQ9GItXpqNK7n6kE8cT8OWkmVsiWVD5YBAAFVXi5nElwzhQP2DIpUo hetQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b=K8UDK9MR; spf=pass (google.com: domain of murch@murch.one designates 2a00:d0c0:200:0:1c7b:a6ff:fee0:8ea4 as permitted sender) smtp.mailfrom=murch@murch.one DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1789167470; x=1789772270; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:content-type :in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:sender:from:to:cc:subject:date :message-id:reply-to:content-type; bh=VfydW8R1j1P2/dL8Pz/YHGvMsoHyY86MS9JLRviI92U=; b=GBb61TR+l14Q/+iIW9SpoDI5G1ecfVNFyedB4sm9KG2HL3rUn5KNVStZvvUssAEmtF InQQc0zjq972OHNjQDPAUCc+ikWugac03cROp6XnNs4fUXRjNORUxVNzMWUyK2VZYtc1 WJGyWKtDKjU+s6il/Jf8Gixnwodm7ceIqRMDrJEpMdXnlSLmOtLetl2hz4Y2OtqypEum wUw+Hn/EN2MbWlFEDWfGaYu8aj5+tg8mcIxN+DWStXOqSbCNLq6n601fNsHNQKXx2j4y iynv+0fWXJy9BBto9zGgvLQgCmWaPAFxCngz3gKASLN8j91ew2uaiL6D+J/xNv7kekRk sx8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789167470; x=1789772270; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:content-type :in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:x-beenthere:x-gm-message-state:sender :from:to:cc:subject:date:message-id:reply-to:content-type; bh=VfydW8R1j1P2/dL8Pz/YHGvMsoHyY86MS9JLRviI92U=; b=ej13lJaReCxSJtdf6l9Adp93l+Kpmoex8c3QOdzdwhb9wFeXkQcpF9f2ML3X0nNcKw OwvNvI30NRDJNYdIflM941cgug+XeiUYhnQHtspkM4BuPqyqWUFmgbGxKzLQo1prG8m6 1znpETNJW5pREPWsz5qdLCYVm0VOufG45wlQtP8IFWaHBKG0eTYQK4d5Lu1DaS9PhSUR O7uBROkf03u4c20BaKcQP83D7b6ehiWrEwdogtNpPdgr5nFRDF8kozpNINknRS/Lw37i UKsIlqkebv8ihEHd3bgVV+qrCxX85We2hkCqW9biOOaKcuLexHRwANCq6SlvYAgkxRIS 6BFQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AKwUvBzsqO72c3W2GQ2NQOBxMSagdKy7ORO6DRqasdXUER1xsk5wlyz6VPm3FTOeb2vxiKf+otVBJButHlri@gnusha.org X-Gm-Message-State: AFuF++nlphb0EdZ/o9/DKKTcZf22EXeqjMbp7rTJfdaUF+oeGB/3bq6W cN1lHCjCzmnU6FjU1+tmhc9x6VHRRc0+FgFHp8MX+4DGDzH3AXp7Xi0B X-Received: by 2002:a05:6820:220a:b0:6b1:2843:1312 with SMTP id 006d021491bc7-6c249998bd3mr478827eaf.0.1789167470364; Fri, 11 Sep 2026 15:57:50 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdfIknboYn+BHQxOxui1gUCZyMNttbkb1s9z75MtP+fXQA==" Received: by 2002:a05:6871:a591:b0:456:6f58:d522 with SMTP id 586e51a60fabf-47c8763b876ls2886457fac.1.-pod-prod-04-us; Fri, 11 Sep 2026 15:57:44 -0700 (PDT) X-Received: by 2002:a05:6808:f08:b0:4b9:a88b:8884 with SMTP id 5614622812f47-4c4a9ccb0f3mr653300b6e.26.1789167463892; Fri, 11 Sep 2026 15:57:43 -0700 (PDT) Received: by 2002:a05:600c:4184:b0:49d:b96:9473 with SMTP id 5b1f17b1804b1-49e6201b128ms5e9; Fri, 11 Sep 2026 15:54:10 -0700 (PDT) X-Received: by 2002:a05:600c:19c9:b0:49e:6c9b:4e94 with SMTP id 5b1f17b1804b1-49e6cc11409mr2041145e9.28.1789167248427; Fri, 11 Sep 2026 15:54:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1789167248; cv=none; d=google.com; s=arc-20260327; b=OPLRhjoachdKAx477YDVxGn6AMOJSkuzaMk+Qp7iRrI6ExiWcy5zLuI5acz6SeLz3C 9cp21hlax80b25mvlmMo5kY3hz8eAIfQrVTq+glq5r6FxNbHB8xmiKGQruTmbvvCbqOZ jH8AmSdJzqjfLEKXIpz62TPJlBDQaED4rn7RADRTXmtbAvtzq591WYnUBysbb1slKCz8 gtPs5IHWFDPxfg9ZI+OBDbWSGb7fjLkoWE41Fq1+J70ERdY2/QTF6jvpfMYvCVkcBbcG MPAlwBEuP8OvG/goG4awqmEO4ZdKXycf2p38NrtORVEqKsA+ZuYz4/Jt3YIi7/Cty1eF 4/uQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=dkim-signature:content-transfer-encoding:in-reply-to:from :content-language:references:to:subject:user-agent:mime-version:date :message-id; bh=p496nXySziZiZxFUfshua/IMF+Rnn1LzNGA7nmFVTUU=; fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=; b=nLy3EJ+g9cUmp31a0lPY1FpQ5lVdOlrop1Ich7Xu3ZqabMIv+JgHtmqWIE3WQtMAd+ O3w5K4KJ467l6olkF1nR3T247qsdaqJXmNUnxm5I3WbddnhvCtN/OaFrUbfLJwqi0NYh /GQKyjrfm1/7shL26ighk+Dy6GLGZylfy64xkYnGjX+buMw/TbQb+el4GjrMNs9MTI+f l0meQDGb8ZwTitx1s8IgRSto/JRRXvp3xHK2RBBJSFKZ+gu8zHyLE11jqcJqu7hZLtIM 8lbC/H8T96tY6MsoeOdeGsW2G7n8BCCIlSvHiLXX2fUP7y+xUlyVIUvbIyTcwSzMH5AD TqWg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b=K8UDK9MR; spf=pass (google.com: domain of murch@murch.one designates 2a00:d0c0:200:0:1c7b:a6ff:fee0:8ea4 as permitted sender) smtp.mailfrom=murch@murch.one Received: from mailgate02.uberspace.is (mailgate02.uberspace.is. [2a00:d0c0:200:0:1c7b:a6ff:fee0:8ea4]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-49e6246d915si370675e9.4.2026.09.11.15.54.08 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Sep 2026 15:54:08 -0700 (PDT) Received-SPF: pass (google.com: domain of murch@murch.one designates 2a00:d0c0:200:0:1c7b:a6ff:fee0:8ea4 as permitted sender) client-ip=2a00:d0c0:200:0:1c7b:a6ff:fee0:8ea4; Received: from farbauti.uberspace.de (farbauti.uberspace.de [185.26.156.235]) by mailgate02.uberspace.is (Postfix) with ESMTPS id 0BAE0180B46 for ; Sat, 12 Sep 2026 00:54:08 +0200 (CEST) Received: (qmail 29781 invoked by uid 989); 11 Sep 2026 22:54:07 -0000 Received: from unknown (HELO unknown) (::1) by farbauti.uberspace.de (Haraka/3.1.1) with ESMTPSA; Sat, 12 Sep 2026 00:54:05 +0200 Message-ID: Date: Fri, 11 Sep 2026 15:54:02 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [bitcoindev] Re: SHRINCS: an efficient hash-based signature scheme for Bitcoin (first draft) To: bitcoindev@googlegroups.com References: <-w8D4WbD7zY2bfYQIES40iBZQWbZx6ab-S6EW8tWsMEFaHO9NEOLUkte_MZZgNQDd0pljCM2wD1Ccnk3BfjwLPgCiVz-NfTwjHJ4aZHUqUw=@proton.me> <2fb38fb8-2584-4550-b268-ee7138de419bn@googlegroups.com> Content-Language: en-US From: Murch In-Reply-To: <2fb38fb8-2584-4550-b268-ee7138de419bn@googlegroups.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Bar: --- X-Rspamd-Report: BAYES_HAM(-2.999993) XM_UA_NO_VERSION(0.01) MIME_GOOD(-0.1) X-Rspamd-Score: -3.089993 X-Original-Sender: murch@murch.one X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b=K8UDK9MR; spf=pass (google.com: domain of murch@murch.one designates 2a00:d0c0:200:0:1c7b:a6ff:fee0:8ea4 as permitted sender) smtp.mailfrom=murch@murch.one 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.8 (/) Hi Conduition et al, I=E2=80=99m excited that your draft has progressed this far. Please feel fr= ee to=20 open a PR to the BIPs repository whenever you=E2=80=99re ready to do so. Pl= ease=20 note that we accept submissions using either MediaWiki or Markdown, so a=20 conversion to MediaWiki format is not necessary. For either document=20 type, GitHub makes an outline/navigation available by clicking the=20 =E2=80=9COutline=E2=80=9D button at the right end of the bar above the docu= ment content. Cheers, Murch On 2026-09-04 09:07, 'conduition' via Bitcoin Development Mailing List=20 wrote: > Thanks for your reply Antoine. >=20 > You're correct that we do not specify cost accounting. The SHRINCS BIP=20 > is 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. >=20 > 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=20 > reserves all those protocols might have to keep >=20 > 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=20 > usage, even in the absence of a further witness discount. You have to=20 > account for 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* >=20 > Then you also need to account for the change in the fee market. If=20 > SHRINCS were in common usage with no block size increase or witness=20 > discount, it's reasonable to assume the fee market would inflate because= =20 > network throughput will have dropped. I can't conjecture on how high fee= =20 > rates might escalate in this scenario... I suppose it depends on how=20 > many people are able to use the stateful component, or if any other PQ=20 > signature algorithms are available at the time (such as Falcon/ML-DSA/=20 > SQIsign). >=20 > > By the way, there is no table of content in your document. >=20 > Thanks for the note, this will be populated automatically once we=20 > convert the document to mediawiki. >=20 > regards, > conduition >=20 > On Monday, August 31, 2026 at 4:34:50=E2=80=AFPM UTC-7 Antoine Riard wrot= e: >=20 > Hello Conduition, >=20 > 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... >=20 > 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. >=20 > Thanks for the work overall, it's very interesting. >=20 > Best, > Antoine > OTS hash: > 53902c7451df74e4046766d6df268b6aaae2916f1b3c6792880659e3efe56777 >=20 > Le Wednesday, August 26, 2026 =C3=A0 10:38:01=E2=80=AFPM UTC+1, condu= ition a =C3=A9crit=C2=A0: >=20 > Hi everyone, it's me again. >=20 > 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. >=20 > https://github.com/SHRINCS/shrincs-bip/blob/main/SHRINCS.md > >=20 > /Disclaimer: Do NOT use in production. SHRINCS is prototype > cryptography, still in need of peer review. Formal security > proofs are WIP. > / > Features >=20 > SHRINCS offers: >=20 > * *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 componen= t. >=20 >=20 > Drawbacks >=20 > SHRINCS has drawbacks: >=20 > * 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. >=20 >=20 > Changes >=20 > This new specification is the evolution and formalization of > ideas originally put forward by Jonas Nick and Mikhail Kudinov > inthis Delving thread byte-stateful-post-quantum-signatures-with-static- > backups/2158>=C2=A0and intheir joint paper eprint.iacr.org/2025/2203.pdf>referenced therein. Also seethis > related mailing list thread bitcoindev/c/gOfL5ag_bDU/>. >=20 > Notable changes since the original proposals 8+ months ago includ= e: >=20 > * *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=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 larger > signatures) compared to the original proposal. >=20 >=20 > Status >=20 > 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. >=20 > 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: >=20 > * Test vectors > * Unit tests >=20 > * A security proof >=20 > * An optimized implementation > * Mediawiki or Markdown format compliance >=20 >=20 > 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 :) >=20 > 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. >=20 > We note that SHRINCS' parameters offer a complex=C2=A0multi- > 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 thedesign rationale shrincs-bip/blob/main/SHRINCS.md#rationale>, and invite readers > to also play with=C2=A0our interactive stateless blockstreamresearch.github.io/SPHINCS-Parameters/site/ > stateless.html> and stateful blockstreamresearch.github.io/SPHINCS-Parameters/site/ > stateful.html> parameter set exploration tools. >=20 > Those who prefer video format may be interested in this > interview discussing the internals of SHRINCS: https://youtu.be/ > n-jGPICZMR0?si=3DNpfyTRB88-sUxtlh si=3DNpfyTRB88-sUxtlh> >=20 > Related Work >=20 > We are building libshrincs libshrincs>, an attempt at a formally verified 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 four public > contracts under CompCert's semantics (VST vst.cs.princeton.edu/>), and forging costs breaking truncated > SHA256 (SSProve ). Still a > prototype, more detail on Delving libshrincs-a-c-implementation-with-a-machine-checked-security- > proof/2795>. >=20 > Acknowledgements >=20 > The SHRINCS specification is the result of several months' > collaboration between contributors across multiple > organizations. The SHRINCS Working Group is, in alphabetical orde= r: >=20 > - Mike Casey (OpenChain) > - Conduition (Brink) > - Ethan Heilman (Cloudflare) > - Mikhail Kudinov (Blockstream) > - Oleksandr Kurbatov (Blockstream) > - Boris Nagaev (Independent) > - Jonas Nick (Blockstream) > - remix7531 (OpenSats) >=20 > // > regards, > conduition >=20 > --=20 > You received this message because you are subscribed to the Google=20 > Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send=20 > an email to bitcoindev+unsubscribe@googlegroups.com=20 > . > To view this discussion visit https://groups.google.com/d/msgid/=20 > bitcoindev/2fb38fb8-2584-4550-b268-ee7138de419bn%40googlegroups.com=20 > ee7138de419bn%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>. --=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/= c0ff85ab-2b8b-4aea-8a04-e0e8a6be7c94%40murch.one.