path: root/83/7a645d500beac50e7f97465c09479ad1e1164c

Return-Path: <lf-lists@mattcorallo.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6A51FC000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 14:01:38 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 58A0B8655C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 14:01:38 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id yykKTTSGiPpu
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 14:01:35 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id 6EB4C862E4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 14:01:35 +0000 (UTC)
Received: by mail.as397444.net (Postfix) with ESMTPSA id A22F74A38EF;
 Thu, 18 Feb 2021 14:01:33 +0000 (UTC)
X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com;
 s=1613655663; t=1613656893;
 bh=ir24PxsONNrhNk9zmynihRjlhiy1kU1M87+kecraI2Y=;
 h=From:Subject:Date:References:Cc:In-Reply-To:To:From;
 b=k/FCCbtSrlPn2eIQ1cb8fSxr/FXkqVSHg9PaFYVq6YcQAB0BKdPNB7BFzsUwoDLVw
 +nya9SpD+U3I8myUEeVRF2NF8IPq6+9bDAVr/bRh8hOVJb0+ZqM6a2O0hCRCb+IFE4
 fuwVcRDZvdHm0pzzCDgCnt4tzA4gbAygNjJhSXjypByPFEGW8L2FCfZ5zoxxy5o4pa
 kBTYgUjuqUiH1G7iqnytmzynzOV08jvrxRCPZfzjwm2L0S7KfcjIXuyWZ4vgDkEor9
 AxmScKI143tgUbbhU5s2Qb1bzWvb9vg5iWD6f20XeWet7H2JCLwEyCbkxH5BZ8LDO+
 NGZcrCmNCFrAA==
Content-Type: multipart/alternative;
 boundary=Apple-Mail-64F839EB-5A59-4AF8-A785-6D2A8A56FE3F
Content-Transfer-Encoding: 7bit
From: Matt Corallo <lf-lists@mattcorallo.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 18 Feb 2021 09:01:32 -0500
Message-Id: <8591CF93-E574-4C23-90D5-FA410637DECD@mattcorallo.com>
References: <CAFvNmHSHu0gqVgWxOCJnSTf5mxpWsMF9FrMQ+_X+uyR3P4QCsg@mail.gmail.com>
In-Reply-To: <CAFvNmHSHu0gqVgWxOCJnSTf5mxpWsMF9FrMQ+_X+uyR3P4QCsg@mail.gmail.com>
To: Michael Folkson <michaelfolkson@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Yesterday's Taproot activation meeting on
	lockinontimeout (LOT)
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, 18 Feb 2021 14:01:38 -0000


--Apple-Mail-64F839EB-5A59-4AF8-A785-6D2A8A56FE3F
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

If the eventual outcome is that different implementations (that have materia=
l *transaction processing* userbases, and I=E2=80=99m not sure to what exten=
t that=E2=80=99s true with Knots) ship different consensus rules, we should s=
top here and not activate Taproot. Seriously.

Bitcoin is a consensus system. The absolute worst outcome at all possible is=
 to have it fall out of consensus.

Matt

> On Feb 18, 2021, at 08:11, Michael Folkson via bitcoin-dev <bitcoin-dev@li=
sts.linuxfoundation.org> wrote:
>=20
> =EF=BB=BF
> Right, that is one option. Personally I would prefer a Bitcoin Core releas=
e sets LOT=3Dfalse (based on what I have heard from Bitcoin Core contributor=
s) and a community effort releases a version with LOT=3Dtrue. I don't think u=
sers should be forced to choose something they may have no context on before=
 they are allowed to use Bitcoin Core.=20
>=20
> My current understanding is that roasbeef is planning to set LOT=3Dfalse o=
n btcd (an alternative protocol implementation to Bitcoin Core) and Luke Das=
hjr hasn't yet decided on Bitcoin Knots.
>=20
>=20
>=20
>> On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote=
:
>> Good morning all,
>>=20
>> > "An activation mechanism is a consensus change like any other change, c=
an be contentious like any other change, and we must resolve it like any oth=
er change. Otherwise we risk arriving at the darkest timeline."
>> >
>> > Who's we here?
>> >
>> > Release both and let the network decide.
>>=20
>> A thing that could be done, without mandating either LOT=3Dtrue or LOT=3D=
false, would be to have a release that requires a `taprootlot=3D1` or `tapro=
otlot=3D0` and refuses to start if the parameter is not set.
>>=20
>> This assures everyone that neither choice is being forced on users, and i=
nstead what is being forced on users, is for users to make that choice thems=
elves.
>>=20
>> Regards,
>> ZmnSCPxj
>>=20
>> >
>> > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <bitcoi=
n-dev@lists.linuxfoundation.org> wrote:
>> >
>> > > Thanks for your response Ariel. It would be useful if you responded t=
o specific points I have made in the mailing list post or at least quote the=
se ephemeral "people" you speak of. I don't know if you're responding to con=
versation on the IRC channel or on social media etc.
>> > >
>> > > > The argument comes from a naive assumption that users MUST upgrade t=
o the choice that is submitted into code. But in fact this isn't true and so=
me voices in this discussion need to be more humble about what users must or=
 must not run.
