path: root/48/81b82be6f2318f3f2cec73f14793f0404c30a3

Return-Path: <keagan.mcclelland@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 3C39BC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Mar 2021 19:12:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 1678243262
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Mar 2021 19:12:22 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level: 
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5
 tests=[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_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id UYDiW60QBx0h
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Mar 2021 19:12:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com
 [IPv6:2a00:1450:4864:20::435])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 680E842FC2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Mar 2021 19:12:20 +0000 (UTC)
Received: by mail-wr1-x435.google.com with SMTP id d11so28882681wrj.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 04 Mar 2021 11:12:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=V7JMx/EmG/hace2nBCgjrY933d0+0PmZKSLwYzzQvcA=;
 b=ajK1vxxEiUZMmwsXfrK6xappe0KCCDVFTRT42Jeo37a9z4dN64d7dtpWImGVsefZpY
 fYFsR3RKKa/BOZ+cpsyWliQetHv4Ric6sDsSn9xR3WL8mnFfHrgKnYDVRjo47mL08h3A
 Hjpzd5I9FkEYwXqEA+jrcHVVG2SNOcY4Yg9Js9lBy2IqdBVLnNx0aFZgnTLghuhL4LzK
 2Ruu+VWc/1DCqkUjo4j9svcxjAGxL0azqhh6Sl648vAHQvAVOtX04Gue96sfMs3p/9hH
 uTwhkUj74QFoJWk2iyKtgJUPlAz1Z/7xeIMotVpd3QaGPaBIVh2lk8dBoIRITFarg+1o
 H8fg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=V7JMx/EmG/hace2nBCgjrY933d0+0PmZKSLwYzzQvcA=;
 b=ttcQ0QeXKXnfMjM9QGv94gO6Vc3pPxBZv5hvguCQmDsrgkbxh6D4itC9wtTJG6w+Tt
 VQDPKIWP8VbMrfybf4YLcAhCrYSrAZ06IfX91bIauzpb3Y+cWcnnr6uSMZP8lWC6+rGO
 7hewpf2OAgyIJ3duyVSvUMHZniCc0hbOnU/9seHu9F1Fj0tlXuQi/rww9akbd+2Q2yBE
 4LR3KCRvbshEsHBExhRgYJqAO4kCb7i1Mwo600cIpeo2g/gO1t4SPZDREJXQkALmcSLl
 hFwcrc9s3AJ5XMm9k7R20gblNEYI4Df8KJtPEpicgDh1EZ/EgRY/+psPwPe0Y/oGK9bz
 rDjg==
X-Gm-Message-State: AOAM5332mk4JdweU3oG+GAiA7Sc8x3N31OA9jB3JVPJ3FeGa2Gwe7OOX
 yUbMdpxNZBbuYz7nyxjaVl3LcgxAwu03+rW15OmrfAdKHu0=
X-Google-Smtp-Source: ABdhPJxsNpuWhBAD8LbGl9e04inNGIqIh0yAJjDMWOR4G4QxYt8UNrPYS2Dxm2qN0qRv42wLlJ+2je4EJ1mDghZmykM=
X-Received: by 2002:a5d:4e85:: with SMTP id e5mr5537962wru.218.1614882212892; 
 Thu, 04 Mar 2021 10:23:32 -0800 (PST)
MIME-Version: 1.0
References: <3286a7eb-9deb-77d6-4527-58e0c5882ae2@riseup.net>
 <CAMZUoKkWmdwi-VH3WUvFfG+5MDK3xhvZUac3eBQbxXX_b_btWw@mail.gmail.com>
 <4947b02e-90fb-9044-4552-767de805ff14@mattcorallo.com>
 <CAMZUoKmTL+2GMpv8Qr5uOUC2bMgyuzMPw1zjdjuD+XNE23-65A@mail.gmail.com>
In-Reply-To: <CAMZUoKmTL+2GMpv8Qr5uOUC2bMgyuzMPw1zjdjuD+XNE23-65A@mail.gmail.com>
From: Keagan McClelland <keagan.mcclelland@gmail.com>
Date: Thu, 4 Mar 2021 11:23:21 -0700
Message-ID: <CALeFGL2oh5WZi0y64Q0-FjANE8W3GoBrXFNo=9a1OpjcssT30w@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000a751f905bcba108e"
X-Mailman-Approved-At: Thu, 04 Mar 2021 19:32:48 +0000
Subject: Re: [bitcoin-dev] Making the case for flag day activation of taproot
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, 04 Mar 2021 19:12:22 -0000

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

