summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorBilly Tetrud <billy.tetrud@gmail.com>2022-03-11 10:26:21 -0600
committerbitcoindev <bitcoindev@gnusha.org>2022-03-11 16:26:41 +0000
commitdbfeaa99e127a0638980e0080558d122b1f1f8da (patch)
treeff2c84b845633475f3e8eb9c0f34e4beb6dff4e8
parent47cded49c710e6fabd351b2dbae3b3cde33fbb58 (diff)
downloadpi-bitcoindev-dbfeaa99e127a0638980e0080558d122b1f1f8da.tar.gz
pi-bitcoindev-dbfeaa99e127a0638980e0080558d122b1f1f8da.zip
Re: [bitcoin-dev] Speedy Trial
-rw-r--r--19/b90691a344352b378af34c32cd8cc12e3d9a60345
1 files changed, 345 insertions, 0 deletions
diff --git a/19/b90691a344352b378af34c32cd8cc12e3d9a60 b/19/b90691a344352b378af34c32cd8cc12e3d9a60
new file mode 100644
index 000000000..e3e565297
--- /dev/null
+++ b/19/b90691a344352b378af34c32cd8cc12e3d9a60
@@ -0,0 +1,345 @@
+Return-Path: <fresheneesz@gmail.com>
+Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
+ by lists.linuxfoundation.org (Postfix) with ESMTP id 83384C000B
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 11 Mar 2022 16:26:41 +0000 (UTC)
+Received: from localhost (localhost [127.0.0.1])
+ by smtp3.osuosl.org (Postfix) with ESMTP id 80CF360A8B
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 11 Mar 2022 16:26:41 +0000 (UTC)
+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
+Authentication-Results: smtp3.osuosl.org (amavisd-new);
+ dkim=pass (2048-bit key) header.d=gmail.com
+Received: from smtp3.osuosl.org ([127.0.0.1])
+ by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
+ with ESMTP id XqsybBE9p6QN
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 11 Mar 2022 16:26:40 +0000 (UTC)
+X-Greylist: whitelisted by SQLgrey-1.8.0
+Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
+ [IPv6:2a00:1450:4864:20::632])
+ by smtp3.osuosl.org (Postfix) with ESMTPS id D6A2360A75
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 11 Mar 2022 16:26:39 +0000 (UTC)
+Received: by mail-ej1-x632.google.com with SMTP id qt6so20161499ejb.11
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 11 Mar 2022 08:26:39 -0800 (PST)
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
+ h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
+ bh=NiU2i34WiE+NiP+APfmYFe0DYfFPM2/qfuSlNsh0sto=;
+ b=OwdR8zKYMrkgrTeG2LWX0x7sSNrUeo1UL56s7nZGEPVpZMJ2OsQ+py82fTo3d8LG02
+ ZTZ1W5oneh8EdKR1Upg6yDg8Kmf+04iRVX42bY5UdlELOYfS6v/9V8K+A+mBAlM9vuNT
+ uUa0UdIo2HjxlJ36IudxR3xBNqutoT7BBters166HafVQJ4fZKEsoTCFUn3hrPwSJTX9
+ 9/cjWUO4kzzEdCceGfvazM2FeXtYXz0h0wxOvKt41cfRJSoosxAJ/fnkSzaFx5grMj7p
+ x5+jpJJFRLt8nAuhckMcGW7/w/4Y/SNAcJZVMPIudWhNsXDWYK4Qhhrn+DB7m/QdFwtv
+ OeAQ==
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+ d=1e100.net; s=20210112;
+ h=x-gm-message-state:mime-version:references:in-reply-to:from:date
+ :message-id:subject:to;
+ bh=NiU2i34WiE+NiP+APfmYFe0DYfFPM2/qfuSlNsh0sto=;
+ b=56l1Wx8AqO1AvxNUKapef3FC/GZtVKWdjZWXTJVnMSXBvRjuYIbuidYPOEGWw477eY
+ VZ1ExN+4f0DqSpb/lDBAzMdc0vugOXCwzbwMM19mVzO2JYZgLpkmf5eDi8FD1Hze04n+
+ Vg9fRD4tYuDeOHov62BVusKcPvjbBXYcDTAzgd3dVKhy1nvWh35iK/xsMdOSCVu7dcTP
+ XnP2chhwoiAY3oHlpfptOADB9/siv7Q/fNkz9STm9nohagwlWoAZyIFFnaZ3oG5zGIkN
+ RpaihSjf+rMthJDqGngT4gH+bZKcTyMxQTyXbVmK6iM1chbfdx7fy5dMmq9FSAM8/a0+
+ 6oCA==
+X-Gm-Message-State: AOAM532+u7JVxceaXNs6UK7VrZmtWobIusq5YM2JgpUFU4XXb73hkA9e
+ 6bsMUHw5O5M3MIedRUU4uLdVfDrUseJJacXDLyXebyM8
+X-Google-Smtp-Source: ABdhPJwgcG+s+7ofW2SaR+lV7aaoey5fpkRrbl+B6q5DQKX/JTVy0KjA0gfBX7FUF4dbiaP7/6WQuSIZNeE+8PBGMm0=
+X-Received: by 2002:a17:906:9741:b0:6da:c274:6b18 with SMTP id
+ o1-20020a170906974100b006dac2746b18mr9095399ejy.207.1647015997822; Fri, 11
+ Mar 2022 08:26:37 -0800 (PST)
+MIME-Version: 1.0
+References: <CAMZUoKkTDjDSgnqhYio8Lnh-yTdsNAdXbDC9RQwnN00RdbbL6w@mail.gmail.com>
+ <CABm2gDrdoD3QZ=gZ_nd7Q+AZpetX32dLON7pfdC4aAwpLRd4xA@mail.gmail.com>
+ <CAMZUoK=kpZZw++WmdRM0KTkj6dQhmtsanm9eH1TksNwypKS8Zw@mail.gmail.com>
+In-Reply-To: <CAMZUoK=kpZZw++WmdRM0KTkj6dQhmtsanm9eH1TksNwypKS8Zw@mail.gmail.com>
+From: Billy Tetrud <billy.tetrud@gmail.com>
+Date: Fri, 11 Mar 2022 10:26:21 -0600
+Message-ID: <CAGpPWDZWKF=r4fQP8+JSBaUHT9ZTFYn7RKUgApMx4sys6Cx7Xg@mail.gmail.com>
+To: "Russell O'Connor" <roconnor@blockstream.com>,
+ Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
+Content-Type: multipart/alternative; boundary="0000000000007d5d5b05d9f3cb15"
+X-Mailman-Approved-At: Fri, 11 Mar 2022 16:32:18 +0000
+Subject: Re: [bitcoin-dev] Speedy Trial
+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: Fri, 11 Mar 2022 16:26:41 -0000
+
+--0000000000007d5d5b05d9f3cb15
+Content-Type: text/plain; charset="UTF-8"
+Content-Transfer-Encoding: quoted-printable
+
+Thanks for pointing out that PR @pushd. Looks like pretty good evidence for
+what the status of consensus was around BIP8 in the last 2 years.
+
+@Jorge, I tried to engage with you on the topic of activation rules last
+year. This is where we left it
+<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019172.h=
+tml>.
+If I'm being frank, you were not clear about what you advocated for, you
+didn't seem to take the time to understand what I was advocating for and
+what I was asking you and trying to discuss with you, and you ghosted some
+of my questions to you. I think you have some ideas that are important to
+consider, but you're quite a bit more difficult to communicate with than
+the average bitcoin-dev user, and I'd suggest that if you want your
+concerns addressed, you figure out how to interact more constructively with
+people on here. You're being very defensive and adversarial. Please take a
+step back and try to be more objective. That is IHMO the best way for your
+thoughts to be heard and understood.
+
+I think involving users more in activation is a good avenue of thought for
+improving how bitcoin does soft forks. I also think the idea you brought up
+of some way for people to signal opposition is a good idea. I've suggested
+a mechanism for signature-based user polling
+<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/019022.ht=
+ml>,
+I've also suggested a mechanism
+<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019117.h=
+tml>
+where miners can actively signal for opposing a soft fork. It seems like
+there should be some common ground between us in those ideas. Where it
+seems we may perhaps unreconcilably disagree are that A. miners are users
+too and generally have interests that are important and different than most
+users, and giving them at least some mechanism to force discussion is
+appropriate, and B. chain splits are no joke and should almost never be
+possible accidentally and therefore we should make a significant effort to
+avoid them, which almost definitely means orderly coordination of miners.
+
+Do you have anything concrete you want to propose? An example mechanism?
+Are you simply here advocating your support for BIP8+LOT=3Dtrue?
+
+
+On Fri, Mar 11, 2022 at 7:47 AM Russell O'Connor via bitcoin-dev <
+bitcoin-dev@lists.linuxfoundation.org> wrote:
+
+> On Fri, Mar 11, 2022 at 7:18 AM Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote=
+:
+>
+>> I talked about this. But the "no-divergent-rules" faction doesn't like
+>> it, so we can pretend we have listened to this "faction" and addressed a=
+ll
+>> its concerns, I guess.
+>> Or perhaps it's just "prosectution complex", but, hey, what do I know
+>> about psychology?
+>>
+>
+> Your accusations of bad faith on the part of myself and pretty much
+> everyone else makes me disinclined to continue this discussion with you.
+> I'll reply, but if you want me to continue beyond this, then you need to
+> knock it off with the accusations.
+>
+>
+>> A major contender to the Speedy Trial design at the time was to mandate
+>>> eventual forced signalling, championed by luke-jr. It turns out that, =
+at
+>>> the time of that proposal, a large amount of hash power simply did not =
+have
+>>> the firmware required to support signalling. That activation proposal
+>>> never got broad consensus, and rightly so, because in retrospect we see
+>>> that the design might have risked knocking a significant fraction of mi=
+ning
+>>> power offline if it had been deployed. Imagine if the firmware couldn'=
+t be
+>>> quickly updated or imagine if the problem had been hardware related.
+>>>
+>>
+>> Yes, I like this solution too, with a little caveat: an easy mechanism
+>> for users to actively oppose a proposal.
+>> Luke alao talked about this.
+>> If users oppose, they should use activation as a trigger to fork out of
+>> the network by invalidating the block that produces activation.
+>> The bad scenario here is that miners want to deploy something but users
+>> don't want to.
+>> "But that may lead to a fork". Yeah, I know.
+>> I hope imagining a scenario in which developers propose something that
+>> most miners accept but some users reject is not taboo.
+>>
+>
+> This topic is not taboo.
+>
+> There are a couple of ways of opting out of taproot. Firstly, users can
+> just not use taproot. Secondly, users can choose to not enforce taproot
+> either by running an older version of Bitcoin Core or otherwise forking t=
+he
+> source code. Thirdly, if some users insist on a chain where taproot is
+> "not activated", they can always softk-fork in their own rule that
+> disallows the version bits that complete the Speedy Trial activation
+> sequence, or alternatively soft-fork in a rule to make spending from (or
+> to) taproot addresses illegal.
+>
+> As for mark, he wasn't talking about activation, but quantum computing
+>> concerns. Perhaps those have been "addressed"?
+>> I just don't know where.
+>>
+>
+> Quantum concerns were discussed. Working from memory, the arguments were
+> (1) If you are worried about your funds not being secured by taproot, the=
+n
+> don't use taproot addresses, and (2) If you are worried about everyone
+> else's funds not being quantum secure by other people choosing to use
+> taproot, well it is already too late because over 5M BTC is currently
+> quantum insecure due to pubkey reuse <
+> https://nitter.net/pwuille/status/1108091924404027392>. I think it is
+> unlikely that a quantum breakthrough will sneak up on us without time to
+> address the issue and, at the very least, warn people to move their funds
+> off of taproot and other reused addresses, if not forking in some quantum
+> secure alternative. A recent paper <
+> https://www.sussex.ac.uk/physics/iqt/wp-content/uploads/2022/01/Webber-20=
+22.pdf>
+> suggest that millions physical qubits will be needed to break EC in a day
+> with current error correction technology. But even if taproot were to be
+> very suddenly banned, there is still a small possibility for recovery
+> because one can prove ownership of HD pubkeys by providing a zero-knowled=
+ge
+> proof of the chaincode used to derive them.
+> _______________________________________________
+> bitcoin-dev mailing list
+> bitcoin-dev@lists.linuxfoundation.org
+> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
+>
+
+--0000000000007d5d5b05d9f3cb15
+Content-Type: text/html; charset="UTF-8"
+Content-Transfer-Encoding: quoted-printable
+
+<div dir=3D"ltr"><div dir=3D"ltr">Thanks for pointing out that PR @pushd. L=
+ooks like pretty good evidence=C2=A0for what the status of consensus was ar=
+ound BIP8 in the last 2 years.</div><div dir=3D"ltr"><br></div><div>@Jorge,=
+ I tried to engage with you on the topic of activation rules last year. Thi=
+s is <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/202=
+1-June/019172.html" target=3D"_blank">where we left it</a>. If I&#39;m bein=
+g frank, you were not clear about what you advocated for, you didn&#39;t se=
+em to take the time to understand what I was advocating for and what I was =
+asking you and trying to discuss with you, and you ghosted some of my quest=
+ions to you. I think you have some ideas that are important to consider, bu=
+t you&#39;re quite a bit more difficult to communicate with than the averag=
+e bitcoin-dev user, and I&#39;d suggest that if you want your concerns addr=
+essed, you figure out how to interact more constructively with people on he=
+re. You&#39;re being very defensive and adversarial. Please take a step bac=
+k and try to be more objective. That is IHMO the best way for your thoughts=
+ to be heard and understood.=C2=A0</div><div><br></div><div>I think involvi=
+ng users more in activation is a good avenue=C2=A0of thought for improving =
+how bitcoin does soft forks. I also think the idea you brought up of some w=
+ay for people to signal opposition is a good idea. I&#39;ve suggested a mec=
+hanism for <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-d=
+ev/2021-May/019022.html" target=3D"_blank">signature-based user polling</a>=
+, I&#39;ve also suggested <a href=3D"https://lists.linuxfoundation.org/pipe=
+rmail/bitcoin-dev/2021-June/019117.html" target=3D"_blank">a mechanism</a> =
+where miners can actively signal for opposing a soft fork. It seems like th=
+ere should be some common ground between us in those ideas. Where it seems =
+we may perhaps unreconcilably=C2=A0disagree are that A. miners are users to=
+o and generally have interests that are important and different than most u=
+sers, and giving them at least some mechanism to force discussion is approp=
+riate, and B. chain splits are no joke and should almost never be possible =
+accidentally and therefore we should make a significant effort to avoid the=
+m, which almost definitely means orderly coordination of miners.=C2=A0</div=
+><div><br></div><div>Do you have anything concrete you want to propose? An =
+example mechanism? Are you simply here advocating your support for BIP8+LOT=
+=3Dtrue?=C2=A0</div><div><br></div><br><div class=3D"gmail_quote"><div dir=
+=3D"ltr" class=3D"gmail_attr">On Fri, Mar 11, 2022 at 7:47 AM Russell O&#39=
+;Connor via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
+tion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; w=
+rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
+x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
+=3D"ltr"><div dir=3D"ltr"></div><div class=3D"gmail_quote"><div dir=3D"ltr"=
+ class=3D"gmail_attr">On Fri, Mar 11, 2022 at 7:18 AM Jorge Tim=C3=B3n &lt;=
+<a href=3D"mailto:jtimon@jtimon.cc" target=3D"_blank">jtimon@jtimon.cc</a>&=
+gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
+px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
+dir=3D"auto"><div dir=3D"auto">I talked about this. But the &quot;no-diverg=
+ent-rules&quot; faction doesn&#39;t like it, so we can pretend we have list=
+ened to this &quot;faction&quot; and addressed all its concerns, I guess.</=
+div><div dir=3D"auto">Or perhaps it&#39;s just &quot;prosectution complex&q=
+uot;, but, hey, what do I know about psychology? <br></div></div></blockquo=
+te><div><br></div><div>Your accusations of bad faith on the part of myself =
+and pretty much everyone else makes me disinclined to continue this discuss=
+ion with you.=C2=A0 I&#39;ll reply, but if you want me to continue beyond t=
+his, then you need to knock it off with the accusations.=C2=A0 <br></div><d=
+iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
+x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
+=3D"auto"><div dir=3D"auto"></div><div dir=3D"auto"><div class=3D"gmail_quo=
+te"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
+der-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><di=
+v dir=3D"auto">A major contender to the Speedy Trial design at the time was=
+ to mandate eventual forced signalling, championed by luke-jr.=C2=A0 It tur=
+ns out that, at the time of that proposal, a large amount of hash power sim=
+ply did not have the firmware required to support signalling.=C2=A0 That ac=
+tivation proposal never got broad consensus, and rightly so, because in ret=
+rospect we see that the design might have risked knocking a significant fra=
+ction of mining power offline if it had been deployed.=C2=A0 Imagine if the=
+ firmware couldn&#39;t be quickly updated or imagine if the problem had bee=
+n hardware related.</div></div></blockquote></div></div><div dir=3D"auto"><=
+br></div><div dir=3D"auto">Yes, I like this solution too, with a little cav=
+eat: an easy mechanism for users to actively oppose a proposal.</div><div d=
+ir=3D"auto">Luke alao talked about this.</div><div dir=3D"auto">If users op=
+pose, they should use activation as a trigger to fork out of the network by=
+ invalidating the block that produces activation.</div><div dir=3D"auto">Th=
+e bad scenario here is that miners want to deploy something but users don&#=
+39;t want to.</div><div dir=3D"auto">&quot;But that may lead to a fork&quot=
+;. Yeah, I know.</div><div dir=3D"auto">I hope imagining a scenario in whic=
+h developers propose something that most miners accept but some users rejec=
+t is not taboo.</div></div></blockquote><div><br></div><div>This topic is n=
+ot taboo.<br></div><div><br></div><div><div>There are a couple of ways of o=
+pting out of taproot.=C2=A0 Firstly, users can just=20
+not use taproot.=C2=A0 Secondly, users can choose to not enforce taproot ei=
+ther by running an older version of Bitcoin Core or otherwise forking the s=
+ource code.=C2=A0 Thirdly, if some users insist on a chain where taproot is=
+ &quot;not activated&quot;, they can always softk-fork in their own rule th=
+at disallows
+ the version bits that complete the Speedy Trial activation sequence, or al=
+ternatively soft-fork in a rule to make spending from (or to) taproot addre=
+sses illegal.<br></div><div><br></div></div><blockquote class=3D"gmail_quot=
+e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
+;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto">As for mark, he wasn=
+&#39;t talking about activation, but quantum computing concerns. Perhaps th=
+ose have been &quot;addressed&quot;?</div><div dir=3D"auto">I just don&#39;=
+t know where.</div></div></blockquote><div><br></div><div>Quantum concerns =
+were discussed.=C2=A0 Working from memory, the arguments were (1) If you ar=
+e worried about your funds not being secured by taproot, then don&#39;t use=
+ taproot addresses, and (2) If you are worried about everyone else&#39;s fu=
+nds not being quantum secure by other people choosing to use taproot, well =
+it is already too late because over 5M BTC is currently quantum insecure du=
+e to pubkey reuse &lt;<a href=3D"https://nitter.net/pwuille/status/11080919=
+24404027392" target=3D"_blank">https://nitter.net/pwuille/status/1108091924=
+404027392</a>&gt;.=C2=A0 I think it is unlikely that a quantum breakthrough=
+ will sneak up on us without time to address the issue and, at the very lea=
+st, warn people to move their funds off of taproot and other reused address=
+es, if not forking in some quantum secure alternative.=C2=A0 A recent paper=
+ &lt;<a href=3D"https://www.sussex.ac.uk/physics/iqt/wp-content/uploads/202=
+2/01/Webber-2022.pdf" target=3D"_blank">https://www.sussex.ac.uk/physics/iq=
+t/wp-content/uploads/2022/01/Webber-2022.pdf</a>&gt; suggest that millions =
+physical qubits will be needed to break EC in a day with current error corr=
+ection technology.=C2=A0 But even if taproot were to be very suddenly banne=
+d, there is still a small possibility for recovery because one can prove ow=
+nership of HD pubkeys by providing a zero-knowledge proof of the chaincode =
+used to derive them.<br></div></div></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></div>
+
+--0000000000007d5d5b05d9f3cb15--
+