>> > >
>> > > I personally have never made this assumption. Of course users aren't f=
orced to run any particular software version, quite the opposite. Defaults s=
et in software versions matter though as many users won't change them.
>> > >
>> > > > Does no one realize that it is a very possible outcome that if LOT=3D=
true is released there may be only a handful of people that begin running it=
 while everyone else delays their upgrade (with the very good reason of not g=
etting involved in politics) and a year later those handful of people just b=
ecome stuck at the moment of MUST_SIGNAL, unable to mine new blocks?
>> > >
>> > > It is a possible outcome but the likely outcome is that miners activa=
te Taproot before LOT is even relevant. I think it is prudent to prepare for=
 the unlikely but possible outcome that miners fail to activate and hence ha=
ve this discussion now rather than be unprepared for that eventuality. If LO=
T is set to false in a software release there is the possibility (T2 in http=
s://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.htm=
l) of individuals or a proportion of the community changing LOT to true. In t=
hat sense setting LOT=3Dfalse in a software release appears to be no more sa=
fe than LOT=3Dtrue.
>> > >
>> > > > The result: a wasted year of waiting and a minority of people who d=
idn't want to be lenient with miners by default.
>> > >
>> > > There is the (unlikely but possible) possibility of a wasted year if L=
OT is set to false and miners fail to activate. I'm not convinced by this pe=
rception that LOT=3Dtrue is antagonistic to miners. I actually think it offe=
rs them clarity on what will happen over a year time period and removes the n=
eed for coordinated or uncoordinated community UASF efforts on top of LOT=3D=
false.
>> > >
>> > > > An activation mechanism is a consensus change like any other change=
, can be contentious like any other change, and we must resolve it like any o=
ther change. Otherwise we risk arriving at the darkest timeline.
>> > >
>> > > I don't know what you are recommending here to avoid "this darkest ti=
meline". Open discussions have occurred and are continuing and in my mailing=
 list post that you responded to **I recommended we propose LOT=3Dfalse be s=
et in protocol implementations such as Bitcoin Core**. I do think this apoca=
lyptic language isn't particularly helpful. In an open consensus system disc=
ussion is healthy, we should prepare for bad or worst case scenarios in adva=
nce and doing so is not antagonistic or destructive. Mining pools have pledg=
ed support for Taproot but we don't build secure systems based on pledges of=
 support, we build them to minimize trust in any human actors. We can be gra=
teful that people like Alejandro have worked hard on taprootactivation.com (=
and this effort has informed the discussion) without taking pledges of suppo=
rt as cast iron guarantees.
>> > >
>> > > TL;DR It sounds like you agree with my recommendation to set LOT=3Dfa=
lse in protocol implementations in my email :)
>> > >
>> > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <arielluaces@gma=
il.com> wrote:
>> > >
>> > > > Something what strikes me about the conversation is the emotion sur=
rounding the letters UASF.
>> > > > It appears as if people discuss UASF as if it's a massive tidal wav=
e of support that is inevitable, like we saw during segwit activation. But t=
he actual definition is "any activation that is not a MASF".
>> > > > A UASF can consist of a single node, ten nodes, a thousand, half of=
 all nodes, all business' nodes, or even all the non mining nodes. On anothe=
r dimension it can have zero mining support, 51% support, 49% support, or an=
y support right up against a miner activation threshold.
>> > > > Hell a UASF doesn't even need code or even a single node running as=
 long as it exists as a possibility in people's minds.
>> > > > The only thing a UASF doesn't have is miner support above an agreed=
 activation threshold (some number above %51).
>> > > > I say this because it strikes me when people say that they are for L=
OT=3Dtrue with the logic that since a UASF is guaranteed to happen then it's=
 better to just make it default from the beginning. Words like coordination a=
nd safety are sometimes sprinkled into the argument.
>> > > > The argument comes from a naive assumption that users MUST upgrade t=
o the choice that is submitted into code. But in fact this isn't true and so=
me voices in this discussion need to be more humble about what users must or=
 must not run.
