path: root/59/955525180c86f92bda06c694560ccc38827ca7

Return-Path: <keagan.mcclelland@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 149F7C007A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 23:36:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id F0607842B9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 23:36:34 +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: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
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 XVH4wPK2pVoo
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 23:36:33 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com
 [IPv6:2a00:1450:4864:20::332])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 082C4842A9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 23:36:32 +0000 (UTC)
Received: by mail-wm1-x332.google.com with SMTP id
 r187-20020a1c44c4000000b0038ccb70e239so6859700wma.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 16:36:32 -0700 (PDT)
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=IxwX9lnzRFZxsQS1gAMtIdxnGLe01TNmNc9wAa8/Px0=;
 b=Jw+JeuH67IaQ7hjZJGPZyqQJ5KrXGmlNmU7YQaUKIVn3Ed770sAcvZFIgvjnqjePm1
 ptDkTyHgAebvS1XJvFfHSzVO0MM3szrEp7Sugld3lv2I00syDPT0QOexQLdFjRk39Y+S
 6S/GQ56NlGOPpO1SAZK914LpiMO0bblyAHMTbLkOSXwouIaBLIYUFiVzwBQgZeIw24+d
 dlqCR0D8BZxlE7X4DIj/BwMuAUVwoVzoSzvfmvM1+yUT29nbPsykwXIUQpcI7jIClcMV
 8UqcXtJjMw3RO3eBGRU+1Ieol79JVBjO/UYw0Gko3KgIOFWyg/lL+1dldaXiMFNDDqCv
 2n/A==
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=IxwX9lnzRFZxsQS1gAMtIdxnGLe01TNmNc9wAa8/Px0=;
 b=SBMhrz5zrpIrcTAr4J8teAwng+VQoJeUjiorhSQqTnISyOdChQnW9vqgEUar/jW8yt
 3OeYvLi1QrSgpQDzUmgsodQqFPbQFYOs46GYTCmdsFywl/YbAX+0/RrVjbkMD6vH+mix
 8wXLZVAuuA1TbNPPQZqqsdEXCEFqHy6NunIDpSIfJqilQHAYZ7PiNxUrFmL3kPSn6v7S
 Bcl586JTqFSceP6XAPJov1pal6ttlspvqEYT6Wr8m7OGjs5ZBe+Nog0e9BTtVsGFP2l0
 0DTZXL5TzQp6E5RRgpGzJrJIWlP9XkUmdlpc45po8MzB6o3gw+l1Fh/CLOgiPW23my+Z
 PUPA==
X-Gm-Message-State: AOAM532ftSa+KIeadFilMvGy5W4EI6VHiquJatHeLbNMVpzNTSDROyGq
 5mkba6G0F+bPotT852VSBVhLy+HSrT8RDeWs4q0ZTiMY
X-Google-Smtp-Source: ABdhPJx4apeGS/PhMt/mp7ry5s0WhZEUk+h/tCBKJ3XgphWapkt1V0Ggr86oW9V/Hwo0HddULg94x4wwVsa11i7wxGE=
X-Received: by 2002:a7b:c844:0:b0:37b:b986:7726 with SMTP id
 c4-20020a7bc844000000b0037bb9867726mr1517525wml.160.1650584191129; Thu, 21
 Apr 2022 16:36:31 -0700 (PDT)
MIME-Version: 1.0
References: <RyYBRY3MJP_0b2YkCEUFBdP8u1A_cGSEEkDbzKK9k-rkINZrBaOL70L96iHR11bJhmkhAzuN6uZ1X8PQgz2wa8Us3-2OpNa4RbhSSprw_WE=@protonmail.com>
In-Reply-To: <RyYBRY3MJP_0b2YkCEUFBdP8u1A_cGSEEkDbzKK9k-rkINZrBaOL70L96iHR11bJhmkhAzuN6uZ1X8PQgz2wa8Us3-2OpNa4RbhSSprw_WE=@protonmail.com>
From: Keagan McClelland <keagan.mcclelland@gmail.com>
Date: Thu, 21 Apr 2022 17:36:19 -0600
Message-ID: <CALeFGL1=4PrA_ziTsoS9sUjGjfLr54AiMfM99uDV-Bau5Ab_eQ@mail.gmail.com>
To: Michael Folkson <michaelfolkson@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000062599405dd329419"
X-Mailman-Approved-At: Fri, 22 Apr 2022 07:55:54 +0000
Subject: Re: [bitcoin-dev] User Resisted Soft Fork for CTV
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: Thu, 21 Apr 2022 23:36:35 -0000