As one of the folks that prefers LOT=3Dtrue I can certainly attest to the
fact that at least some of us would be willing to do a flag day activation
instead. As far as I'm concerned, flag day does not give a very small
percentage of the user base (5-10% of minerz) the ability to veto a change
that has broad support and is non-invasive.

However, I must question the incongruence between those who oppose LOT=3Dtr=
ue
and support a possible flag day activation. In my mind, all that LOT=3Dtrue
does is concatenate a flag day activation after a LOT=3Dfalse deployment,
where, as Russell noted, activation is an idempotent operation.

So that leads me to believe here that the folks who oppose LOT=3Dtrue
primarily have an issue with forced signaling, which personally I don't
care about as much, not the idea of committing to a UASF from the get go.

More generally, I want to remind everyone that this is a change everyone
supports (so far). So letting the activation method kill the proposal
altogether would be tragic. If those with specific objections to various
activation methods can be clear about what those objections are, and, even
better, suggest small adjustments to various proposals on those grounds, I
think we have a far more optimistic path forward on getting Taproot
activated. Bitcoin may not have voting, but it certainly can have
compromise to come to consensus on these things. I don't think anyone in
the UASF crowd is impatient with respect to the actual guaranteed
activation timeline, what I get the sense of is a burnout on the arguments,
paired with no action. To the degree that we can make progress on coming to
an agreement that makes people comfortable, even if you don't get
everything you want, I think.

Keagan