>> > > > Does no one realize that it is a very possible outcome that if LOT=3D=
true is released there may be only a handful of people that begin running it=
 while everyone else delays their upgrade (with the very good reason of not g=
etting involved in politics) and a year later those handful of people just b=
ecome stuck at the moment of MUST_SIGNAL, unable to mine new blocks? Or attr=
acting a minority of miners, activating, and forking off into a minority for=
k. Then a lot=3Dfalse could be started that ends up activating the feature n=
ow that the stubborn option has ran its course.
>> > > > The result: a wasted year of waiting and a minority of people who d=
idn't want to be lenient with miners by default. The chains could be called B=
itcoinLenient and BitcoinStubborn.
>> > > > How is that strictly safer or more coordinated?
>> > > > I may be in the minority, or maybe a silent majority, or maybe a ma=
jority that just hasn't considered this as a choice but honestly if there is=
 contention about whether we're going to be stubborn or lenient with miners f=
or Taproot and in the future then I prefer to just not activate anything at a=
ll. I'm fine for calling bitcoin ossified, accepting that segwit is Bitcoin'=
s last network upgrade. Taproot is amazing but no new feature is worth a net=
work split down the middle.
>> > > > Maybe in 10 or 20 years, when other blockchains implement features l=
ike Taproot and many more, we will become envious enough to put aside our di=
fferences on how to behave towards miners and finally activate Taproot.
>> > > > An activation mechanism is a consensus change like any other change=
, can be contentious like any other change, and we must resolve it like any o=
ther change. Otherwise we risk arriving at the darkest timeline.
>> > > > Cheers
>> > > > Ariel Lorenzo-Luaces
>> > > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev <bitco=
in-dev@lists.linuxfoundation.org> wrote:
>> > > >
>> > > > > Yesterday (February 16th) we held a second meeting on Taproot
>> > > > > activation on IRC which again was open to all. Despite what appea=
red
>> > > > > to be majority support for LOT=3Dfalse over LOT=3Dtrue in the fir=
st
>> > > > > meeting I (and others) thought the arguments had not been explore=
d in
>> > > > > depth and that we should have a follow up meeting almost entirely=

>> > > > > focused on whether LOT (lockinontimeout) should be set to true or=

>> > > > > false.
>> > > > >
>> > > > > The meeting was announced here:
>> > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Febr=
uary/018380.html
>> > > > >
>> > > > > In that mailing list post I outlined the arguments for LOT=3Dtrue=
 (T1 to
>> > > > > T6) and arguments for LOT=3Dfalse (F1 to F6) in their strongest f=
orm I
>> > > > > could. David Harding responded with an additional argument for
>> > > > > LOT=3Dfalse (F7) here:
>> > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Febr=
uary/018415.html
>> > > > >
>> > > > > These meetings are very challenging given they are open to all, y=
ou
>> > > > > don=E2=80=99t know who will attend and you don=E2=80=99t know mos=
t people=E2=80=99s views in
>> > > > > advance. I tried to give time for both the LOT=3Dtrue arguments a=
nd the
>> > > > > LOT=3Dfalse arguments to be discussed as I knew there was support=
 for