--00000000000062599405dd329419
Content-Type: text/plain; charset="UTF-8"

Good day Michael,

> and discuss working on an additional release that if run may ultimately
reject blocks that signal for CTV.

This seems silly to me.

The structure of CTV is imbuing an OP_NOP with script semantics. Resisting
changes that don't affect you is not consistent with the ideals of people
being able to structure their own private agreements as they see fit...aka
freedom. It seems needlessly coercive to try and resist CTV in this way.
CTV is ultimately an opt-in proposal. If you don't like the risk/benefit
ratio, you can simply not generate scripts that contain CTV checks.
Conservatism and apathy are something I can understand, but resisting CTV
via an escalating soft fork is not conservatism or apathy, it's fundamental
opposition. What is it that you hope to accomplish by blocking others from
using a new opcode? According to your formal statement, you haven't really
opposed CTV on fundamental grounds so much as vaguely questioning whether
or not it is the "best tool for the job"...as if anyone really has the
capacity to judge that for a diverse group with varying interests and use
cases that may differ substantially from their own.

There are really two ways to effectively resist this change: 1. reject all
blocks during the lockin period, 2. reject all blocks that include OP_CTV
in the script.

Regardless of which method you choose, it is ultimately going to be a far
more forceful/invasive consensus change than CTV was in the first place. So
have fun trying to explain yourself out of that one. You've gone from
saying you won't NACK the proposal on its own to intentionally cause
consensus forks to block its enforcement. Did you change your mind or
something?

