path: root/70/065b8698084ecaae5950447e610440b0a55550

Return-Path: <weiji.g@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 97FAFC002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 10 May 2023 03:08:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 8090A8143B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 10 May 2023 03:08:31 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 8090A8143B
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=dq9pxwL5
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 1oiKqppK49yn
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 10 May 2023 03:08:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 81CC480F66
Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com
 [IPv6:2607:f8b0:4864:20::a29])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 81CC480F66
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 10 May 2023 03:08:28 +0000 (UTC)
Received: by mail-vk1-xa29.google.com with SMTP id
 71dfb90a1353d-4501ca552a3so3201218e0c.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 09 May 2023 20:08:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1683688107; x=1686280107;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=Vd011O4dapKJMUp5EXMlC0jTJPCzujrNTpdygt3VcFU=;
 b=dq9pxwL5qXe5/Bdzco1iecEgLMjuR6mATO4RJNNJO/AxEJeAN9EbKbJRkxq1aFqB3f
 ebi4WNA80ThESyem18O3q8IiTBwiJ8KfN5ubSnI2101Xhe0HLd4suyCNJwnTpdy/H52r
 EOTMbHyorxblMV6uMXJH1rp98CznW1Yj0nWn8ysmD/sl2r/8n7oYrQlPgLrHWXTzcSij
 TPmB1/JWn/Ke6nh3r/embRwVEIHQLhvPdIVc6tLwgpX6JUoUeunJBvwx/t/6hfCZ8pr3
 fw1VYnHOjpwIjx6SulE3cYcL7RJw1//mozWo2zB8OS48Mhw2VAwU1PlhndisbFGDxvA3
 gBXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1683688107; x=1686280107;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=Vd011O4dapKJMUp5EXMlC0jTJPCzujrNTpdygt3VcFU=;
 b=Paufp/zlnv7Zmo3M9fHeRjofBKQmvDOGKAkfzQYLau9GylOJdjSnjk8iUQKAAkS2ww
 K2ujHWQE1T3rRtau6EZLfB9MqoXjaagsWyvWpXCo4Cjjdena0LFbIfRem5gr5zr8UCnu
 d6xfVav5KCT9NXrySTqGhFYRg3ogqTSSS9zAbMKI/2i+76C7Q3jWd7Omii/boqSejZRf
 KFSeehzGcxYFCXap/Wice4++NK35sWk/mlnq3wogGwnv3UBUi+caZaOSJO2ePi6E4JW/
 nio+c99xnX+g8kwBk80M3Fqk6j25gWxAe1TrYjijpNMExUJ35+G6IZ3Z8jpUNSLLn0zt
 wUMg==
X-Gm-Message-State: AC+VfDzOvhQBtohxd4Pc7pCAMV1Z32DTsnggnyYnB8OHOTYv4kkdDrt7
 J2WzANdmpX3BcuvgdVmI5VSBPoowKwwLPSTEFv4=
X-Google-Smtp-Source: ACHHUZ5ca/oLS2ecbvAX4Gs9jBFRaoPJwNL2QWcUilHtCruzPdgZcWqsGDbAJ1A+ffvp7SOrmTfyobcfC6z6pmzg2kE=
X-Received: by 2002:a1f:60c9:0:b0:452:a751:eacf with SMTP id
 u192-20020a1f60c9000000b00452a751eacfmr3433076vkb.8.1683688107169; Tue, 09
 May 2023 20:08:27 -0700 (PDT)
MIME-Version: 1.0
References: <183080646-e0c2bb9eaf62640f6c5d6c34f66db1d9@pmq7v.m5r2.onet>
 <CAJowKgJVAfDiwUEy+6f1Ln45=mua=R7c=KxV5XZOJHvgEHsQhg@mail.gmail.com>
In-Reply-To: <CAJowKgJVAfDiwUEy+6f1Ln45=mua=R7c=KxV5XZOJHvgEHsQhg@mail.gmail.com>
From: Weiji Guo <weiji.g@gmail.com>
Date: Wed, 10 May 2023 11:08:15 +0800
Message-ID: <CA+ydi=KJwPrqn1WcB-AUPsCkbUm69TsbLsVmu_H9cntNrtSD3Q@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000008a5ce505fb4e2f92"
X-Mailman-Approved-At: Wed, 10 May 2023 16:51:33 +0000
Subject: Re: [bitcoin-dev] [Mempool spam] Should we as developers reject
 non-standard Taproot transactions from full nodes?
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 10 May 2023 03:08:31 -0000

--0000000000008a5ce505fb4e2f92
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> I would like to point out that I'm not an advocate for doing anything at
this point aside from working on l2