>> > > > > both. We only tried evaluating which had more support and which h=
ad
>> > > > > more strong opposition towards the end of the meeting.
>> > > > >
>> > > > > The conversation log is here:
>> > > > > http://gnusha.org/taproot-activation/2021-02-16.log
>> > > > >
>> > > > > (If you are so inclined you can watch a video of the meeting here=
.
>> > > > > Thanks to the YouTube account =E2=80=9CBitcoin=E2=80=9D for setti=
ng up the livestream:
>> > > > > https://www.youtube.com/watch?v=3Dvpl5q1ovMLM)
>> > > > >
>> > > > > A summary of the meeting was provided by Luke Dashjr on Mastodon h=
ere:
>> > > > > https://bitcoinhackers.org/@lukedashjr/105742918779234566
>> > > > >
>> > > > > Today's #Bitcoin #Taproot meeting was IMO largely unproductive, b=
ut we
>> > > > > did manage to come to consensus on everything but LockinOnTimeout=
.
>> > > > >
>> > > > > Activation height range: 693504-745920
>> > > > >
>> > > > > MASF threshold: 1815/2016 blocks (90%)
>> > > > >
>> > > > > Keep in mind only ~100 people showed for the meetings, hardly
>> > > > > representative of the entire community.
>> > > > >
>> > > > > So, these details remain JUST a proposal for now.
>> > > > >
>> > > > > It seems inevitable that there won't be consensus on LOT.
>> > > > >
>> > > > > Everyone will have to choose for himself. :/
>> > > > >
>> > > > > Personally I agree with most of this. I agree that there wasn=E2=80=
=99t
>> > > > > overwhelming consensus for either LOT=3Dtrue or LOT=3Dfalse. Howe=
ver, from
>> > > > > my perspective there was clearly more strong opposition (what wou=
ld
>> > > > > usually be deemed a NACK in Bitcoin Core review terminology) from=

>> > > > > Bitcoin Core contributors, Lightning developers and other communi=
ty
>> > > > > members against LOT=3Dtrue than there was for LOT=3Dfalse. Andrew=
 Chow
>> > > > > tried to summarize views from the meeting in this analysis:
>> > > > > https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c=

>> > > > >
>> > > > > I am also aware of other current and previous Bitcoin Core
>> > > > > contributors and Lightning developers who didn=E2=80=99t attend t=
he meeting in
>> > > > > person who are opposed to LOT=3Dtrue. I don=E2=80=99t want to put=
 them in the
>> > > > > spotlight for no reason but if you go through the conversation lo=
gs of
>> > > > > not only the meeting but the weeks of discussion prior to this me=
eting
>> > > > > you will see their views evaluated on the ##taproot-activation
>> > > > > channel. In addition, on taprootactivation.com some mining pools
>> > > > > expressed a preference for lot=3Dfalse though I don=E2=80=99t kno=
w how strong
>> > > > > that preference was.
>> > > > >
>> > > > > I am only one voice but it is my current assessment that if we ar=
e to
>> > > > > attempt to finalize Taproot activation parameters and propose the=
m to
>> > > > > the community at this time our only option is to propose LOT=3Dfa=
lse.
>> > > > > Any further delay appears to me counterproductive in our collecti=
ve
>> > > > > aim to get the Taproot soft fork activated as early as possible.
>> > > > >
>> > > > > Obviously others are free to disagree with that assessment and
>> > > > > continue discussions but personally I will be attempting to avoid=

>> > > > > those discussions unless prominent new information comes to light=
 or
>> > > > > various specific individuals change their minds.
>> > > > >
>> > > > > Next week we are planning a code review of the Bitcoin Core PR #1=
9573
>> > > > > which was initially delayed because of this LOT discussion. As I=E2=
=80=99ve
>> > > > > said previously that will be loosely following the format of the
>> > > > > Bitcoin Core PR review club and will be lower level and more
>> > > > > technical. That is planned for Tuesday February 23rd at 19:00 UTC=
 on
>> > > > > the IRC channel ##taproot-activation.
>> > > > >
>> > > > > Thanks to the meeting participants (and those who joined the
>> > > > > discussion on the channel prior and post the meeting) for engagin=
g
>> > > > > productively and in good faith.
>> > >
>> > > --
>> > > Michael Folkson
>> > > Email: michaelfolkson@gmail.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
>>=20
>>=20
>=20
>=20
> --=20
> Michael Folkson
> Email: michaelfolkson@gmail.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

--Apple-Mail-64F839EB-5A59-4AF8-A785-6D2A8A56FE3F
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr">If the eventual outcome is=
 that different implementations (that have material *transaction processing*=
 userbases, and I=E2=80=99m not sure to what extent that=E2=80=99s true with=
 Knots) ship different consensus rules, we should stop here and not activate=
 Taproot. Seriously.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">Bitcoi=
n is a consensus system. The absolute worst outcome at all possible is to ha=
ve it fall out of consensus.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr=
">Matt</div><div dir=3D"ltr"><br><blockquote type=3D"cite">On Feb 18, 2021, a=
t 08:11, Michael Folkson via bitcoin-dev &lt;bitcoin-dev@lists.linuxfoundati=
on.org&gt; wrote:<br><br></blockquote></div><blockquote type=3D"cite"><div d=
ir=3D"ltr">=EF=BB=BF<div dir=3D"ltr">Right, that is one option. Personally I=
 would prefer a Bitcoin Core release sets LOT=3Dfalse (based on what I have h=
eard from Bitcoin Core contributors) and a community effort releases a versi=
on with LOT=3Dtrue. I don't think users should be forced to choose something=
 they may have no context on before they are allowed to use Bitcoin Core.&nb=
sp;<div><br></div><div>My current understanding is that roasbeef is planning=
 to set LOT=3Dfalse on btcd (an alternative protocol implementation to Bitco=
in Core) and Luke Dashjr hasn't yet decided on Bitcoin Knots.</div><div><div=
><br></div><div><br></div></div></div><br><div class=3D"gmail_quote"><div di=
r=3D"ltr" class=3D"gmail_attr">On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj &lt=
;<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; w=
rote:<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">Good morning=
 all,<br>
<br>
&gt; "An activation mechanism is a consensus change like any other change, c=
an be contentious like any other change, and we must resolve it like any oth=
er change. Otherwise we risk arriving at the darkest timeline."<br>
&gt;<br>
&gt; Who's we here?<br>
&gt;<br>
&gt; Release both and let the network decide.<br>
<br>
A thing that could be done, without mandating either LOT=3Dtrue or LOT=3Dfal=
se, would be to have a release that requires a `taprootlot=3D1` or `taprootl=
ot=3D0` and refuses to start if the parameter is not set.<br>
<br>
This assures everyone that neither choice is being forced on users, and inst=
ead what is being forced on users, is for users to make that choice themselv=
es.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
&gt;<br>
&gt; On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev &lt;<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitco=
in-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; Thanks for your response Ariel. It would be useful if you responde=
d to specific points I have made in the mailing list post or at least quote t=
hese ephemeral "people" you speak of. I don't know if you're responding to c=
onversation on the IRC channel or on social media etc.<br>
&gt; &gt;<br>
&gt; &gt; &gt; The argument comes from a naive assumption that users MUST up=
grade to the choice that is submitted into code. But in fact this isn't true=
 and some voices in this discussion need to be more humble about what users m=
ust or must not run.<br>
&gt; &gt;<br>
&gt; &gt; I personally have never made this assumption. Of course users aren=
't forced to run any particular software version, quite the opposite. Defaul=
ts set in software versions matter though as many users won't change them.<b=
r>
&gt; &gt;<br>
&gt; &gt; &gt; Does no one realize that it is a very possible outcome that i=
f LOT=3Dtrue is released there may be only a handful of people that begin ru=
nning it while everyone else delays their upgrade (with the very good reason=
 of not getting involved in politics) and a year later those handful of peop=
le just become stuck at the moment of MUST_SIGNAL, unable to mine new blocks=
?<br>
&gt; &gt;<br>
&gt; &gt; It is a possible outcome but the likely outcome is that miners act=
ivate Taproot before LOT is even relevant. I think it is prudent to prepare f=
or the unlikely but possible outcome that miners fail to activate and hence h=
ave this discussion now rather than be unprepared for that eventuality. If L=
OT is set to false in a software release there is the possibility (T2 in&nbs=
p;<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Fe=
bruary/018380.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linux=
foundation.org/pipermail/bitcoin-dev/2021-February/018380.html</a>) of indiv=
iduals or a proportion of the community changing LOT to true. In that sense s=
etting LOT=3Dfalse in a software release appears to be no more safe than LOT=
=3Dtrue.<br>
&gt; &gt;<br>
&gt; &gt; &gt; The result: a wasted year of waiting and a minority of people=
 who didn't want to be lenient with miners by default.<br>
&gt; &gt;<br>
&gt; &gt; There is the (unlikely but possible) possibility of a wasted year i=
f LOT is set to false and miners fail to activate. I'm not convinced by this=
 perception that LOT=3Dtrue is antagonistic to miners. I actually think it o=
ffers them clarity on what will happen over a year time period and removes t=
he need for coordinated or uncoordinated community UASF efforts on top of LO=
T=3Dfalse.<br>
&gt; &gt;<br>
&gt; &gt; &gt; An activation mechanism is a consensus change like any other c=
hange, can be contentious like any other change, and we must resolve it like=
 any other change. Otherwise we risk arriving at the darkest timeline.<br>
&gt; &gt;<br>
&gt; &gt; I don't know what you are recommending here to avoid "this darkest=
 timeline". Open discussions have occurred and are continuing and in my mail=
ing list post that you responded to **I recommended we propose LOT=3Dfalse b=
e set in protocol implementations such as Bitcoin Core**. I do think this ap=
ocalyptic language isn't particularly helpful. In an open consensus system d=
iscussion is healthy, we should prepare for bad or worst case scenarios in a=
dvance and doing so is not antagonistic or destructive. Mining pools&nbsp;ha=
ve pledged support for Taproot but we don't build secure systems based on pl=
edges of support, we build them to minimize trust in any human actors. We ca=
n be grateful that people like Alejandro have worked hard on <a href=3D"http=
://taprootactivation.com" rel=3D"noreferrer" target=3D"_blank">taprootactiva=
tion.com</a> (and this effort has informed the discussion) without taking pl=
edges of support as cast iron guarantees.<br>
&gt; &gt;<br>
&gt; &gt; TL;DR It sounds like you agree with my recommendation to set LOT=3D=
false in protocol implementations in my email :)<br>
&gt; &gt;<br>
&gt; &gt; On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces &lt;<a href=3D=
"mailto:arielluaces@gmail.com" target=3D"_blank">arielluaces@gmail.com</a>&g=
t; wrote:<br>
&gt; &gt;<br>
&gt; &gt; &gt; Something what strikes me about the conversation is the emoti=
on surrounding the letters UASF.<br>
&gt; &gt; &gt; It appears as if people discuss UASF as if it's a massive tid=
al wave of support that is inevitable, like we saw during segwit activation.=
 But the actual definition is "any activation that is not a MASF".<br>