On Thu, Mar 4, 2021 at 11:04 AM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Appologies as I've rearranged your comments in my reply.
>
> On Wed, Mar 3, 2021 at 5:14 PM Matt Corallo <lf-lists@mattcorallo.com>
> wrote:
>
>>
>> On 3/3/21 14:08, Russell O'Connor via bitcoin-dev wrote:
>>
> > After a normal and successful Core update with LOT=3Dfalse, we will hav=
e
>> more data showing broad community support for the
>> > taproot upgrade in hand.
>>
>> I think this is one of the strongest arguments against a flag day
>> activation, but, as I described in more detail in the
>> thread "Straight Flag Day (Height) Taproot Activation", I'm not sure we
>> aren't there enough already.
>>
>
> I agree with you.  I also think we have plenty of evidence to proceed wit=
h
> taproot and could proceed with a PR for such a flag day activation.  If
> there is support for it to be merged, that would be fantastic.  I think w=
e
> should proceed along these lines forthwith.
>
> However, the existence and/or release of a flag day activation code does
> not in of itself preclude concurrently developing and/or releasing a BIP8
> LOT=3Dfalse deployment.  Activating taproot is "idempotent" after all. We
> could even do a Core release with a flag day activation while we continue
> to discuss BIP8 LOT=3Dfalse if that gets the ball rolling.  Certainly hav=
ing
> a flag day activation code merged would take a lot of pressure off furthe=
r
> BIP8 LOT=3Dfalse work.
>
> As Aaron noted on IRC, if the sticking point here is the MUST_SIGNAL
> state, then running BIP8 LOT=3Dfalse alongside a flag day activation at
> timeout may be the way to go.  Once a flag day deployment is released, th=
e
> LOT=3Dtrue people would have their guaranteed activation and would be les=
s
> interested in an alternative client. And without a MUST_SIGNAL state, I
> believe the LOT=3Dfalse deployment won't lead any hashpower that is follo=
wing
> standardness rules to create invalid blocks.
>
>
>> > In the next release, 6 months later or so, Core could then confidently
>> deploy a BIP8 LOT=3Dtrue
>>
>> Could you clarify what an acceptable timeline is, then? Six months from
>> release of new consensus rules to activation (in
>> the case of a one-year original window) seems incredibly agressive for a
>> flag-day activation, let alone one with
>> forced-signaling, which would require significantly higher level of
>> adoption to avoid network split risk. In such a
>> world, we'd probably get Taproot faster with a flag day from day one.
>>
>
> Whatever timeline people are in favour of.  I think having a year or more
> between the LOT=3Dtrue or flag day more and the anticipated second releas=
e
> date is fair myself.
> That would suggest a 2-year timeout from the start to give plenty of room=
.
>
> Of course, if we start with a flag day from the start then we can just do
> 1 year and we don't need a second deployment.
>
> We could also do a "Let=E2=80=99s see what happens" with a short 3 or 4-m=
onth
> deployment and still do a follow up activation if that is more agreeable.
> That would give a net of about 1.5 years or so because we don't need to
> anticipate the second relase date.
>
> I'm good with whatever, and I'm happy to make more concrete suggestions i=
f
> that is necessary.  I think there exist acceptable timelines here.
>
>
>> > client, should it prove to be necessary.  A second Core deployment of
>> LOT=3Dtrue would mitigate some of the concerns with
>> > LOT=3Dfalse, but still provide a period beforehand to objective action=
s
>> taken by the community in support of taproot.  We
>> > don't even have to have agreement today on a second deployment of
>> LOT=3Dtrue after 6 months to start the process of a
>> > LOT=3Dfalse deployment. The later deployment will almost certainly be
>> moot, and we will have 6 months to spend debating
>> > the LOT=3Dtrue deployment versus doing a flag day activation or someth=
ing
>> else.
>>
>
>
>> That was precisely the original goal with the LOT=3Dfalse movement - do
>> something easy and avoid having to hash out all
>> the technical details of a second deployment. Sadly, that's no longer
>> tennable as a number of people are publicly
>> committed to deploying LOT=3Dtrue software on the network ASAP.
>>
>
>
>
> First things last:
>
> > Even today, I still think that starting with BIP8 LOT=3Dfalse is,
>> generally speaking, considered a reasonably safe
>> > activation method in the sense that I think it will be widely
>> considered as a "not wholly unacceptable" approach to
>> > activation.
>>
>> How do you propose avoiding divergent consensus rules on the network,
>> something which a number of commentors on this
>> list have publicly committed to?
>>
>
> Firstly, it is an open network.  Anyone can join and run whatever
> consensus rules they want.  People have run divergent consensus rules on
> the network in the past and it will continue to do so in the future.
> It is troublesome when it happens in mass, but it isn't fatal.  We can't
> prevent it, and we should continue working to keep the protocol robust in
> the face of it.
> And we certainly shouldn't be bullied by anyone who comes threatening
> their own soft-fork.
>
> Even simply doing nothing may not prevent divergent consensus from
> appearing on the network.  Playing conservative isn't playing it safe
> because there is nothing more conservative than doing nothing, which isn'=
t
> guaranteed to be safe in this sense.
>
> Secondly, for the specific concern of people running BIP8 LOT=3Dtrue
> clients, we could start with "Let=E2=80=99s see what happens" with a shor=
t 3 or 4
> month signaling period.  A short enough signaling period is not
> "hijackable".  We could add a longer LOCKED_IN period if there are worrie=
s
> about getting enough nodes upgraded in time for activation.  I see other
> options as well.
>
> I keep being told that miners are ready and willing to activate, and
> taproot will probably activate in two months. All we have to do is get
> something out the door that does that.  If taproot activates in two month=
s,
> great.  If it fails to activate we will learn so much in so little time.
> UASF's will get to say "I told you so" without waiting a year.  Users wil=
l
> get to take active, meaningful and observable steps to demonstrate their
> desire for a taproot upgrade.  Very little time will be wasted, in
> particular we don't have to finish debating how best to handle the unlike=
ly
> scenario where taproot doesn't activate right away for whatever reason th=
at
> is, an scenario that isn't even likely to occur.
>
> I'm still very optimistic.  I see multiple plausible and potentially
> acceptable paths towards activation still open and we don't even have to
> choose only one.  I can hardly wait to look at the forthcoming PRs for
> these possibilities.
>
>
>> Matt
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">As one of the folks that prefers LOT=3Dtrue I can certainl=
y attest to the fact that at least some of us would be willing to do a flag=
 day activation instead. As far as I&#39;m concerned, flag day does not giv=
e a very small percentage of the user base (5-10% of minerz) the ability to=
 veto a change that has broad support and is non-invasive.<div><br></div><d=
iv>However, I must question the incongruence between those who oppose LOT=
=3Dtrue and support a possible flag day activation. In my mind, all that LO=
T=3Dtrue does is concatenate a flag day activation after a LOT=3Dfalse depl=
oyment, where, as Russell noted, activation is an idempotent operation.</di=
v><div><br></div><div>So that leads me to believe here that the folks who o=
ppose LOT=3Dtrue primarily have an issue with forced signaling, which perso=
nally I don&#39;t care about as much, not the idea of committing to a UASF =
from the get go.</div><div><br></div><div>More generally, I want to remind =
everyone that this is a change everyone supports (so far). So letting the a=
ctivation method kill the proposal altogether would be tragic. If those wit=
h specific objections to various activation methods can be clear about what=
 those objections are, and, even better, suggest small adjustments to vario=
