From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 31 Mar 2026 02:32:59 -0700 Received: from mail-oa1-f58.google.com ([209.85.160.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1w7VT0-00034v-7U for bitcoindev@gnusha.org; Tue, 31 Mar 2026 02:32:59 -0700 Received: by mail-oa1-f58.google.com with SMTP id 586e51a60fabf-41555e51e94sf7151054fac.1 for ; Tue, 31 Mar 2026 02:32:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1774949572; x=1775554372; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=j+oUNKMbz0NFKN5FBzTxug7zObh2rjVUEAE8OSxV6DU=; b=FxVR2BfK9wD64qr162GwIk/LR42EfTCcE/YAKD3JVSRqHEsBax8+KZMSQIVzH3MOiX GVxFML9NyMWXjnEk3/nkcKoxqs9DrOOykko5ZyTmgaAhyScxwP+bOmEMAQ88eoK/wxcH 4ZjYGBboJ3jXtUDr6B51xopBKrVWQr1dlNj+iE4JkoIK3pU4vOx0Jfk2ZySfhRCv8Ojq cnLNHhl57uhomEBTyGhBlq62QFFeisrvt8YBPtTUIHG97zqNc1pMlJOdDryyhw1A6ysF 7w9lIff7+JcaS2UxfIr88sBNX0JU3cwVtViqYfES+xFBT4C5TbHyvfidaYQbt3Ls3Gt+ o1tA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774949572; x=1775554372; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=j+oUNKMbz0NFKN5FBzTxug7zObh2rjVUEAE8OSxV6DU=; b=pbemk2hv3CqzSsj1as6oORoMWWdUNK36rqrzwy7mfmuYqXsdDQVzZ8g3npL1/Jc/+j +eWCCu6vk2RV39dJrxOQW27Ik+ZV+eHGbL2ZIwuselIH9BCfOOrAugsRj3xQS9sxqecC JxQE0l0gfewS8lGYgW5olymkOG6SuomHJKFoKPbKDChJvLGECL/Y/x19MrvyBpeiv3j8 K5c0xRF03FbO9d6SMutt8YqPLJsZUyHU81z2fylKElmuC/YU+A6rh++eKzNnlsh0qsRw +RrMW6y3UR6Fqd6QP+L5EQB2QbkO6hIMF0TTtwDeJZqil1svzY7zL8LHhKA4huXpxMTv mlZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774949572; x=1775554372; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=j+oUNKMbz0NFKN5FBzTxug7zObh2rjVUEAE8OSxV6DU=; b=B0wGPAKYwbPkw2sxfRPFx+5resu++aNYbyuY8Gte4OyhFDbfu007ifwcJIF/qMqNMM QlfVkgk6+d4wMZHucJsCxDfFt24qgrHGRqLwKsADI3DDLRu+ntJWA7LmfwN9k54tQk96 p1LBcLjZhh8LkXlsV9XJpwVbklWueYhGl1NffCdKLw6KFdCMbgwZbK7E2YXXaIa27qNP rwzErfwlbnEpSO7EMLVvghdnDBuDO/NM8/uTKhASSeyxNbOMnzimHiFBc/uIfQvVqpbB hOMsw4zy7R64GcY10o0L8JU9PSPn1xRF6jd5Oh5dK+rDMPISwvcm1wqJKb8q05/bvv/6 ZP6Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUMe+oBTGzu9C7M1GNvtSKMNKME9OX1QyIifQkrSIXwYbqPWSL3inLkUOf02vUKFo2FXQ7B+rV7f6v+@gnusha.org X-Gm-Message-State: AOJu0YyiKJ9ircqivPgKbA9JMz0Giw1iyO/X8mbJcvvZRQ44w9Cp/40j CR8aEoLPrKaVPNkTLMzx+O0wKlo6znhY9R18KUYjq5fLGAroCxa+gaSc X-Received: by 2002:a4a:e904:0:b0:67e:3b62:cd76 with SMTP id 006d021491bc7-67e3b62d09bmr2183240eaf.29.1774949571851; Tue, 31 Mar 2026 02:32:51 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiLCaxxXx5OWGTi6zJL1O05ghqJAehPr69K2qanOcxjNWw==" Received: by 2002:a05:6820:1ca0:b0:67b:f5b9:99d8 with SMTP id 006d021491bc7-67e2dcf26e2ls1038410eaf.0.-pod-prod-02-us; Tue, 31 Mar 2026 02:32:46 -0700 (PDT) X-Received: by 2002:a05:6808:2208:b0:46a:738f:7666 with SMTP id 5614622812f47-46a8a574fd3mr7321637b6e.36.1774949566077; Tue, 31 Mar 2026 02:32:46 -0700 (PDT) Received: by 2002:a05:690c:c222:b0:79a:8019:36f5 with SMTP id 00721157ae682-79c8fb6f7b7ms7b3; Mon, 30 Mar 2026 20:09:56 -0700 (PDT) X-Received: by 2002:a05:690c:f14:b0:79b:73dc:d2fb with SMTP id 00721157ae682-79bde080744mr150904417b3.46.1774926596380; Mon, 30 Mar 2026 20:09:56 -0700 (PDT) Date: Mon, 30 Mar 2026 20:09:55 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <6f396784-837f-4764-b9f2-f4fe7ec1555bn@googlegroups.com> In-Reply-To: References: <273ith9pPyipCI5hjV6ETFBzFhM4xFN8ptEFK8zc5N-jxGwOBvEn5r9Bt2c9p0A-6-3Bs53gONglzo1QfI4LCIOwkJgR9PWT4iQT_Wbpllo=@protonmail.com> Subject: Re: [bitcoindev] BIP 54 active on Bitcoin Inquisition MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_314818_1075745903.1774926595952" X-Original-Sender: antoine.riard@gmail.com 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.5 (/) ------=_Part_314818_1075745903.1774926595952 Content-Type: multipart/alternative; boundary="----=_Part_314819_19671452.1774926595952" ------=_Part_314819_19671452.1774926595952 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 Hello, > It's a fine line to tread, because on the one hand you do not want to=20 give away the details of how to optimise the attack (whether for maximum=20 profit or for maximum impact), but on the other hand i do think it's=20 necessary to provide some amount of publicly verifiable information to=20 support a soft fork activation proposal. Agree here it's a fine line and there is no good answer. It's the same=20 problem every time a covert fix for a severe bug has to be developed and=20 disseminated. And from what I aware of, even for open source kernels, where fixes=20 processes have been broken in for 20+ years, they are not doing that much= =20 better... > After that, i split the 6 slow-to-validate transactions into smaller BIP= =20 54 compatible ones. When you say "splitting" I guess you mean crafting transactions spending=20 the same preparation outputs, though for example with less sig ops in the= =20 scriptpubkey to have them passing the new MAX_TX_LEGACY_SIGOPS, though the= =20 txid:index spent are staying the same. That BIP54 is reducing the value=20 transferred throughput per byte of tx when you're consuming legacy inputs,= =20 I think that's a fine trade-off (-- I guess other questions and=20 observations can be made on the delving thread). Going further, in my memory the taproot structured review back in 2019 [0]= =20 was a good initiative to have a lot of eyes engaging in the review process= =20 of those consensus changes. While it might be harder those days to have=20 everyone fitting in a IRC channel due to the growth of the ecosystem=20 (...?), I wonder if an alternative could be to have a handbook explaining= =20 how to test on a regtest pre / after BIP 54 fixes each one of the fix=20 (difficulty adjustement, long block validation time, merkle tree=20 malleability, duplicate coinbase txn). People can be full-node operator,=20 doesn't necessarily means they have the skills to write their own python=20 tests to check specific behaviors. The handbook is just an idea, but I'm=20 sure people would love to go through at their local bitcoin meetups. And somehow, I believe for consensus changes, it's good to do the work of= =20 building legitimacy (i.e lowering the bar for anyone to reproduce the tests= =20 ?). Best, (the other) Antoine OTS hash: c5ca45485b8362dfaa20516192395b051706ac06c9e975176be4de8665928ef9 [0] https://github.com/ajtowns/taproot-review Le Monday, March 30, 2026 =C3=A0 8:40:21=E2=80=AFPM UTC+1, Antoine Poinsot = a =C3=A9crit : > My approach so far has been to share all details in the semi-private=20 > Delving thread that is accessible to a number of experts who would be abl= e=20 > to figure it out on their own anyway, and to share a demonstration of an= =20 > expensive-but-far-from-worst block publicly. > > > Anthony Towns and i performed such a demo last week on Signet. > > I created preparation outputs for 6 transactions that are slow to=20 > validate. How slow depends on the machine, my tests show 4 seconds per=20 > block on modern hardware, about 20 seconds on a mid-range server, and ove= r=20 > a minute on a RPi 4B. AJ reports it took a cheap VPS about 5 minutes to= =20 > validate each block during the live demo. > > AJ mined 6 blocks in a row containing those transactions, and then reorge= d=20 > them out. This allows anyone who was running a Bitcoin Core Signet node a= t=20 > the time to observe the slowish blocks, without imposing an IBD cost to a= ll=20 > future nodes. It goes without saying that anyone running Bitcoin=20 > Inquisition >=3D 29.2 instead would observe their nodes rejecting those= =20 > blocks, since BIP 54 makes them invalid. > > After that, i split the 6 slow-to-validate transactions into smaller BIP= =20 > 54 compatible ones. AJ mined them in 6 more blocks that spend the same se= t=20 > of inputs that the slow blocks did. This is a demonstration that BIP 54= =20 > only precludes batching too many legacy inputs, to not exacerbate quadrat= ic=20 > behaviours in transaction validation, but spending those same inputs in= =20 > multiple transactions is entirely fine. > > More details on the demo are available here:=20 > https://bnoc.xyz/t/slowish-blocks-on-signet/100. Thanks to b10c and Emzy= =20 > for participating and sharing observations. > > Here are the hashes of the stale slowish blocks: > > - 00000000d9338f3251ebb0dc01afebf34b38a2bafaf1376ef9e26e02eadb0c64 > - 00000006048ed6cfedbc6249c5eb82616a4a90cb35c76127af7a40e3198736e1 > - 00000013fb4596b358dd07ede7ef18c57a64e4a6fc0b33944bb86b91f0e74b32 > - 00000007326c42ef17ee090f758ba328954f24313648dc0971b7b33b165427e7 > - 00000002a129891c57504b01e855d29e8e4debc90a12eb092a1afe83e87b13f0 > - 0000000cd04ef18d4a43fa7fc093b8c3a6d29685d899f29e20373bfd04bab78d > > > Here is a tentative (unsure if it'll make it through to the list)=20 > screenshot of a peer observer = =20 > instance b10c had deployed for the occasion, right after the reorg. Node = 01=20 > runs Bitcoin Core v31.0rc1 Signet and node 02 runs Bitcoin Inquisition=20 > v29.2. > [image: image.png] > > Antoine Poinsot > > On Wednesday, March 11th, 2026 at 11:27 AM, 'Antoine Poinsot' via Bitcoin= =20 > Development Mailing List wrote: > > I share this concern, which is why i only shared details about this in th= e=20 > (semi-)private Delving thread to this effect:=20 > https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711. > > The testing for quality assurance has already been performed as part of= =20 > the investigation into the various techniques and possible mitigations.= =20 > Additional testing is always valuable, but the primary goal of a public= =20 > demonstration for this would be to help build consensus. > > It's a fine line to tread, because on the one hand you do not want to giv= e=20 > away the details of how to optimise the attack (whether for maximum profi= t=20 > or for maximum impact), but on the other hand i do think it's necessary t= o=20 > provide some amount of publicly verifiable information to support a soft= =20 > fork activation proposal. > > My approach so far has been to share all details in the semi-private=20 > Delving thread that is accessible to a number of experts who would be abl= e=20 > to figure it out on their own anyway, and to share a demonstration of an= =20 > expensive-but-far-from-worst block publicly. This allows anyone to check= =20 > for themselves that it is indeed possible to craft *some*=E2=80=8B slow b= locks,=20 > and they can refer to an expert to confirm that it can be made much worse= .=20 > Of course, i remain open to feedback. > On Wednesday, February 25th, 2026 at 12:03 PM, Jameson Lopp < > jameso...@gmail.com> wrote: > > The main concern I'd have is whether or not doing so would leak more=20 > information to the world about how to conduct such an attack on mainnet. = It=20 > may be prudent to perform such testing privately. > > On Fri, Feb 13, 2026 at 5:28=E2=80=AFPM 'Antoine Poinsot' via Bitcoin Dev= elopment=20 > Mailing List wrote: > >> Hi everyone, >> >> Bitcoin Inquisition 29.2 was released last week with support for BIP 54= =20 >> (Consensus Cleanup) [0]. BIP >> 54 is now active on Inquisition since block 291168. >> >> By virtue of being a bugfix soft fork rather than introducing new=20 >> features, there is fewer avenues >> for testing on the public Signet network. Perhaps we could create a=20 >> Signet block that is slow but >> not quite as bad as the worst case, and share it here to demonstrate it= =20 >> is now invalid on >> Inquisition? >> >> At any rate, please let us know if you find anything in testing whether= =20 >> it is on the public Signet >> network, in private ones, or however else. >> >> Best, >> Antoine Poinsot >> >> [0] https://delvingbitcoin.org/t/bitcoin-inqusition-29-2/2236 >> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/wJZkcSEOQD5Z8rsel8TJCSkUJiw= n7YepjyOfSDHKt3P_4Fvh9MFu_oiva3G6C-Q_1CmRTCj6lqmVm6ZeZG8WbdVrCo4IZUFg3VazRd= J48AQ%3D%40protonmail.com >> . >> > --=20 > You received this message because you are subscribed to the Google Groups= =20 > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to bitcoindev+...@googlegroups.com. > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/CADL_X_ewFMqLuv7MVfWCZf3QhKe= zW9xiS19xWdROjtoT9dmU7w%40mail.gmail.com > . > > > --=20 > You received this message because you are subscribed to the Google Groups= =20 > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to bitcoindev+...@googlegroups.com. > > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/273ith9pPyipCI5hjV6ETFBzFhM4= xFN8ptEFK8zc5N-jxGwOBvEn5r9Bt2c9p0A-6-3Bs53gONglzo1QfI4LCIOwkJgR9PWT4iQT_Wb= pllo%3D%40protonmail.com > . > > > --=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/= 6f396784-837f-4764-b9f2-f4fe7ec1555bn%40googlegroups.com. ------=_Part_314819_19671452.1774926595952 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello,

> It's a fine line to tread, because on the one hand you do not want = to give away the details of how to optimise the attack (whether for maximum= profit or for maximum impact), but on the other hand i do think it's neces= sary to provide some amount of publicly verifiable information to support a= soft fork activation proposal.

Agree here it's a fine line and there is no good answer. It's the same p= roblem every time a covert fix for a severe bug has to be developed and dis= seminated.

And from what I aware of, even for open source kernels, where fixes proc= esses have been broken in for 20+ years, they are not doing that much bette= r...

> After that, i split the 6 slow-to-validate transactions into smalle= r BIP 54 compatible ones.

When you say "splitting" I guess you mean crafting transactions spending= the same preparation outputs, though for example with less sig ops in the = scriptpubkey to have them passing the new MAX_TX_LEGACY_SIGOPS, though the = txid:index spent are staying the same. That BIP54 is reducing the value tra= nsferred throughput per byte of tx when you're consuming legacy inputs, I t= hink that's a fine trade-off (-- I guess other questions and observations c= an be made on the delving thread).

Going further, in my memory the taproot structured review back in 2019 [= 0] was a good initiative to have a lot of eyes engaging in the review proce= ss of those consensus changes. While it might be harder those days to have = everyone fitting in a IRC channel due to the growth of the ecosystem (...?)= , I wonder if an alternative could be to have a handbook explaining how to = test on a regtest pre / after BIP 54 fixes each one of the fix (difficulty = adjustement, long block validation time, merkle tree malleability, duplicat= e coinbase txn). People can be full-node operator, doesn't necessarily mean= s they have the skills to write their own python tests to check specific be= haviors. The handbook is just an idea, but I'm sure people would love to go= through at their local bitcoin meetups.

And somehow, I believe for consensus changes, it's good to do the work o= f building legitimacy (i.e lowering the bar for anyone to reproduce the tes= ts ?).

Best,

(the other) Antoine

OTS hash: c5ca45485b8362dfaa20516192395b051706ac06c9e975176be4de8665928e= f9

[0] https://github.com/ajtowns/taproot-review


Le Monday, March 30, 2026 = =C3=A0 8:40:21=E2=80=AFPM UTC+1, Antoine Poinsot a =C3=A9crit=C2=A0:
My approach so far has been to= share all details in the semi-private Delving thread that is accessible to= a number of experts who would be able to figure it out on their own anyway= , and to share a demonstration of an expensive-but-far-from-worst block pub= licly.

Anthony Towns and i performed such a demo las= t week on Signet.

I created preparation outputs for 6 transaction= s that are slow to validate. How slow depends on the machine, my tests show= 4 seconds per block on modern hardware, about 20 seconds on a mid-range se= rver, and over a minute on a RPi 4B. AJ reports it took a cheap VPS about 5= minutes to validate each block during the live demo.

AJ mined 6 = blocks in a row containing those transactions, and then reorged them out. T= his allows anyone who was running a Bitcoin Core Signet node at the time to= observe the slowish blocks, without imposing an IBD cost to all future nod= es. It goes without saying that anyone running Bitcoin Inquisition >=3D = 29.2 instead would observe their nodes rejecting those blocks, since BIP 54= makes them invalid.

After that, i split the 6 slow-to-validate t= ransactions into smaller BIP 54 compatible ones. AJ mined them in 6 more bl= ocks that spend the same set of inputs that the slow blocks did. This is a = demonstration that BIP 54 only precludes batching too many legacy inputs, t= o not exacerbate quadratic behaviours in transaction validation, but spendi= ng those same inputs in multiple transactions is entirely fine.

M= ore details on the demo are available here:=C2=A0https://bnoc.xyz/t/slowish-blocks-on-signet/100. Thanks to b10c and Em= zy for participating and sharing observations.

  • 00000000d93= 38f3251ebb0dc01afebf34b38a2bafaf1376ef9e26e02eadb0c64<= /li>
  • 00= 000006048ed6cfedbc6249c5eb82616a4a90cb35c76127af7a40e3198736e1
  • 00000013fb4596b358dd07ede7ef18c57a64e4a6fc0b33944bb86b9= 1f0e74b32
  • 00000007326c42ef17ee= 090f758ba328954f24313648dc0971b7b33b165427e7
  • 00000002a129891c57504b01e855d29e8e4debc90a12eb0= 92a1afe83e87b13f0
  • 0000000cd04ef18d4a43fa7fc093b8c3a6d29685d899f29e20373bfd04bab= 78d
<= br>
Here is a tentative (unsure if it'll make it through to t= he list) screenshot of a peer observer instance b10c had deployed fo= r the occasion, right after the reorg. Node 01 runs Bitcoin Core v31.0rc1 S= ignet and node 02 runs Bitcoin Inquisition v29.2.
3D"ima=

Antoine Poinsot

On Wednesday, March 11th, 2026 at 11:27 AM, 'Antoine Poinsot= 9; via Bitcoin Development Mailing List <bitco...@googlegroups.com> wrote:
I sh= are this concern, which is why i only shared details about this in the (sem= i-)private Delving thread to this effect:=C2=A0https://delvingbitcoin.org/t/worst-b= lock-validation-time-inquiry/711.

The testing for quality assurance has already b= een performed as part of the investigation into the various techniques and = possible mitigations. Additional testing is always valuable, but the primar= y goal of a public demonstration for this would be to help build consensus.=

=
It's a fine = line to tread, because on the one hand you do not want to give away the det= ails of how to optimise the attack (whether for maximum profit or for maxim= um impact), but on the other hand i do think it's necessary to provide = some amount of publicly verifiable information to support a soft fork activ= ation proposal.

M= y approach so far has been to share all details in the semi-private Delving= thread that is accessible to a number of experts who would be able to figu= re it out on their own anyway, and to share a demonstration of an expensive= -but-far-from-worst block publicly. This allows anyone to check for themsel= ves that it is indeed possible to craft some=E2=80=8B slow blocks, a= nd they can refer to an expert to confirm that it can be made much worse. O= f course, i remain open to feedback.
On Wednesday, February 25th, 2026 at 12:03 PM, Jameson Lopp <jameso...@gmail.com> wrote:<= br>
The main concern I'd have is whether or no= t doing so would leak more information to the world about how to conduct su= ch an attack on mainnet. It may be prudent to perform such testing privatel= y.

On Fri, Feb 13, 2026 at 5:28=E2=80=AFPM 'Antoine Poinsot' via Bit= coin Development Mailing List <bitco...@googlegroups.com> wrote:
Hi everyone,

Bitcoin Inquisition 29.2 was released last week with support for BIP 54 (Co= nsensus Cleanup) [0]. BIP
54 is now active on Inquisition since block 291168.

By virtue of being a bugfix soft fork rather than introducing new features,= there is fewer avenues
for testing on the public Signet network. Perhaps we could create a Signet = block that is slow but
not quite as bad as the worst case, and share it here to demonstrate it is = now invalid on
Inquisition?

At any rate, please let us know if you find anything in testing whether it = is on the public Signet
network, in private ones, or however else.

Best,
Antoine Poinsot

[0] https://delvingbitcoin.org/t/bi= tcoin-inqusition-29-2/2236

--
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 bitc= oindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/wJZkcSEOQD5Z8rsel8TJCSkUJiw= n7YepjyOfSDHKt3P_4Fvh9MFu_oiva3G6C-Q_1CmRTCj6lqmVm6ZeZG8WbdVrCo4IZUFg3VazRd= J48AQ%3D%40protonmail.com.

--
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 bitc= oindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/CADL_X_ewFMqLuv7MVfWCZf3QhKezW9xiS19xWdROjtoT9dmU7w%40mail.gmail.com= .

--
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 bitc= oindev+...@googlegroups.com.

--
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/6f396784-837f-4764-b9f2-f4fe7ec1555bn%40googlegroups.com.
------=_Part_314819_19671452.1774926595952-- ------=_Part_314818_1075745903.1774926595952--