&gt; &gt; &gt; A UASF can consist of a single node, ten nodes, a thousand, h=
alf of all nodes, all business' nodes, or even all the non mining nodes. On a=
nother dimension it can have zero mining support, 51% support, 49% support, o=
r any support right up against a miner activation threshold.<br>
&gt; &gt; &gt; Hell a UASF doesn't even need code or even a single node runn=
ing as long as it exists as a possibility in people's minds.<br>
&gt; &gt; &gt; The only thing a UASF doesn't have is miner support above an a=
greed activation threshold (some number above %51).<br>
&gt; &gt; &gt; I say this because it strikes me when people say that they ar=
e for LOT=3Dtrue with the logic that since a UASF is guaranteed to happen th=
en it's better to just make it default from the beginning. Words like coordi=
nation and safety are sometimes sprinkled into the argument.<br>
&gt; &gt; &gt; The argument comes from a naive assumption that users MUST up=
grade to the choice that is submitted into code. But in fact this isn't true=
 and some voices in this discussion need to be more humble about what users m=
ust or must not run.<br>
&gt; &gt; &gt; Does no one realize that it is a very possible outcome that i=
f LOT=3Dtrue is released there may be only a handful of people that begin ru=
nning it while everyone else delays their upgrade (with the very good reason=
 of not getting involved in politics) and a year later those handful of peop=