> Hence it is prudent to prepare for an eventuality where the miner
signaling threshold might be reached but the community wants to prevent the
attempted soft fork from activating. (I personally don't think a 90 percent
miner signaling threshold will be reached but I wouldn't want to bet
Bitcoin's future on it.)

Making the statement that "the community doesn't want this to activate" as
if it's some kind of foregone conclusion is a pretty bold claim. I think
you'll be surprised at how broad support actually is. To contrast your
second citation, here's the set of people who have endorsed the proposal,
along with a handful of people opposed (such as yourself):
https://utxos.org/signals/. If you are aware of others who are opposed, it
would be worth your time to solicit a statement from them that can be put
on the signals page. Absent that, it seems appropriate to assume that the
overwhelming majority of people who have opined on the subject are for it.

> But as always with Jeremy caution and conservatism seems to be thrown out
the window and we have to react to that. It goes without saying that this
is not how Bitcoin consensus changes should be attempted.

What an unhinged take. The level of effort put into gathering consensus for
CTV has set the bar higher than Taproot. Taproot didn't have the level of
outreach effort that CTV does, and the complexity in taproot is
significantly larger than for CTV. You didn't seem to have a problem
organizing that activation process. That proposal was opened for public
discussion in Jan'20, merged in Oct'20, and you were organizing activation
discussions as early as Jan'21. The design of CTV has been *final* since
Feb'20, a month after Taproot was opened for public discussion. There's a
ton of Proof-of-Concept code that has been written to test out use cases
for CTV, but for Taproot it still doesn't look like we'll have MuSig for a
while longer (I heard a year, but someone can correct me on that if I'm
wrong), and wallet support for Taproot wasn't fleshed out until after
activation. Characterizing Jeremy's efforts as throwing caution and
conservatism out the window is hypocritical at best and malicious at worst.

Finally, I think it is worth stating that if Bitcoin adopts a culture where
a willfully ignorant set of people can block changes that have no impact on
them, despite a large constituency wanting those changes, then Bitcoin kind
of deserves the slow deterioration that will result from that. I don't
really find that future appealing and so I think that trying to find ways
to activate non-invasive changes should be everyone's goal, *even if* they
personally may not have an immediate use case, or have a slight preference
for alternate solutions. The exception to this is any introduction of
systemic risk. Not all soft-forks are equal, and therefore the
meta-consensus requirements for getting them activated should vary based on
how broadly consequential the change is.

Feel free to resist this if you want. In some sense that's what the Speedy
Trial procedure is for. However, I think your case would be more compelling
if you actually had some sort of affirmative argument for why CTV induces
systemic risk to non-users of the opcode. Expressing uncertainty over
whether it is the globally optimal solution (to a problem that cannot be
globally defined due to diverse interests) is not persuasive to me and many
others in the community.

Keagan

On Thu, Apr 21, 2022 at 12:16 PM Michael Folkson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Ok so we've had to scramble a bit as I don't think anyone except perhaps
> Jeremy thought that there would be a Speedy Trial signaling period for a
> CTV soft fork planned to start on May 5th [1]. That is two weeks away.
>
> (I have to take what he says at face value. I can understand why one would
> be skeptical.)
>
> Understandably this has angered and surprised a few people including some
> of those who have voiced opposition to a CTV soft fork activation being
> attempted in the first place [2].
>
> As I've said in a previous post [3] the Bitcoin Core 23.0 release
> candidate (and older versions) does not include any CTV code or CTV
> activation code. If a miner runs Bitcoin Core 23.0 out the box it will not
> signal for CTV. If by some chance CTV was to activate through some other
> software release Bitcoin Core releases would not apply CTV rules but they
> also wouldn't reject blocks that apply CTV rules. Hence it is prudent to
> prepare for an eventuality where the miner signaling threshold might be
> reached but the community wants to prevent the attempted soft fork from
> activating. (I personally don't think a 90 percent miner signaling
> threshold will be reached but I wouldn't want to bet Bitcoin's future on
> it.)
>
> I've tentatively labelled this effort a User Resisted Soft Fork (URSF) but
> I'm open to better names. I certainly don't want to discourage those who
> dislike or oppose UASFs from contributing to this effort and potentially
> ultimately running a URSF release. If you don't want this rushed CTV soft
> fork to activate we are all on the same side whatever we call it.
>
> For now I've set up a ##ursf channel on Libera IRC to monitor developments
> and discuss working on an additional release that if run may ultimately
> reject blocks that signal for CTV.
>
> The intention of this would be to provide additional direction and
> incentive to miners that the community does not want this soft fork to be
> activated. To repeat running a Bitcoin Core release will not signal for a
> CTV soft fork out the box. If a miner runs a Bitcoin Core release it will
> not signal for CTV.
>
> Apologies that this is rushed. But as always with Jeremy caution and
> conservatism seems to be thrown out the window and we have to react to
> that. It goes without saying that this is not how Bitcoin consensus changes
> should be attempted.
>
> [1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
> [2]:
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
> [3]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>Good day Michael,</div><span style=3D"color:rgb(80,0,=
80)"><div><br></div><div><span style=3D"font-family:arial;font-size:14px">&=
gt; and discuss working on an additional release that if run may ultimately=
 reject blocks that signal for CTV.</span><br></div><div><br></div></span>T=
his seems silly to me.<br><br>The structure of CTV is imbuing an OP_NOP wit=
h script semantics. Resisting changes that don&#39;t affect you is not cons=
istent with the ideals of people being able to structure their own private =
agreements as they see fit...aka freedom. It seems needlessly coercive to t=
ry and resist CTV in this way. CTV is ultimately an opt-in proposal. If you=
 don&#39;t like the risk/benefit ratio, you can simply not generate scripts=
 that contain CTV checks. Conservatism and apathy are something I can under=
stand, but resisting CTV via an escalating soft fork is not conservatism or=
 apathy, it&#39;s fundamental opposition. What is it that you hope to accom=
plish by blocking others from using a new opcode? According to your formal =
statement, you haven&#39;t really opposed CTV on fundamental grounds so muc=
h as vaguely questioning whether or not it is the &quot;best tool for the j=
ob&quot;...as if anyone really has the capacity to judge that for a diverse=
 group with varying interests and use cases that may differ substantially f=
rom their own.<div><div><br></div><div>There are really two ways to effecti=
vely resist this change: 1. reject all blocks during the lockin period, 2. =
reject all blocks that include OP_CTV in the script.<br><div><br></div><div=
>Regardless of which method you choose, it is ultimately going to be a far =
more forceful/invasive consensus change than CTV was in the first place. So=
 have fun trying to explain yourself out of that one. You&#39;ve gone from =
saying you won&#39;t NACK the proposal on its own to intentionally cause co=
nsensus forks to block its enforcement. Did you change your mind or somethi=
ng?</div><span style=3D"color:rgb(80,0,80)"><div><br></div><div>&gt;=C2=A0<=
span style=3D"font-family:arial;font-size:14px">Hence it is prudent to prep=
are for an eventuality where the miner signaling threshold might be reached=
 but the community wants to prevent the attempted soft fork from activating=
. (I personally don&#39;t think a 90 percent miner signaling threshold will=
 be reached but I wouldn&#39;t want to bet Bitcoin&#39;s future on it.)</sp=
an></div><div><span style=3D"font-family:arial;font-size:14px"><br></span><=
/div></span><div>Making the statement that &quot;the community doesn&#39;t =
want this to activate&quot; as if it&#39;s some kind of foregone conclusion=
 is a pretty bold claim. I think you&#39;ll be surprised at how broad suppo=
rt actually is. To contrast your second citation, here&#39;s the set of peo=
ple who have endorsed the proposal, along with a handful of people opposed =
(such as yourself):=C2=A0<a href=3D"https://utxos.org/signals/" target=3D"_=
blank">https://utxos.org/signals/</a>. If you are aware of others who are o=
pposed, it would be worth your time to solicit a statement from them that c=
an be put on the signals page. Absent that, it seems appropriate to assume =
that the overwhelming majority of people who have opined on the subject are=
 for it.<br></div><span style=3D"color:rgb(80,0,80)"><div><br></div><div>&g=
t;=C2=A0<span style=3D"font-family:arial;font-size:14px">But as always with=
 Jeremy caution and conservatism seems to be thrown out the window and we h=
ave to react to that. It goes without saying that this is not how Bitcoin c=
onsensus changes should be attempted.</span></div><div style=3D"font-family=
:arial;font-size:14px"><br></div></span><div style=3D"font-family:arial;fon=
t-size:14px">What an unhinged take. The level of effort put into gathering =
consensus for CTV has set the bar higher than Taproot. Taproot didn&#39;t h=
ave the level of outreach effort that CTV does, and the complexity in tapro=
ot is significantly larger than for CTV. You didn&#39;t seem to have a prob=
lem organizing that activation process. That proposal was opened for public=
 discussion in Jan&#39;20, merged in Oct&#39;20, and you were organizing ac=
tivation discussions as early as Jan&#39;21. The design of CTV has been *fi=
nal* since Feb&#39;20, a month after Taproot was opened for public discussi=
on. There&#39;s a ton of Proof-of-Concept code that has been written to tes=
t out use cases for CTV, but for Taproot it still doesn&#39;t look like we&=
#39;ll have MuSig for a while longer (I heard a year, but someone can corre=
ct me on that if I&#39;m wrong), and wallet support for Taproot wasn&#39;t =
fleshed out until after activation. Characterizing Jeremy&#39;s efforts as =
throwing caution and conservatism out the window is hypocritical at best an=
d malicious at worst.</div><div style=3D"font-family:arial;font-size:14px">=
<br></div><div>Finally, I think it is worth stating that if Bitcoin adopts =
a culture where a willfully ignorant set of people can block changes that h=
ave no impact on them, despite a large constituency wanting those changes, =
then Bitcoin kind of deserves the slow deterioration that will result from =
that. I don&#39;t really find that future appealing and so I think that try=
ing to find ways to activate non-invasive changes should be everyone&#39;s =
goal, *even if* they personally may not have an immediate use case, or have=
 a slight preference for alternate solutions. The exception to this is any =
introduction of systemic risk. Not all soft-forks are equal, and therefore =
the meta-consensus requirements for getting them activated should vary base=
d on how broadly consequential the change is.</div><div><br></div><div>Feel=
 free to resist this if you want. In some sense that&#39;s what the Speedy =
Trial procedure is for. However, I think your case would be more compelling=
 if you actually had some sort of affirmative argument for why CTV induces =
systemic risk to non-users of the opcode. Expressing uncertainty over wheth=
er it is the globally optimal solution (to a problem that cannot be globall=
y defined due to diverse=C2=A0interests) is not persuasive to me and many o=
thers in the community.</div><font color=3D"#888888"><div><br></div><div>Ke=
agan</div></font></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">On Thu, Apr 21, 2022 at 12:16 PM Michael Folkson via=
 bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t=
arget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></=
div><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 style=3D"font-fa=
mily:arial;font-size:14px">Ok so we&#39;ve had to scramble a bit as I don&#=
39;t think anyone except perhaps Jeremy thought that there would be a Speed=
y Trial signaling period for a CTV soft fork planned to start on May 5th [1=
]. That is two weeks away.</div><div style=3D"font-family:arial;font-size:1=
4px"><br></div><div style=3D"font-family:arial;font-size:14px">(I have to t=
ake what he says at face value. I can understand why one would be skeptical=
.)</div><div style=3D"font-family:arial;font-size:14px"><br></div><div styl=
e=3D"font-family:arial;font-size:14px">Understandably this has angered and =
surprised a few people including some of those who have voiced opposition t=
o a CTV soft fork activation being attempted in the first place [2].</div><=
div style=3D"font-family:arial;font-size:14px"><br></div><div style=3D"font=
-family:arial;font-size:14px">As I&#39;ve said in a previous post [3] the B=
itcoin Core 23.0 release candidate (and older versions) does not include an=
y CTV code or CTV activation code. If a miner runs Bitcoin Core 23.0 out th=
e box it will not signal for CTV. If by some chance CTV was to activate thr=
ough some other software release Bitcoin Core releases would not apply CTV =
rules but they also wouldn&#39;t reject blocks that apply CTV rules. Hence =
it is prudent to prepare for an eventuality where the miner signaling thres=
hold might be reached but the community wants to prevent the attempted soft=
 fork from activating. (I personally don&#39;t think a 90 percent miner sig=
naling threshold will be reached but I wouldn&#39;t want to bet Bitcoin&#39=
;s future on it.)</div><div style=3D"font-family:arial;font-size:14px"><br>=
</div><div style=3D"font-family:arial;font-size:14px">I&#39;ve tentatively =
labelled this effort a User Resisted Soft Fork (URSF) but I&#39;m open to b=
etter names. I certainly don&#39;t want to discourage those who dislike or =
oppose UASFs from contributing to this effort and potentially ultimately ru=
nning a URSF release. If you don&#39;t want this rushed CTV soft fork to ac=
tivate we are all on the same side whatever we call it.</div><div style=3D"=
font-family:arial;font-size:14px"><br></div><div style=3D"font-family:arial=
;font-size:14px">For now I&#39;ve set up a ##ursf channel on Libera IRC to =
monitor developments and discuss working on an additional release that if r=
un may ultimately reject blocks that signal for CTV.</div><div style=3D"fon=
t-family:arial;font-size:14px"><br></div><div style=3D"font-family:arial;fo=
nt-size:14px">The intention of this would be to provide additional directio=
n and incentive to miners that the community does not want this soft fork t=
o be activated. To repeat running a Bitcoin Core release will not signal fo=
r a CTV soft fork out the box. If a miner runs a Bitcoin Core release it wi=
ll not signal for CTV.</div><div style=3D"font-family:arial;font-size:14px"=
><br></div><div style=3D"font-family:arial;font-size:14px">Apologies that t=
his is rushed. But as always with Jeremy caution and conservatism seems to =
be thrown out the window and we have to react to that. It goes without sayi=
ng that this is not how Bitcoin consensus changes should be attempted.</div=
><div style=3D"font-family:arial;font-size:14px"><br></div><div style=3D"fo=
nt-family:arial;font-size:14px">[1]:=C2=A0<span><a rel=3D"noreferrer nofoll=
ow noopener" href=3D"https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/=
" target=3D"_blank">https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/<=
/a></span></div><div style=3D"font-family:arial;font-size:14px">[2]:=C2=A0<=
span><a rel=3D"noreferrer nofollow noopener" href=3D"https://gist.github.co=
m/michaelfolkson/352a503f4f9fc5de89af528d86a1b718" target=3D"_blank">https:=
//gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718</a></span=
></div><div style=3D"font-family:arial;font-size:14px">[3]:=C2=A0<span><a r=
el=3D"noreferrer nofollow noopener" href=3D"https://lists.linuxfoundation.o=
rg/pipermail/bitcoin-dev/2022-April/020235.html" target=3D"_blank">https://=
lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html</a><=
/span></div><div style=3D"font-family:arial;font-size:14px"><br></div>
<div style=3D"font-family:arial;font-size:14px">
    <div>
        <div style=3D"font-family:arial;font-size:14px"><span style=3D"colo=
r:rgb(38,42,51);font-style:normal;font-weight:400;letter-spacing:normal;tex=
t-indent:0px;text-transform:none;white-space:pre-wrap;word-spacing:0px;back=
ground-color:rgb(255,255,255);float:none;display:inline"><span style=3D"fon=
t-family:SFMono-Regular,Consolas,&quot;Liberation Mono&quot;,Menlo,monospac=
e,monospace"><span style=3D"font-size:14px">--<br>Michael Folkson<br>Email:=
 michaelfolkson at </span></span></span><a href=3D"http://protonmail.com/" =
style=3D"line-height:normal;text-decoration:underline;font-family:SFMono-Re=
gular,Consolas,&quot;Liberation Mono&quot;,Menlo,monospace,monospace;font-s=
ize:14px;font-style:normal;font-weight:400;letter-spacing:normal;text-inden=
t:0px;text-transform:none;white-space:pre-wrap;word-spacing:0px" rel=3D"noo=
pener noreferrer" target=3D"_blank">protonmail.com</a><span style=3D"color:=
rgb(38,42,51);font-style:normal;font-weight:400;letter-spacing:normal;text-=
indent:0px;text-transform:none;white-space:pre-wrap;word-spacing:0px;backgr=
ound-color:rgb(255,255,255);float:none;display:inline"><span style=3D"font-=
family:SFMono-Regular,Consolas,&quot;Liberation Mono&quot;,Menlo,monospace,=
monospace"><span style=3D"font-size:14px"> </span></span></span><br></div><=
div style=3D"font-family:arial;font-size:14px"><span style=3D"color:rgb(38,=
42,51);font-style:normal;font-weight:400;letter-spacing:normal;text-indent:=
0px;text-transform:none;white-space:pre-wrap;word-spacing:0px;background-co=
lor:rgb(255,255,255);float:none;display:inline"><span style=3D"font-family:=
SFMono-Regular,Consolas,&quot;Liberation Mono&quot;,Menlo,monospace,monospa=
ce"><span style=3D"font-size:14px">Keybase: michaelfolkson<br>PGP: 43ED C99=
9 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3</span></span></span><br></div>
    </div>

            <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>

--00000000000062599405dd329419--