Speaking of L2, I had recently proposed a new opcode OP_ZKP to enable
payments based on ZKP proof. I wonder if it has drawn enough attention but
it seems to me a viable way to address transaction fee issues, in addition
to enabling more smart contracts. And it will be a Bitcoin native L2, not a
side chain, not pegging.

      scriptPubKey: <hash of the verification key> <scheme_id> OP_ZKP
      scriptSig:         <pubInput_1> <pubInput_2> ... <pubInput_n> <n>
<proof>

I haven't figured out how to use OP_ZKP to incentivize BRC-20, inscription
etc. to move to L2. But I like to bring it up here and I am open to your
feedback and comments.

Thanks,
Weiji

On Tue, May 9, 2023 at 8:51=E2=80=AFPM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I would like to point out that I'm not an advocate for doing anything at
> this point aside from working on l2
>
> just to make it inconvenient for people
>
> I just think the discussion of outputs and fees is interesting and relate=
d
> to the game theory portion of Bitcoin
>
>
>
> On Tue, May 9, 2023, 8:23 AM Jaroslaw via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>>
>> Ok, I need to highlight one important thing well proven by this
>> discussion (like it or not)...
>>
>> Not the spam itself is the real reason of feeling: "something must be
>> done"
>> The reason is: $30 fee per transaction (I hope you all agree)
>>
>>
>> Let me paraphrase some quotes used in this discussion, then:
>>
>> 1. Lack of block subsidy long term and necessity of $40 tx fee to
>> compensate it - "threaten the smooth and normal use of the Bitcoin netwo=
rk
>> as a peer-to-pear digital currency, as it was intended to be used as."
>>
>> 2. "the harmony of Bitcoin transactions is being disrupted right now" du=
e
>> to lack of block subsidy and due to exorbitant $40 tx fees as an effect
>> necessary to keep the network security untouched
>>
>> 3. "Fee spikes aren't fun" and it's obvious that keeping the network
>> security only on enormous tx fees of active users and having passive use=
rs
>> as free-riders - isn't fun, too
>>
>> 4. by ignoring Bitcoin long-term security budget problem - "we indirectl=
y
>> allowed this to happen, which previously wasn't possible before. So we a=
lso
>> have a responsibility to do something to ensure that this kind of
>> tremendous $40 tx fees can never happen again"
>>
>> 5. "Action against exorbitant fees should have been taken months ago.
>> (...) It's a mistake that the" tail emission or other necessary solution=
 -