le just become stuck at the moment of MUST_SIGNAL, unable to mine new blocks=
? Or attracting a minority of miners, activating, and forking off into a min=
ority fork. Then a lot=3Dfalse could be started that ends up activating the f=
eature now that the stubborn option has ran its course.<br>
&gt; &gt; &gt; The result: a wasted year of waiting and a minority of people=
 who didn't want to be lenient with miners by default. The chains could be c=
alled BitcoinLenient and BitcoinStubborn.<br>
&gt; &gt; &gt; How is that strictly safer or more coordinated?<br>
&gt; &gt; &gt; I may be in the minority, or maybe a silent majority, or mayb=
e a majority that just hasn't considered this as a choice but honestly if th=
ere is contention about whether we're going to be stubborn or lenient with m=
iners for Taproot and in the future then I prefer to just not activate anyth=
ing at all. I'm fine for calling bitcoin ossified, accepting that segwit is B=
itcoin's last network upgrade. Taproot is amazing but no new feature is wort=
h a network split down the middle.<br>
&gt; &gt; &gt; Maybe in 10 or 20 years, when other blockchains implement fea=
tures like Taproot and many more, we will become envious enough to put aside=
 our differences on how to behave towards miners and finally activate Taproo=
t.<br>
&gt; &gt; &gt; An activation mechanism is a consensus change like any other c=
hange, can be contentious like any other change, and we must resolve it like=
 any other change. Otherwise we risk arriving at the darkest timeline.<br>
&gt; &gt; &gt; Cheers<br>
&gt; &gt; &gt; Ariel Lorenzo-Luaces<br>
&gt; &gt; &gt; On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev &=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank=
">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Yesterday (February 16th) we held a second meeting on Ta=
proot<br>
&gt; &gt; &gt; &gt; activation on IRC which again was open to all. Despite w=
hat appeared<br>
&gt; &gt; &gt; &gt; to be majority support for LOT=3Dfalse over LOT=3Dtrue i=
n the first<br>
&gt; &gt; &gt; &gt; meeting I (and others) thought the arguments had not bee=
n explored in<br>
&gt; &gt; &gt; &gt; depth and that we should have a follow up meeting almost=
 entirely<br>
