From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 15 Sep 2026 16:12:27 -0700 Received: from mail-oa1-f56.google.com ([209.85.160.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1x6cKA-00015d-8g for bitcoindev@gnusha.org; Tue, 15 Sep 2026 16:12:27 -0700 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-46509ab0149sf6432468fac.2 for ; Tue, 15 Sep 2026 16:12:25 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1789513940; cv=pass; d=google.com; s=arc-20260327; b=K/pQ+tHuqpYZT0Ktxna9cAniOvCBxTtZrXkbLpM7m9jr7DUnAOQ5ni2tlZDLpcvW5I mKmfnDDH66093cPMEhYGdYNq2TI5bLjSr9MNvfMGCMpNKy3WwvrZkG/RfvvjkdvwYiUk zweHUbUej042TzZfBMgSpvWuTMTE74veJVPobCsVo7znlsZGqLAy+DPqmaA6kPTxOWBj tVlFiFiOL91SQj7TNpOfbJ3oJ1xs2gFanNoWE5HfaO1zhWXuOmfBNxnfBkYk4NUsJUVh 0HYVsNJd/m1YaG9j6p/o54yLlE3RHP7P0C11FHwnvijEQdVTLLGUyusPlsN8szBJWeHi ewfQ== 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=bARC86l0Tr1xhw/iexBY3NNpk9DHc6VeAFSJcMMpFiM=; fh=q3DgRcVe2jBsJL8O7+abEFtsJycnYxkTPy72OwM6y24=; b=MtLxpi+/pDh6pjyeit/xWpl06HFeRLjeGxVFgjJHNQdc9j4Wgb8eSpH+Q/RKA0xzF4 yOb77T5lTTur0cfxIgNz3BokQxcaKO6Gn2bMaT3RWn10DTspopVvBFS2QIMXfMURKNbl oUOAH1RELK9XcaqTevjX2t4eBxTMiFUlFCrTTXCU5CToMVyEPUQRMkouFPMNMJPU1E3t OIEW4//aGwHeokcQXm4JKzxipQYYfWeZibBxOMiT/41Ib5WkW3VUh1uUev2baxh9CPFg DJTA2j3KpNGjLFiZxTVS+rWtZWW4cjqBdqcFhzfJxA+oKvDbJfosl2yErj99J7NMNXqV GUxg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b=TMfVH+Xv; 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=1789513940; x=1790118740; 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=bARC86l0Tr1xhw/iexBY3NNpk9DHc6VeAFSJcMMpFiM=; b=Rnbbm/CaO3HHhVbWCxmzaC8MU3Nt9CESfOvknU0u7S5LTGmIGnS8Y+67hQ3uuMuuJ6 g+2lI6JM7ZjqrTq4hyO3vbZYlr6AvnJ2kKi6Sps0/n5MGLv5LxDUKoey2O1gvBZhh3cr rpWX3qAlEZ9V/EolgCR1wuPWlPKvc4X4bOv8Wv6fqbyL4Ds40dBOg2Y4zqLdldvudsY6 0uGWNb3cTy3QDzPRWfwfUquKG2ZKZyqMizbE/DbBIf2EVkaLzIC5v1HBZFYalUSRkg6+ Q+GNrSjclRFSIkxvWOGoa8frnDBvm9eFaGEo9F0xXYctdRCk0A1UFQkSIl1jq/BcAGZy O8Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789513940; x=1790118740; 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=bARC86l0Tr1xhw/iexBY3NNpk9DHc6VeAFSJcMMpFiM=; b=MlUYh7lKWOQ20NiqZBZMVo6OnEV9AK3zfxwPKkc66UhuuDyYQ5XIWWktH9UTrkxM/j ftYvNLSYfGDiI2WTZhqhPI62qs0j88AHL9Jp57h6g2M69WUQtjC1oWt3uWZndck3JvnD XgNUY4pMhiI61lq7qzM5BbLklVB2hTWHowHdqVa3zlsAQ9tGusJc/yfhY2VfPqvGOVPJ myjLp8GVWCLEzlTCXfyEqgqSmycJfd9dk0DfwJX0rex0V1qprDYRtVS8chb/xpB2nDIP gwrva2oAAaYlHP3zs27ID+pqk7rFC6JDfCAxXgavWs6+/m7ex99gCapX3REs1dKYLu/Y F+gg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AKwUvBwA/y33g2E1jYTSrwEYcMbmpBGI6RFvZRBH+op1Er7gZFTsU/D7j8/YYfVjRqXRNVplG9ASpyC3L9mA@gnusha.org X-Gm-Message-State: AFuF++nHjw1WMoNnXkmdcWby+l4/u+DN5tOT7oZLUXzeSZiiDdtH1QIt ZShEBf4DboLu2/ar3Vy84NKqC3/3jOvWNChobMs48HkEkgUzmxvcCxBw X-Received: by 2002:a05:6871:2e97:b0:47a:cc3d:ae09 with SMTP id 586e51a60fabf-48475e891cfmr286737fac.14.1789513939618; Tue, 15 Sep 2026 16:12:19 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdde6crCir/eAB21IW6h2m7nwJbR4iapjavTAilGmuVa3Q==" Received: by 2002:a05:6871:341f:b0:479:bbe:a714 with SMTP id 586e51a60fabf-47c8255eecbls6505504fac.0.-pod-prod-08-us; Tue, 15 Sep 2026 16:12:13 -0700 (PDT) X-Received: by 2002:a05:6808:470c:b0:4b9:e65b:8c39 with SMTP id 5614622812f47-4ca4cf01204mr481541b6e.39.1789513932932; Tue, 15 Sep 2026 16:12:12 -0700 (PDT) Received: by 2002:a05:600c:16d3:b0:49e:84ca:940e with SMTP id 5b1f17b1804b1-49e84ca972fms5e9; Tue, 15 Sep 2026 15:39:46 -0700 (PDT) X-Received: by 2002:a05:600c:3b0a:b0:49e:663c:c69f with SMTP id 5b1f17b1804b1-49eb73374b0mr1551285e9.15.1789511984510; Tue, 15 Sep 2026 15:39:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1789511984; cv=none; d=google.com; s=arc-20260327; b=s+NXNYFKnXJWfMSSEZA7V9HEKFR7TSRiX+3xJEhw/jSNZRZw1+qTdSOY6XxkH+CeJj 6OWxtOG0NnsbzfTIgaCa+jxNmOa9wiCyMU50GrwVJkNhqHs81r3VxShsX50/8I/OcnXK 1cskuEN4cuAtjt6SDbW56OgtdvM1D2j4GsQjV2y/7zDEoRJ273f6v0LkJegk9+dxpARU JEzIikwJ+nUfpRJydWi9wKnRYUzPSak72QFI++gzoFfduesHy1shFlx41u3rgSZTxZG8 LItqc/i+vOs8qfVp4Sk4U7cNinPG+0fuSVhMby7kNHtumS5JmOgITSG0nN/QDG+VT8bj zecQ== 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=QsH0IE9RYHItXaji2I8sdazzFqFSC3zUmmHGFrKhvG0=; fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=; b=Kc/8gIEZosxdqOckXVNB1gCrF/iaDuh5QiI7XCuMLjCY3bME32UBcK5h/JM3CF/UA1 IAI3ucj+z62dqq9e46JclR4kNNXmqwh5xl1lp2Sa6LfvAcJZGeSdGkxmHxxbpp+aHucl WxWI1TeLADo4NMcylLM4Uq+SDXKZOM7jXbiDU1ffaqQcLGuC17lhA0sdwoouCes3sG5h F9/MTvio0q7MLkVhqayt5CAkX5khMTQ+/BFU9fh6IynA/7QK6P0gVSmC25SpkBDZzp6V Tcpu6sH23abqpOEwMQ/KVAcThNNMYmzDD+MyEvjQDZdgeot0m/1/KpRmVHfmyp6Dc+Dy M4Mw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b=TMfVH+Xv; 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-49e84c934e6si26765e9.1.2026.09.15.15.39.44 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Sep 2026 15:39:44 -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 1AB9C180B99 for ; Wed, 16 Sep 2026 00:39:44 +0200 (CEST) Received: (qmail 15963 invoked by uid 989); 15 Sep 2026 22:39:44 -0000 Received: from unknown (HELO unknown) (::1) by farbauti.uberspace.de (Haraka/3.1.1) with ESMTPSA; Wed, 16 Sep 2026 00:39:43 +0200 Message-ID: <70cc8e00-e4fd-46de-b9b4-27bc39bfcbe8@murch.one> Date: Tue, 15 Sep 2026 15:39:40 -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: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Bar: -- X-Rspamd-Report: BAYES_HAM(-2.999999) XM_UA_NO_VERSION(0.01) MIME_GOOD(-0.1) MIME_BASE64_TEXT(0.1) X-Rspamd-Score: -2.989999 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=TMfVH+Xv; 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 (/) Hey Conduition, the reason for that comment was that if we ever move the BIPs to a=20 different platform, GitHub-flavored Markdown features may break.=20 However, it has gotten drastically cheaper to amend such issues in=20 documents, so if that=E2=80=99s the only reason you=E2=80=99re eyeing a tra= nslation to a=20 different format, please feel free to submit the Markdown instead. Cheers, Murch On 2026-09-13 15:25, 'conduition' via Bitcoin Development Mailing List=20 wrote: > Hey Murch, and thanks for confirming. We were under the impression BIP3 r= ecommends standard (non-flavored) markdown: > > >> The author of this proposal has no opinion on Markdown flavors, but reco= mmends 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 numbe= r of places. > > regards, > conduition > > On Friday, September 11th, 2026 at 5:57 PM, Murch wrote= : > >> Hi Conduition et al, >> >> I=E2=80=99m excited that your draft has progressed this far. Please feel= free to >> open a PR to the BIPs repository whenever you=E2=80=99re 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 >> =E2=80=9COutline=E2=80=9D button at the right end of the bar above the d= ocument 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 =3D *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 becaus= e >>> network throughput will have dropped. I can't conjecture on how high fe= e >>> 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=E2=80=AFPM UTC-7 Antoine Riard wr= ote: >>> >>> 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, co= nduition a =C3=A9crit : >>> >>> Hi everyone, it's me again. >>> >>> On behalf of the SHRINCS Working Group, I am excited to announ= ce >>> a first draft of a cryptographic BIP that fully specifies >>> SHRINCS: A semi-stateful hash-based signature scheme for Bitco= in. >>> >>> 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 th= at >>> 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 27= 92 >>> 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 t= o >>> 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 compo= nent. >>> >>> >>> Drawbacks >>> >>> SHRINCS has drawbacks: >>> >>> * The efficient stateful component requires software that ca= n >>> manage an incrementing state counter (essentially the numb= er >>> 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 >> byte-stateful-post-quantum-signatures-with-static- >>> backups/2158> and intheir joint paper >> eprint.iacr.org/2025/2203.pdf>referenced therein. Also seethis >>> related mailing list thread >> bitcoindev/c/gOfL5ag_bDU/>. >>> >>> Notable changes since the original proposals 8+ months ago inc= lude: >>> >>> * *Black-box compatibility with SLH-DSA (FIPS-205) >>> algorithms*. This encourages interoperability with non- >>> Bitcoin systems, and leans into established security proof= s. >>> * *Flexible XMSS (FXMSS)*. Prior descriptions of SHRINCS >>> implied only unbalanced stateful trees were allowed. We no= w >>> 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 whic= h >>> offer much faster performance (at the cost of larger >>> signatures) compared to the original proposal. >>> >>> >>> Status >>> >>> This initial draft specification contains only the cryptograph= y >>> 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, whic= h >>> 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 a= nd >>> 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 w= e >>> encourage prospective cyclists to first read the relevant >>> sections of thedesign rationale >> shrincs-bip/blob/main/SHRINCS.md#rationale>, and invite reader= s >>> 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.b= e/ >>> n-jGPICZMR0?si=3DNpfyTRB88-sUxtlh >> si=3DNpfyTRB88-sUxtlh> >>> >>> Related Work >>> >>> We are building libshrincs >> libshrincs>, an attempt at a formally verified C implementatio= n. >>> 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 truncated >>> SHA256 (SSProve ). Still a >>> prototype, more detail on Delving >> 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 o= rder: >>> >>> - 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 >>> >> ee7138de419bn%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter= >. >> -- >> You received this message because you are subscribed to the Google Group= s "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 70cc8e00-e4fd-46de-b9b4-27bc39bfcbe8%40murch.one.