From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 18 Sep 2026 19:47:19 -0700 Received: from mail-oo1-f61.google.com ([209.85.161.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 1x7l6k-0005kM-DK for bitcoindev@gnusha.org; Fri, 18 Sep 2026 19:47:19 -0700 Received: by mail-oo1-f61.google.com with SMTP id 006d021491bc7-6b1a3f01d2asf1818608eaf.1 for ; Fri, 18 Sep 2026 19:47:17 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1789786032; cv=pass; d=google.com; s=arc-20260327; b=Lg2YeJApKKBHjbTdWqQJM3h4sDMVSTS2+WaBZ6bqxnNthiflJ84MKOjzIJQd+eRiAl rGoBH8jSMt5MxPxkpLyhW5GBtsRzfY+APOioRu/OaO8fhfW1eHTK9mUtjj848M3P2R+B w702CSxmkXhPoMIMltcZPB4ecAHMuBDQVNd3Jz0/1ZrhFSxRo+yCPfFiBBNFyutM3iXw F80bDun+BkTOZVABD2Y4vlnEE3dcm9k6UHCTgSLccR551g21W3X1sbqDAvYcKN+Gho9L 4XEPoEYP55GmEJI+bZ2FhWm9rp4JNK1uFxUkzkwNMZ+UvsIpvtSPcOr+9PnlOm9sv/He DW/w== 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:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=dNY2TREx0UfUxYanBUQRpBHxlXHI5F81IK3XpW7nyKc=; fh=R3QEdDb0W58YDltFmsBZXs9+hbBvWoJCAKPp031VfcI=; b=HjzEOgAD9w2fDH5nKXJDtTEr8qwKldlTnzsJBMt2caQRdqoOpSu8FGG6zuzIcM5ogg Di2GhZ9Dr/BOFsplbNFGqf+bZzgJFSxDugIzih6aMQaI+wSY3e0XVu3rIbZH4gzi/cNc Y/tUQfjBZxZUFG53M5zqy/geX7MC3XfsobJUHn79g6EFScSs7B0ZmbN7vGyOBTT5EnZK PfQbI2Vev/TYZZRo3szFhLzp1S/CgAj7MSkU1YFiw6xBKEyokdpFCKMe/BRtJLNf08G4 N9Bb4hUmIWaAzjpMDBmfRKzdPyGvwtcYCGc/MTHoMyThSZJxzB/EVpNWYcYTzVqhy4em 9hBw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=uhtsl4cjfvfi7fkwgqd2fwc7ly.protonmail header.b=PxdKr8S1; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.101 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1789786032; x=1790390832; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:content-type :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=dNY2TREx0UfUxYanBUQRpBHxlXHI5F81IK3XpW7nyKc=; b=xopkIvtRXIPex5vv/jQtzkMslAuGFdAcAhGJPKI3tyXHdb/+MDKvr5sOr/qn672Etx 9Tt7p+Q3TYuRE3j10qDc/8aUdN1u2ep4JKpbhbSm1uG8a+F03AbcRhl5IUk1isSOFB8G ivDcnh4x3wX8gmv7Jnkon+YlMeEoqH8DT76yxR+UqdprmwNSNr7r5kbKVCEss0QHzL5G mZWDOkJV85qLJI8kKVopMf7bukHxaEgoIWIwbkUc/JB371ktHApD+vM4xFC4HjYp0zxR rOqssXkNX7vaGu77vIYSjyAgZjhpWZs8tvGvqdLxOXNbgCjjrcc7FUEF0yH4W9slggbK H6ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789786032; x=1790390832; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:content-type :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:x-beenthere:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=dNY2TREx0UfUxYanBUQRpBHxlXHI5F81IK3XpW7nyKc=; b=YMmNi0dxoCI0A8dZXhh3tffOOtiZwdpXcvzbG0j6XH4klfBcJIwcXzCD3wT8wfb+bI fhM8QJqja1Vy6ruC+YSCJe6o59azjqdt1w1MrycpMvi9vwh6MTw+eAnsEKDjEhlw1NpG DYewhSnJ2A8F0askeRWCIOZifWR8ykkFscqYPcAS7kcYe62tuG+qI8YP5bkLLOq1sTpB 0qkPYeSb1Yi3N7Sa6Q7OyE1AU+DZcWIt3CieOc/HjuxZAW1Wxy0lWQ7pI3gSREhRCgil rEGlOtmSgLFe0Wqeh/dxRp8g0a0ePjJCZhyBIR2QA8ytk2WXJj1FMbLMtfcsr1KD6+Da 8BlQ== X-Forwarded-Encrypted: i=2; AKwUvBykHD7oUZ5rswqDKdzjSx+EhDtObLmX47on1/ip8ItJHGr0AOznL5r9ZSOPBUg0jXTwRFnSNEWeq6U/@gnusha.org X-Gm-Message-State: AFuF++kNgeGGbbQio3Sjti0/DpwDdrgHuLD8dfHaNp/tKZVGkXaB7h9Y iNmPYD6tIVOwmvac1GvL2lCqT07bJMK6qAEPXkBQzT6oc2GMrpIfR5fD X-Received: by 2002:a05:6820:1ca3:b0:6c0:853f:7e6e with SMTP id 006d021491bc7-6ca9a1341b2mr4269268eaf.7.1789786031677; Fri, 18 Sep 2026 19:47:11 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLddCNd4rSTMB59DKrukej2uEHJH4AbnXKOYvLAL1Mo0JLA==" Received: by 2002:a05:6820:c2c8:10b0:6ae:98bc:10e0 with SMTP id 006d021491bc7-6c8f53c30dcls2751803eaf.2.-pod-prod-05-us; Fri, 18 Sep 2026 19:47:05 -0700 (PDT) X-Received: by 2002:a05:6808:1513:b0:4c3:ee9e:2001 with SMTP id 5614622812f47-4ccf53702cfmr4721119b6e.3.1789786025069; Fri, 18 Sep 2026 19:47:05 -0700 (PDT) Received: by 2002:a05:600c:a409:b0:49b:8c5c:cda1 with SMTP id 5b1f17b1804b1-49fcdc218dems5e9; Fri, 18 Sep 2026 19:07:25 -0700 (PDT) X-Received: by 2002:a05:600c:354e:b0:49e:6bc7:4e1b with SMTP id 5b1f17b1804b1-49fc56ef4fcmr53965205e9.15.1789783643876; Fri, 18 Sep 2026 19:07:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1789783643; cv=none; d=google.com; s=arc-20260327; b=n3UmEYr0SDoWflQYZ09pg+2H5BNxYpt8JLMAV9BESnD6H6sYPGVuLyi2TD4qNvHflV irdrAa1lutRK5ECcWn43NuuBJzpjHTIsh1bJtEvs/KXzvnQCbAAa9a/ephoZ/0pNG3yM TjepvfK8oH1l0bDKKmf+4ei2zQbIjQZxxKeoih2BL3DhkE0d7X4DtbTfhLUUpsK16IhW WVbdxuZp/76fPgtSOtPpsPpz1X5guUUUSv0NKbDzerdTWGNykX8t2/xorufYIXwUN3n3 g54jPwigxCnA8jR3qvftzNq8TrSXvubELaXPAMOLXq4WDGMjFNl8/vyuYLf1Gxvzu+jG AM/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=8d2koASpbO3/TNU7CRIsyMUNPnvoqF5dnyXB2dTd/ck=; fh=foaZ9w3C3c5ltuXRyLrsJcSZd5F+/L4e8AHpKYxjE8o=; b=hxaYc23IMM1TzdZUlmGJZPr4b748ESIKiMFLZELL8pxdJosjwgreZg3cuAzOgPUfsc S/jHeizDVL/Pcl8SJOcbIwpE3ttW8MUcofBekGAZeLELoiWF/jF7mvS8eOttp6W0sHwH 5wSnouxmGSam3raKN1Wul4XOlrXgSNxxKBRkG5riW00tGEMtMKFS+iJdh6Zj4kAwbSqu RU3pbRT/DS93aDovdX3J46ciMQLbdxo1YDCSNXKump5BAanUBaE5zcjqk1vAuhg4CIv/ Na63adAV6ZfZwbdSh9c2wsK51qG7LmoUVk82A4cqkHKxqb4WorAo7AQqRU6tcC76/Ko3 zDmQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=uhtsl4cjfvfi7fkwgqd2fwc7ly.protonmail header.b=PxdKr8S1; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.101 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-106101.protonmail.ch (mail-106101.protonmail.ch. [79.135.106.101]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-49fc5a0ae74si378925e9.0.2026.09.18.19.07.23 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 19:07:23 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 79.135.106.101 as permitted sender) client-ip=79.135.106.101; Date: Sat, 19 Sep 2026 02:07:18 +0000 To: Murch From: "'conduition' via Bitcoin Development Mailing List" Cc: bitcoindev@googlegroups.com Subject: Re: [bitcoindev] Re: SHRINCS: an efficient hash-based signature scheme for Bitcoin (first draft) Message-ID: In-Reply-To: <70cc8e00-e4fd-46de-b9b4-27bc39bfcbe8@murch.one> References: <-w8D4WbD7zY2bfYQIES40iBZQWbZx6ab-S6EW8tWsMEFaHO9NEOLUkte_MZZgNQDd0pljCM2wD1Ccnk3BfjwLPgCiVz-NfTwjHJ4aZHUqUw=@proton.me> <2fb38fb8-2584-4550-b268-ee7138de419bn@googlegroups.com> <70cc8e00-e4fd-46de-b9b4-27bc39bfcbe8@murch.one> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 89b26ffafe84c58e6c955a9972dec25ffb096d94 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------b8af7243fa500517463b194fa210e90467ba4ae448942030854cc5e7934d3e25"; charset=utf-8 X-Original-Sender: conduition@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=uhtsl4cjfvfi7fkwgqd2fwc7ly.protonmail header.b=PxdKr8S1; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.101 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=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 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------b8af7243fa500517463b194fa210e90467ba4ae448942030854cc5e7934d3e25 Content-Type: multipart/mixed;boundary=---------------------3d8d6e4f6b4b60c41e82dd16dd41adc9 -----------------------3d8d6e4f6b4b60c41e82dd16dd41adc9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hey Murch, That's great news for us if GFMD is acceptable. I have made a note in the a= ppropriate issue: https://github.com/SHRINCS/shrincs-bip/issues/21 Before we submit a PR though, we would still like some time to review publi= c 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 wrote: > Hey Conduition, >=20 > 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=E2=80=99s the only reason you=E2=80=99re eyeing a t= ranslation to a > different format, please feel free to submit the Markdown instead. >=20 > Cheers, > Murch >=20 > 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 re= commends that proposals stick to the basic Markdown syntax features commonl= y shared across Markdown dialects. > > At the moment we're using features of github flavored markdown in a num= ber of places. > > > > regards, > > conduition > > > > On Friday, September 11th, 2026 at 5:57 PM, Murch wro= te: > > > >> Hi Conduition et al, > >> > >> I=E2=80=99m excited that your draft has progressed this far. Please fe= el free to > >> open a PR to the BIPs repository whenever you=E2=80=99re ready to do s= o. 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 > >> =E2=80=9COutline=E2=80=9D 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 BI= P > >>> 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 B= IP > >>> 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 =3D *840 WU* > >>> - P2MR + SHRINCS (stateless): 178 non-witness bytes + 5857 x 2 witnes= s > >>> 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 beca= use > >>> 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 P= Q > >>> 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=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. > >>> > >>> 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 =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 anno= unce > >>> a first draft of a cryptographic BIP that fully specifies > >>> SHRINCS: A semi-stateful hash-based signature scheme for Bit= coin. > >>> > >>> 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. Statefu= l > >>> signatures are 548 bytes at the smallest, with a statele= ss > >>> 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 th= an > >>> 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 sha= pe > >>> and size of their stateful keypair to best suit their us= e- > >>> 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 int= o > >>> 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 com= ponent. > >>> > >>> > >>> Drawbacks > >>> > >>> SHRINCS has drawbacks: > >>> > >>> * The efficient stateful component requires software that = can > >>> manage an incrementing state counter (essentially the nu= mber > >>> of signatures issued) for each keypair. If wallet softwa= re > >>> accidentally reuses the same state counter on two distin= ct > >>> 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 techniqu= es. > >>> * SHRINCS lacks any algebraic structure allowing for publi= c > >>> 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 Kudin= ov > >>> inthis Delving thread >>> byte-stateful-post-quantum-signatures-with-static- > >>> backups/2158> and intheir joint paper >>> eprint.iacr.org/2025/2203.pdf>referenced therein. Also seeth= is > >>> related mailing list thread >>> bitcoindev/c/gOfL5ag_bDU/>. > >>> > >>> Notable changes since the original proposals 8+ months ago i= nclude: > >>> > >>> * *Black-box compatibility with SLH-DSA (FIPS-205) > >>> algorithms*. This encourages interoperability with non- > >>> Bitcoin systems, and leans into established security pro= ofs. > >>> * *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 wh= ich > >>> offer much faster performance (at the cost of larger > >>> signatures) compared to the original proposal. > >>> > >>> > >>> Status > >>> > >>> This initial draft specification contains only the cryptogra= phy > >>> 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 deplo= y > >>> SHRINCS without introducing at least one new output type, wh= ich > >>> we do not define in this BIP. > >>> > >>> The draft BIP-SHRINCS is not ready to be submitted to the BI= Ps > >>> repository yet. We still have much work to do. Notably absen= t > >>> 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 clari= ty, > >>> 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 se= mi- > >>> stateful signing scheme. > >>> > >>> We note that SHRINCS' parameters offer a complex multi- > >>> dimensional trade-off space between performance and signatur= e > >>> size. The choice of parameter set therefore seems ripe for > >>> bikeshedding. We provide a forum for parameter set discussio= n > >>> here , but= we > >>> encourage prospective cyclists to first read the relevant > >>> sections of thedesign rationale >>> shrincs-bip/blob/main/SHRINCS.md#rationale>, and invite read= ers > >>> to also play with our interactive stateless >>> blockstreamresearch.github.io/SPHINCS-Parameters/site/ > >>> stateless.html> and stateful >>> 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=3DNpfyTRB88-sUxtlh >>> si=3DNpfyTRB88-sUxtlh> > >>> > >>> Related Work > >>> > >>> We are building libshrincs >>> libshrincs>, an attempt at a formally verified C implementat= ion. > >>> 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 >>> vst.cs.princeton.edu/>), and forging costs breaking truncate= d > >>> SHA256 (SSProve ). Still= a > >>> prototype, more detail on Delving >>> libshrincs-a-c-implementation-with-a-machine-checked-securit= y- > >>> 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, sen= d > >>> 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 > >>> >>> ee7138de419bn%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfoot= er>. > >> -- > >> You received this message because you are subscribed to the Google Gro= ups "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/bitcoi= ndev/c0ff85ab-2b8b-4aea-8a04-e0e8a6be7c94%40murch.one. > >> >=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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/70cc8e00-e4fd-46de-b9b4-27bc39bfcbe8%40murch.one. >=20 --=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/= tGemKORoxpaqKlU6SZ9gYoMAj3VVzWB7gDGr49qxd4gq1IACbTdUhJmf7T3gbrUmREluNMVVal1= 2sftAeaRiJIAWKOH_1caL_Fit2gdVouo%3D%40proton.me. -----------------------3d8d6e4f6b4b60c41e82dd16dd41adc9 Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3 Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag UFVCTElDIEtFWSBCTE9DSy0tLS0tCg== -----------------------3d8d6e4f6b4b60c41e82dd16dd41adc9-- --------b8af7243fa500517463b194fa210e90467ba4ae448942030854cc5e7934d3e25 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0Fgmqt7kcJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmeT7Lgql91Zyn3rRwD65w5r30CWFluRTUlalvOm ocVcJxYhBEdIka0CMtrLdg13a3gpbO2E9rPFAADZXgEAjDZh7IYbxEWMCL2o WTtamGPvizGHY3kW8CDmouWfRZYBAICtZB49ytVu4Fuklekw4fjNgv5ZeDL6 U3zqqz2l+bEK =8Y9z -----END PGP SIGNATURE----- --------b8af7243fa500517463b194fa210e90467ba4ae448942030854cc5e7934d3e25--