From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 13 Sep 2026 15:51:32 -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 1x5t2p-0000gZ-VH for bitcoindev@gnusha.org; Sun, 13 Sep 2026 15:51:32 -0700 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-469debb526fsf2458405fac.0 for ; Sun, 13 Sep 2026 15:51:31 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1789339886; cv=pass; d=google.com; s=arc-20260327; b=I5/pxta/sCmQnZXFgAP8naCw4KOgAEc9geEqKaQ51AORd3J7GFD5RWUchjveQdxnO9 Ipl9LQ7HpKOd94b9liuQYItUfT+IMbLriZU+YJ3rqF6JoLizbzAeYOXiag5C5OdkeKRV yoCgIyfVQrgGie7dAzkjq9ej7j6/lBzx6B6rBahChwBeHuu3xktiN8HpG9sq2EAPsCGq 8/J8ny+ASf5kofdty4l+Y7lpM87X/S4sIr+rgEqalDJDuqpO08xICM/jlA44OKy/1A2z Ehi+wpjLayb2C7HvqItJ2bYb8V65VXPuyXz70u2Ty6syHUb+RkbPUF6XAAREmSw6BLMZ VPWw== 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=q/aOA56yW3lJPuCrcJC17ICkpNME7Uk9crDVO0iF+v8=; fh=3PAtvQK2vY43RZkhS+VCWHBJLGrCToILN4rj7TocrhM=; b=LgO1rRzAhlziJ88hP94gDoZnyMmiZrecjE3QuYFSj1UKgwjgdaFcSHaPDA7FzVCg5R Q0G6xeegkBFsRSuSvPSUNyslB8phtyk28vP5KnZv2RKUzjUGD9CCoHV623CaX6h9SVq9 RodPe5tNGIoyL3fTiRVpiZ/mFFeXg2PVZdE3i2vECt4vf95eSDTWp8sdxKyXVVW/HJmt u0loKaGvoxRLm7P1dKAHiDl6Usf0r/a2nZJE4Z4HnjEs6DvcxvE76VPyrV1L+UZdIZRT E5oiBM+Zq+s3iYxGdmXiQfqU9qNRUgM6nE0Zo0k7bNFZhJntOxhDL4UtTv0rEgIl/89v tZPQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=U1jygGAv; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.166 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=1789339886; x=1789944686; 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=q/aOA56yW3lJPuCrcJC17ICkpNME7Uk9crDVO0iF+v8=; b=rLCJ+AVwRtvxGATqgg0pIPnvg3GOjRakmDu3MJ0F3m71yupOkPbqwBlhbD1rn6A6Bw q+sAiszHS9k7C5kXYSgqX+tvEQTL5TaCS0dXTrE7h99Sdz8FFCfjXxmeQdtOAFi//v2K qH3q60RAVj8/wrkwcn11xEQxDS8Ws+WFMlQclo6s6ZimaCYIEgxPHil0CkNvr46ScKPq OUpqHfTSSZiMK/obv68VcYMkxqVk2SNXxcoUI/JU0AMr5BvrfEzfSAvqVjuZPx8rGA/k PLmjHmKUqCHpsAvCF7Lr61QFnzdWkhxoZaHwaEUxOghKeNpgKdpRQcFFS5jdjjfM6Yhj TpDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789339886; x=1789944686; 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=q/aOA56yW3lJPuCrcJC17ICkpNME7Uk9crDVO0iF+v8=; b=o2/TanCePl3XrLuJ8JGCn3WMSE9H2IMH5y0l9LIoaU304ID4G0gRvJ7JkThRzdkj3A zxBTRshxObziBrMvxHF8XeXhI7SujPHeZngy0iEkQpy8HKeRQkvFvA8XTfdV8F1tDUnd cllq0t75Bo9/a+I1MTbl0XAN+/MU4h9iQFQ8p++lJKZ8oomPty24exAh6VaJnEGTAE3L tRqOCwQBF7rAAFnpcM98njyu0OKFboXHiYTH0CupTB1mKniFrJBSdBkSLCvfXZNJBCgZ X85RN5ah5f6XoP5uUh7IvAdps+1We4NKYLUcUvj4EA915ghCXuGlSrr+1QSI+YwIPtb9 rd1g== X-Forwarded-Encrypted: i=2; AKwUvBxIe4rd0Sw3tIW0/mcnO6WtxsQbLPjCJGQcUzCDtMXbspINfY8gNag80CKoizE4jhkDsTt8LCHo5IUF@gnusha.org X-Gm-Message-State: AFuF++l8Glv7xrThJjL0llEa/rvNxY2v77p3hp/eddAfnUWI13HA5kp4 lFjnQCX5CUGLHLtRcThiF0msvvbzPhOt2LCTijEjJpZUZse3SXreasXb X-Received: by 2002:a05:6871:660d:b0:447:a816:9328 with SMTP id 586e51a60fabf-481f7a25ab4mr51753fac.6.1789339885661; Sun, 13 Sep 2026 15:51:25 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdcrgZYc2v0IuXAnsXQs7gLR+O4dBbHvMeeX+KW9xECF1w==" Received: by 2002:a05:6870:8311:b0:47e:54b0:78f2 with SMTP id 586e51a60fabf-47e54bfc1d6ls2531973fac.2.-pod-prod-07-us; Sun, 13 Sep 2026 15:51:17 -0700 (PDT) X-Received: by 2002:a05:6808:e794:20b0:4c3:bc6a:a328 with SMTP id 5614622812f47-4c3bc6aa7d4mr5336797b6e.31.1789339877298; Sun, 13 Sep 2026 15:51:17 -0700 (PDT) Received: by 2002:ab3:7152:0:b0:312:42b6:3552 with SMTP id a1c4a302cd1d6-31408a06721msc7a; Sun, 13 Sep 2026 15:25:10 -0700 (PDT) X-Received: by 2002:a05:6512:130b:b0:5b4:c00d:23f3 with SMTP id 2adb3069b0e04-5b8a02de3aamr2661753e87.14.1789338308756; Sun, 13 Sep 2026 15:25:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1789338308; cv=none; d=google.com; s=arc-20260327; b=XjpKXRxFfi9wDhfXx4uAZRnomLswhc+KeDSWs/Xf0/PoSmxDGIEd+ZmN2enkWycNfT F25TDFUXaD754tswgLIp9chBRquzRQqn5d5hGk8SfiCoLgQcqlrf4QqPcs+bCbKezmgf LWVeXREAVkZ5iwqN62gnJ7IVtJyN/EP/ujzi+7Mncuz/rZegxuKub8GbqQs7uwfb7gR/ jjJo9a1CjUaGGpRj9WrAQ6SwE0Z0s1/ZQUf7tb88GhORCOCAnkZV8YCXJUHeETaFP5Dv esTz2mMv0nNzAuqcfwlO0f5K/LxDyel8BJZeCGxD3AfJuA9NiGuMAsTdcquzGb3zhi8T iCew== 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=spt6tbSLMuoaabIgD1EHtDvhg3OBkC6h8ZYwb8VNkRU=; fh=foaZ9w3C3c5ltuXRyLrsJcSZd5F+/L4e8AHpKYxjE8o=; b=lq66AN01EfeigFSPYl9ayAFFT9TLOZY5urviJLDgYCxpnU2FpU5Vztc9NlkHm0wpDz HlrfN3aHa0VNN43dREOzyBWa1XjVF5SMW64oEOsqw6iIo8S88ZwmaRfVPNRYVwtsfQxz cpu+oeI+Mh1GPm6wzIkvrl5HGU3aIo/MANQZgjOhhudqdjsj6VX0RlmdiRNZBmY6zcHJ EkZ11pms25mTw3wV3261S4++4PuTYISoLSkXsBPZt+kCxszx03f60TZMioe8DskDgGHN e/SW+Go5oDX4eZSur2+BbVA4j8pob2vJMK2HDcbg1MLJEW6U9QKQHb2XmcnS/v+OVOD9 LZeg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=U1jygGAv; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.166 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-43166.protonmail.ch (mail-43166.protonmail.ch. [185.70.43.166]) by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-5b8a047a6d6si184843e87.5.2026.09.13.15.25.08 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 13 Sep 2026 15:25:08 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 185.70.43.166 as permitted sender) client-ip=185.70.43.166; Date: Sun, 13 Sep 2026 22:25:01 +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: References: <-w8D4WbD7zY2bfYQIES40iBZQWbZx6ab-S6EW8tWsMEFaHO9NEOLUkte_MZZgNQDd0pljCM2wD1Ccnk3BfjwLPgCiVz-NfTwjHJ4aZHUqUw=@proton.me> <2fb38fb8-2584-4550-b268-ee7138de419bn@googlegroups.com> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: a22243d03560b6a59cb793e7d47b726a158cf83b MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------c3d8467b73cabf1f8aa8f46ce87a6c075fa135e1a8306dbf29ef16461c400a7d"; 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=protonmail header.b=U1jygGAv; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.166 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) --------c3d8467b73cabf1f8aa8f46ce87a6c075fa135e1a8306dbf29ef16461c400a7d Content-Type: multipart/mixed;boundary=---------------------108f8dae13137b86c8e9cc92c98d5025 -----------------------108f8dae13137b86c8e9cc92c98d5025 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hey Murch, and thanks for confirming. We were under the impression BIP3 rec= ommends standard (non-flavored) markdown:=20 > The author of this proposal has no opinion on Markdown flavors, but recom= mends that proposals stick to the basic Markdown syntax features commonly s= hared across Markdown dialects. At the moment we're using features of github flavored markdown in a number = of places. regards, conduition On Friday, September 11th, 2026 at 5:57 PM, Murch wrote: > Hi Conduition et al, >=20 > 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 do= cument content. >=20 > Cheers, > Murch >=20 > 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, con= duition a =C3=A9crit : > > > > Hi everyone, it's me again. > > > > On behalf of the SHRINCS Working Group, I am excited to announc= e > > a first draft of a cryptographic BIP that fully specifies > > SHRINCS: A semi-stateful hash-based signature scheme for Bitcoi= n. > > > > 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 tha= t > > 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 279= 2 > > 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 compon= ent. > > > > > > Drawbacks > > > > SHRINCS has drawbacks: > > > > * The efficient stateful component requires software that can > > manage an incrementing state counter (essentially the numbe= r > > 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 incl= ude: > > > > * *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 protocols 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. > > > > > > Status > > > > 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. > > > > 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 an= d > > 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 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 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 implementation= . > > 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 or= der: > > > > - 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= >. >=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/c0ff85ab-2b8b-4aea-8a04-e0e8a6be7c94%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/= gQG2loLv5XaZrJVFrD_nVtP1m-yTF89A-phqkz-V5qA8VpmygXJnyRG6_nU73Hb-C4ZbIEZghvE= j6rEulV2TqtLQHUisu5xIg8Ak-1J4Q3o%3D%40proton.me. -----------------------108f8dae13137b86c8e9cc92c98d5025 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== -----------------------108f8dae13137b86c8e9cc92c98d5025-- --------c3d8467b73cabf1f8aa8f46ce87a6c075fa135e1a8306dbf29ef16461c400a7d Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmqnIq0JEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmco/h5G4zCOsaxgekdx9nnElQdo2Vycg9p7XmIz 3Vj7aRYhBEdIka0CMtrLdg13a3gpbO2E9rPFAADGbQD9HvYEJIYiUUgtfAqE jDD2ccRCEtB1r/xL8aCN0uv97QIA/RwP5uL8GM8yKsJ8y9Ep63t429cai+Xn +I+TSq6ObpoJ =oESj -----END PGP SIGNATURE----- --------c3d8467b73cabf1f8aa8f46ce87a6c075fa135e1a8306dbf29ef16461c400a7d--