&gt; &gt; &gt; &gt; focused on whether LOT (lockinontimeout) should be set t=
o true or<br>
&gt; &gt; &gt; &gt; false.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; The meeting was announced here:<br>
&gt; &gt; &gt; &gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/b=
itcoin-dev/2021-February/018380.html" rel=3D"noreferrer" target=3D"_blank">h=
ttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.=
html</a><br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; In that mailing list post I outlined the arguments for L=
OT=3Dtrue (T1 to<br>
&gt; &gt; &gt; &gt; T6) and arguments for LOT=3Dfalse (F1 to F6) in their st=
rongest form I<br>
&gt; &gt; &gt; &gt; could. David Harding responded with an additional argume=
nt for<br>
&gt; &gt; &gt; &gt; LOT=3Dfalse (F7) here:<br>
&gt; &gt; &gt; &gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/b=
itcoin-dev/2021-February/018415.html" rel=3D"noreferrer" target=3D"_blank">h=
ttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.=
html</a><br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; These meetings are very challenging given they are open t=
o all, you<br>
&gt; &gt; &gt; &gt; don=E2=80=99t know who will attend and you don=E2=80=99t=
 know most people=E2=80=99s views in<br>
&gt; &gt; &gt; &gt; advance. I tried to give time for both the LOT=3Dtrue ar=
guments and the<br>
&gt; &gt; &gt; &gt; LOT=3Dfalse arguments to be discussed as I knew there wa=
s support for<br>
&gt; &gt; &gt; &gt; both. We only tried evaluating which had more support an=
d which had<br>
&gt; &gt; &gt; &gt; more strong opposition towards the end of the meeting.<b=
r>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; The conversation log is here:<br>
&gt; &gt; &gt; &gt; <a href=3D"http://gnusha.org/taproot-activation/2021-02-=
16.log" rel=3D"noreferrer" target=3D"_blank">http://gnusha.org/taproot-activ=
ation/2021-02-16.log</a><br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; (If you are so inclined you can watch a video of the mee=
ting here.<br>
&gt; &gt; &gt; &gt; Thanks to the YouTube account =E2=80=9CBitcoin=E2=80=9D f=
or setting up the livestream:<br>
&gt; &gt; &gt; &gt; <a href=3D"https://www.youtube.com/watch?v=3Dvpl5q1ovMLM=
" rel=3D"noreferrer" target=3D"_blank">https://www.youtube.com/watch?v=3Dvpl=
5q1ovMLM</a>)<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; A summary of the meeting was provided by Luke Dashjr on M=
astodon here:<br>
&gt; &gt; &gt; &gt; <a href=3D"https://bitcoinhackers.org/@lukedashjr/105742=
918779234566" rel=3D"noreferrer" target=3D"_blank">https://bitcoinhackers.or=
g/@lukedashjr/105742918779234566</a><br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Today's #Bitcoin #Taproot meeting was IMO largely unprod=
uctive, but we<br>
&gt; &gt; &gt; &gt; did manage to come to consensus on everything but Lockin=
OnTimeout.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Activation height range: 693504-745920<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; MASF threshold: 1815/2016 blocks (90%)<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Keep in mind only ~100 people showed for the meetings, h=
ardly<br>
&gt; &gt; &gt; &gt; representative of the entire community.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; So, these details remain JUST a proposal for now.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; It seems inevitable that there won't be consensus on LOT=
.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Everyone will have to choose for himself. :/<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Personally I agree with most of this. I agree that there=
 wasn=E2=80=99t<br>
&gt; &gt; &gt; &gt; overwhelming consensus for either LOT=3Dtrue or LOT=3Dfa=
lse. However, from<br>
&gt; &gt; &gt; &gt; my perspective there was clearly more strong opposition (=
what would<br>
&gt; &gt; &gt; &gt; usually be deemed a NACK in Bitcoin Core review terminol=
ogy) from<br>
&gt; &gt; &gt; &gt; Bitcoin Core contributors, Lightning developers and othe=
r community<br>
&gt; &gt; &gt; &gt; members against LOT=3Dtrue than there was for LOT=3Dfals=
e. Andrew Chow<br>
&gt; &gt; &gt; &gt; tried to summarize views from the meeting in this analys=
is:<br>
&gt; &gt; &gt; &gt; <a href=3D"https://gist.github.com/achow101/3e179501290a=
bb7049de198d46894c7c" rel=3D"noreferrer" target=3D"_blank">https://gist.gith=
ub.com/achow101/3e179501290abb7049de198d46894c7c</a><br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; I am also aware of other current and previous Bitcoin Co=
re<br>
&gt; &gt; &gt; &gt; contributors and Lightning developers who didn=E2=80=99t=
 attend the meeting in<br>