us proposals on those grounds, I think we have a far more optimistic path f=
orward on getting Taproot activated. Bitcoin may not have voting, but it ce=
rtainly can have compromise to come to consensus on these things. I don&#39=
;t think anyone in the UASF crowd is impatient with respect to the actual g=
uaranteed activation timeline, what I get the sense of is a burnout on the =
arguments, paired with no action. To the degree that we can make progress o=
n coming to an agreement that makes people comfortable, even if you don&#39=
;t get everything you want, I think.</div><div><br></div><div>Keagan</div><=
/div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Thu, Mar 4, 2021 at 11:04 AM Russell O&#39;Connor via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.lin=
uxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div class=3D"g=
mail_attr">Appologies as I&#39;ve rearranged your comments in my reply.<br>=
</div><div dir=3D"ltr" class=3D"gmail_attr"><br></div><div dir=3D"ltr" clas=
s=3D"gmail_attr">On Wed, Mar 3, 2021 at 5:14 PM Matt Corallo &lt;<a href=3D=
"mailto:lf-lists@mattcorallo.com" target=3D"_blank">lf-lists@mattcorallo.co=
m</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><br>
On 3/3/21 14:08, Russell O&#39;Connor via bitcoin-dev wrote:<br></blockquot=
e><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; After a normal and successful Core update with LOT=3Dfalse, we will ha=
ve more data showing broad community support for the <br>
&gt; taproot upgrade in hand.<br>
<br>
I think this is one of the strongest arguments against a flag day activatio=
n, but, as I described in more detail in the <br>
thread &quot;Straight Flag Day (Height) Taproot Activation&quot;, I&#39;m n=
ot sure we aren&#39;t there enough already.<br></blockquote><div><br></div>=
<div>I agree with you.=C2=A0 I also think we have plenty of evidence to pro=
ceed with taproot and could proceed with a PR for such a flag day activatio=
n.=C2=A0 If there is support for it to be merged, that would be fantastic.=
=C2=A0 I think we should proceed along these lines forthwith.<br></div><div=
><br></div><div>However, the existence and/or release of a flag day activat=
ion code does not in of itself preclude concurrently developing and/or rele=
asing a BIP8 LOT=3Dfalse deployment.=C2=A0 Activating taproot is &quot;idem=
potent&quot; after all. We could even do a Core release with a flag day act=
ivation while we continue to discuss BIP8 LOT=3Dfalse if that gets the ball=
 rolling.=C2=A0 Certainly having a flag day activation code merged would ta=
ke a lot of pressure off further BIP8 LOT=3Dfalse work.<br></div><div><br><=
/div><div>As Aaron noted on IRC, if the sticking point here is the MUST_SIG=
NAL state, then running BIP8 LOT=3Dfalse alongside a flag day activation at=
 timeout may be the way to go.=C2=A0 Once a flag day deployment is released=
, the LOT=3Dtrue people would have their guaranteed activation and would be=
 less interested in an alternative client. And without a MUST_SIGNAL state,=
 I believe the LOT=3Dfalse deployment won&#39;t lead any hashpower that is =
following standardness rules to create invalid blocks.<br></div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; In the next release, 6 months later or so, Core could then confidently=
 deploy a BIP8 LOT=3Dtrue <br>
<br>
Could you clarify what an acceptable timeline is, then? Six months from rel=
ease of new consensus rules to activation (in <br>
the case of a one-year original window) seems incredibly agressive for a fl=
ag-day activation, let alone one with <br>
forced-signaling, which would require significantly higher level of adoptio=
n to avoid network split risk. In such a <br>
world, we&#39;d probably get Taproot faster with a flag day from day one.<b=
r></blockquote><div>=C2=A0</div><div><div>Whatever timeline people are in f=
avour of.=C2=A0 I think having a year or more between the LOT=3Dtrue or fla=
g day more and the anticipated second release date is fair myself.</div><di=
v>That would suggest a 2-year timeout from the start to give plenty of room=
.</div><div><br></div><div>Of course, if we start with a flag day from the =
start then we can just do 1 year and we don&#39;t need a second deployment.=
</div><div><br></div><div>We could also do a &quot;Let=E2=80=99s see what h=
appens&quot; with a short 3 or 4-month deployment and still do a follow up =
activation if that is more agreeable.=C2=A0 That would give a net of about =
1.5 years or so because we don&#39;t need to anticipate the second relase d=
ate.</div><div><br></div><div>I&#39;m good with whatever, and I&#39;m happy=
 to make more concrete suggestions if that is necessary.=C2=A0 I think ther=