>> weren't implemented on time
>>
>> 6. "we need to find a solution for long-term horrible fees problem - tha=
t
>> fits everyone's common ground."
>>
>>
>> Yes, we need - instead of being still in a heavy denial state.
>>
>> No additional comment then, except this little one:
>> Delay of halving in case of 4 years long network difficulty regression
>> situation.
>>
>>
>> Regards,
>> Jaroslaw
>>
>>
>>
>>
>>
>> W dniu 2023-05-09 00:37:57 u=C5=BCytkownik Luke Dashjr via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> napisa=C5=82:
>>
>> Action should have been taken months ago. Spam filtration has been a
>> standard part of Bitcoin Core since day 1. It's a mistake that the exist=
ing
>> filters weren't extended to Taproot transactions. We can address that, o=
r
>> try a more narrow approach like OP_RETURN (ie, what "Ordisrespector" doe=
s).
>> Since this is a bugfix, it doesn't really even need to wait for a major
>> release.
>>
>> (We already have pruning. It's not an alternative to spam filtering.)
>>
>> Luke
>>
>>
>>
>>
>> On 5/7/23 13:22, Ali Sherief via bitcoin-dev wrote:
>> Hi guys,
>>
>>
>> I think everyone on this list knows what has happened to the Bitcoin
>> mempool during the past 96 hours. Due to side projects such as BRC-20
>> having such a high volume, real bitcoin transactions are being priced ou=
t
>> and that is what is causing the massive congestion that has arguable not
>> been seen since December 2017. I do not count the March 2021 congestion
>> because that was only with 1-5sat/vbyte.
>>
>>
>> Such justifiably worthless ("worthless" is not even my word - that's how
>> its creator described them[1]) tokens threaten the smooth and normal use=
 of
>> the Bitcoin network as a peer-to-pear digital currency, as it was intend=
ed
>> to be used as.
>>
>>
>> If the volume does not die down over the next few weeks, should we take
>> an action? The bitcoin network is a triumvirate of developers, miners, a=
nd
>> users. Considering that miners are largely the entities at fault for
>> allowing the system to be abused like this, the harmony of Bitcoin
>> transactions is being disrupted right now. Although this community has a
>> strong history of not putting its fingers into pies unless absolutely
>> necessary - an example being during the block size wars and Segwit - sho=
uld
>> similar action be taken now, in the form of i) BIPs and/or ii) commits i=
nto
>> the Bitcoin Core codebase, to curtail the loophole in BIP 342 (which
>> defines the validation rules for Taproot scripts) which has allowed thes=
e
>> unintended consequences?
>>
>>
>> An alternative would be to enforce this "censorship" at the node level
>> and introduce a run-time option to instantly prune all non-standard Tapr=
oot
>> transactions. This will be easier to implement, but won't hit the road
>> until minimum next release.
>>
>>
>> I know that some people will have their criticisms about this,
>> absolutists/libertarians/maximum-freedom advocates, which is fine, but w=
e
>> need to find a solution for this that fits everyone's common ground. We
>> indirectly allowed this to happen, which previously wasn't possible befo=
re.
>> So we also have a responsibility to do something to ensure that this kin=
d
>> of congestion can never happen again using Taproot.
>>
>>
>> -Ali
>>
>>
>> ---
>>
>>
>> [1]:
>> https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the=
-promise-and-peril-of-bitcoin-backed-tokens/
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--0000000000008a5ce505fb4e2f92
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; I would like to point out that I&#39;m not an advocat=
e for doing anything at this point aside from working on l2<div><br></div><=
div>Speaking of L2, I had recently proposed a new opcode OP_ZKP to enable p=
ayments based on ZKP proof. I wonder if it has drawn enough attention but i=
t seems to me a viable way to address transaction=C2=A0fee issues, in addit=
ion to enabling more smart contracts. And it will be a Bitcoin native L2, n=
ot a side chain, not pegging.=C2=A0</div><div><span style=3D"font-family:fo=
nt0000000029fd134e;font-size:10pt"><br></span></div><div><span style=3D"fon=
t-family:font0000000029fd134e;font-size:10pt">=C2=A0 =C2=A0 =C2=A0 scriptPu=
bKey: &lt;hash of the verification key&gt; &lt;scheme_id&gt; OP_ZKP=C2=A0</=
span></div><div><span style=3D"font-family:font0000000029fd134e;font-size:1=
0pt">=C2=A0 =C2=A0 =C2=A0 scriptSig:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&lt;p=
ubInput_1&gt; &lt;pubInput_2&gt; ... &lt;pubInput_n&gt; &lt;n&gt; &lt;proof=
&gt;=C2=A0</span><br></div><div><span style=3D"font-family:font0000000029fd=
134e;font-size:10pt"><br></span></div><div><span style=3D"font-family:font0=
000000029fd134e;font-size:10pt">I haven&#39;t figured out how to use OP_ZKP=
 to incentivize BRC-20, inscription etc. to move to L2. But I like to bring=
 it up here and I am open to your feedback and comments.</span></div><div><=
span style=3D"font-family:font0000000029fd134e;font-size:10pt"><br></span><=
/div><div><span style=3D"font-family:font0000000029fd134e;font-size:10pt">T=
hanks,</span></div><div><span style=3D"font-family:font0000000029fd134e;fon=
t-size:10pt">Weiji</span></div></div><br><div class=3D"gmail_quote"><div di=
r=3D"ltr" class=3D"gmail_attr">On Tue, May 9, 2023 at 8:51=E2=80=AFPM Erik =
Aronesty via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto">I would l=
ike to point out that I&#39;m not an advocate for doing anything at this po=
int aside from working on l2<div dir=3D"auto"><br></div><div dir=3D"auto">j=
ust to make it inconvenient for people</div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">I just think the discussion of outputs and fees is interesti=
ng and related to the game theory portion of Bitcoin</div><div dir=3D"auto"=
><br></div><div dir=3D"auto"><br></div></div><br><div class=3D"gmail_quote"=
><div dir=3D"ltr" class=3D"gmail_attr">On Tue, May 9, 2023, 8:23 AM Jarosla=
w via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
Ok, I need to highlight one important thing well proven by this discussion =
(like it or not)...<br>
<br>
Not the spam itself is the real reason of feeling: &quot;something must be =
done&quot;<br>
The reason is: $30 fee per transaction (I hope you all agree)<br>
<br>
<br>
Let me paraphrase some quotes used in this discussion, then:<br>
<br>
1. Lack of block subsidy long term and necessity of $40 tx fee to compensat=
e it - &quot;threaten the smooth and normal use of the Bitcoin network as a=
 peer-to-pear digital currency, as it was intended to be used as.&quot;<br>