&gt; &gt; &gt; &gt; person who are opposed to LOT=3Dtrue. I don=E2=80=99t wa=
nt to put them in the<br>
&gt; &gt; &gt; &gt; spotlight for no reason but if you go through the conver=
sation logs of<br>
&gt; &gt; &gt; &gt; not only the meeting but the weeks of discussion prior t=
o this meeting<br>
&gt; &gt; &gt; &gt; you will see their views evaluated on the ##taproot-acti=
vation<br>
&gt; &gt; &gt; &gt; channel. In addition, on <a href=3D"http://taprootactiva=
tion.com" rel=3D"noreferrer" target=3D"_blank">taprootactivation.com</a> som=
e mining pools<br>
&gt; &gt; &gt; &gt; expressed a preference for lot=3Dfalse though I don=E2=80=
=99t know how strong<br>
&gt; &gt; &gt; &gt; that preference was.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; I am only one voice but it is my current assessment that=
 if we are to<br>
&gt; &gt; &gt; &gt; attempt to finalize Taproot activation parameters and pr=
opose them to<br>
&gt; &gt; &gt; &gt; the community at this time our only option is to propose=
 LOT=3Dfalse.<br>
&gt; &gt; &gt; &gt; Any further delay appears to me counterproductive in our=
 collective<br>
&gt; &gt; &gt; &gt; aim to get the Taproot soft fork activated as early as p=
ossible.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Obviously others are free to disagree with that assessme=
nt and<br>
&gt; &gt; &gt; &gt; continue discussions but personally I will be attempting=
 to avoid<br>
&gt; &gt; &gt; &gt; those discussions unless prominent new information comes=
 to light or<br>
&gt; &gt; &gt; &gt; various specific individuals change their minds.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Next week we are planning a code review of the Bitcoin C=
ore PR #19573<br>
&gt; &gt; &gt; &gt; which was initially delayed because of this LOT discussi=
on. As I=E2=80=99ve<br>
&gt; &gt; &gt; &gt; said previously that will be loosely following the forma=
t of the<br>
&gt; &gt; &gt; &gt; Bitcoin Core PR review club and will be lower level and m=
ore<br>
&gt; &gt; &gt; &gt; technical. That is planned for Tuesday February 23rd at 1=
9:00 UTC on<br>
&gt; &gt; &gt; &gt; the IRC channel ##taproot-activation.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Thanks to the meeting participants (and those who joined=
 the<br>
&gt; &gt; &gt; &gt; discussion on the channel prior and post the meeting) fo=
r engaging<br>
&gt; &gt; &gt; &gt; productively and in good faith.<br>
&gt; &gt;<br>
&gt; &gt; --<br>
&gt; &gt; Michael Folkson<br>
&gt; &gt; Email:&nbsp;<a href=3D"mailto:michaelfolkson@gmail.com" target=3D"=
_blank">michaelfolkson@gmail.com</a><br>
&gt; &gt; Keybase: michaelfolkson<br>
&gt; &gt; PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; bitcoin-dev mailing list<br>
&gt; &gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; &gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.=
org/mailman/listinfo/bitcoin-dev</a><br>
<br>
<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr" c=
lass=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div di=
r=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr=
"><font face=3D"arial, helvetica, sans-serif" color=3D"#000000">Michael Folk=
son</font><div><font face=3D"arial, helvetica, sans-serif" color=3D"#000000"=
>Email:&nbsp;<a href=3D"mailto:michaelfolkson@gmail.com" target=3D"_blank">m=
ichaelfolkson@gmail.com</a></font></div><div><font face=3D"arial, helvetica,=
 sans-serif" color=3D"#000000">Keybase: michaelfolkson</font></div><div><fon=
t face=3D"arial, helvetica, sans-serif" color=3D"#000000">PGP: 43ED C999 9F8=
5 1D40 EAF4 9835 92D6 0159 214C FEE3</font></div></div></div></div></div></d=
iv></div></div></div></div></div>
<span>_______________________________________________</span><br><span>bitcoi=
n-dev mailing list</span><br><span>bitcoin-dev@lists.linuxfoundation.org</sp=
an><br><span>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/span><br></div></blockquote></body></html>=

--Apple-Mail-64F839EB-5A59-4AF8-A785-6D2A8A56FE3F--