e exist acceptable timelines here.<br></div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex">
</blockquote></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; client, should it prove to be necessary.=C2=A0 A second Core deploymen=
t of LOT=3Dtrue would mitigate some of the concerns with <br>
&gt; LOT=3Dfalse, but still provide a period beforehand to objective action=
s taken by the community in support of taproot.=C2=A0 We <br>
&gt; don&#39;t even have to have agreement today on a second deployment of =
LOT=3Dtrue after 6 months to start the process of a <br>
&gt; LOT=3Dfalse deployment. The later deployment will almost certainly be =
moot, and we will have 6 months to spend debating <br>
&gt; the LOT=3Dtrue deployment versus doing a flag day activation or someth=
ing else.<br></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex">That was precisely the original goal with the LOT=3Dfalse=
 movement - do something easy and avoid having to hash out all <br>
the technical details of a second deployment. Sadly, that&#39;s no longer t=
ennable as a number of people are publicly <br>
committed to deploying LOT=3Dtrue software on the network ASAP.<br></blockq=
uote><div><br></div><div><br></div><div><br></div><div>First things last:<b=
r></div><div><br></div><div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">&gt; Even today, I still think that starting with BIP8 LOT=3Dfalse is, g=
enerally speaking, considered a reasonably safe <br>
&gt; activation method in the sense that I think it will be widely consider=
ed as a &quot;not wholly unacceptable&quot; approach to <br>
&gt; activation.<br>
<br>
How do you propose avoiding divergent consensus rules on the network, somet=
hing which a number of commentors on this <br>
list have publicly committed to?<br></blockquote><div><br></div><div>Firstl=
y, it is an open network.=C2=A0 Anyone can join and run whatever consensus =
rules they want.=C2=A0 People have run divergent consensus rules on the net=
work in the past and it will continue to do so in the future.<br></div><div=
>It is troublesome when it happens in mass, but it isn&#39;t fatal.=C2=A0 W=
e can&#39;t prevent it, and we should continue working to keep the protocol=
 robust in the face of it.</div><div>And we certainly shouldn&#39;t be bull=
ied by anyone who comes threatening their own soft-fork.</div><div><br></di=
v><div>Even simply doing nothing may not prevent divergent consensus from a=
ppearing on the network.=C2=A0 Playing conservative isn&#39;t playing it sa=
fe because there is nothing more conservative than doing nothing, which isn=
&#39;t guaranteed to be safe in this sense.<br></div><div><br></div><div>Se=
condly, for the specific concern of people running BIP8 LOT=3Dtrue clients,=
 we could start with &quot;Let=E2=80=99s see what happens&quot; with a shor=
t 3 or 4 month signaling period.=C2=A0 A short enough signaling period is n=
ot &quot;hijackable&quot;.=C2=A0 We could add a longer LOCKED_IN period if =
there are worries about getting enough nodes upgraded in time for activatio=
n.=C2=A0 I see other options as well.<br></div><div><br></div><div>I keep b=
eing told that miners are ready and willing to activate, and taproot will p=
robably activate in two months. All we have to do is get something out the =
door that does that.=C2=A0 If taproot activates in two months, great.=C2=A0=
 If it fails to activate we will learn so much in so little time.=C2=A0 UAS=
F&#39;s will get to say &quot;I told you so&quot; without waiting a year.=
=C2=A0 Users will get to take active, meaningful and observable steps to de=
monstrate their desire for a taproot upgrade.=C2=A0 Very little time will b=
e wasted, in particular we don&#39;t have to finish debating how best to ha=
ndle the unlikely scenario where taproot doesn&#39;t activate right away fo=
r whatever reason that is, an scenario that isn&#39;t even likely to occur.=
<br></div><div><br></div><div>I&#39;m still very optimistic.=C2=A0 I see mu=
ltiple plausible and potentially acceptable paths towards activation still =
open and we don&#39;t even have to choose only one.=C2=A0 I can hardly wait=
 to look at the forthcoming PRs for these possibilities.<br></div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">
Matt<br>
</blockquote></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>

--000000000000a751f905bcba108e--