<br>
2. &quot;the harmony of Bitcoin transactions is being disrupted right now&q=
uot; due to lack of block subsidy and due to exorbitant $40 tx fees as an e=
ffect necessary to keep the network security untouched<br>
<br>
3. &quot;Fee spikes aren&#39;t fun&quot; and it&#39;s obvious that keeping =
the network security only on enormous tx fees of active users and having pa=
ssive users as free-riders - isn&#39;t fun, too<br>
<br>
4. by ignoring Bitcoin long-term security budget problem - &quot;we indirec=
tly allowed this to happen, which previously wasn&#39;t possible before. So=
 we also have a responsibility to do something to ensure that this kind of =
tremendous $40 tx fees can never happen again&quot;<br>
<br>
5. &quot;Action against exorbitant fees should have been taken months ago. =
(...) It&#39;s a mistake that the&quot; tail emission or other necessary so=
lution - weren&#39;t implemented on time<br>
<br>
6. &quot;we need to find a solution for long-term horrible fees problem - t=
hat fits everyone&#39;s common ground.&quot;<br>
<br>
<br>
Yes, we need - instead of being still in a heavy denial state.<br>
<br>
No additional comment then, except this little one:<br>
Delay of halving in case of 4 years long network difficulty regression situ=
ation.<br>
<br>
<br>
Regards,<br>
Jaroslaw<br>
<br>
<br>
<br>
<br>
<br>
W dniu 2023-05-09 00:37:57 u=C5=BCytkownik Luke Dashjr via bitcoin-dev &lt;=
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer"=
 target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; napisa=C5=
=82:<br>
<br>
Action should have been taken months ago. Spam filtration has been a standa=
rd part of Bitcoin Core since day 1. It&#39;s a mistake that the existing f=
ilters weren&#39;t extended to Taproot transactions. We can address that, o=
r try a more narrow approach like OP_RETURN (ie, what &quot;Ordisrespector&=
quot; does). Since this is a bugfix, it doesn&#39;t really even need to wai=
t for a major release.<br>
<br>
(We already have pruning. It&#39;s not an alternative to spam filtering.)<b=
r>
<br>
Luke<br>
<br>
<br>
<br>
<br>
On 5/7/23 13:22, Ali Sherief via bitcoin-dev wrote:<br>
Hi guys,<br>
<br>
<br>
I think everyone on this list knows what has happened to the Bitcoin mempoo=
l during the past 96 hours. Due to side projects such as BRC-20 having such=
 a high volume, real bitcoin transactions are being priced out and that is =
what is causing the massive congestion that has arguable not been seen sinc=
e December 2017. I do not count the March 2021 congestion because that was =
only with 1-5sat/vbyte.<br>
<br>
<br>
Such justifiably worthless (&quot;worthless&quot; is not even my word - tha=
t&#39;s how its creator described them[1]) tokens threaten the smooth and n=
ormal use of the Bitcoin network as a peer-to-pear digital currency, as it =
was intended to be used as.<br>
<br>
<br>
If the volume does not die down over the next few weeks, should we take an =
action? The bitcoin network is a triumvirate of developers, miners, and use=
rs. Considering that miners are largely the entities at fault for allowing =
the system to be abused like this, the harmony of Bitcoin transactions is b=
eing disrupted right now. Although this community has a strong history of n=
ot putting its fingers into pies unless absolutely necessary - an example b=
eing during the block size wars and Segwit - should similar action be taken=
 now, in the form of i) BIPs and/or ii) commits into the Bitcoin Core codeb=
ase, to curtail the loophole in BIP 342 (which defines the validation rules=
 for Taproot scripts) which has allowed these unintended consequences?<br>
<br>
<br>
An alternative would be to enforce this &quot;censorship&quot; at the node =
level and introduce a run-time option to instantly prune all non-standard T=
aproot transactions. This will be easier to implement, but won&#39;t hit th=
e road until minimum next release.<br>
<br>
<br>
I know that some people will have their criticisms about this, absolutists/=
libertarians/maximum-freedom advocates, which is fine, but we need to find =
a solution for this that fits everyone&#39;s common ground. We indirectly a=
llowed this to happen, which previously wasn&#39;t possible before. So we a=
lso have a responsibility to do something to ensure that this kind of conge=
stion can never happen again using Taproot.<br>
<br>
<br>
-Ali<br>
<br>
<br>
---<br>
<br>
<br>
[1]:=C2=A0<a href=3D"https://www.coindesk.com/consensus-magazine/2023/05/05=
/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/" rel=3D"nore=
ferrer noreferrer" target=3D"_blank">https://www.coindesk.com/consensus-mag=
azine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-toke=
ns/</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer"=
 target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer"=
 target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000008a5ce505fb4e2f92--