path: root/e3/2ac5a7d007258c955d9772153bce62d45f285b

Return-Path: <michaelfolkson@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id ECF9AC000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 11:01:43 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id D3DD586E0C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 11:01:43 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id A8oHhbPIWe+P
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 11:01:41 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com
 [209.85.210.50])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 8197786974
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 11:01:41 +0000 (UTC)
Received: by mail-ot1-f50.google.com with SMTP id s6so1490132otk.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 03:01:41 -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=ULvdp7Y43Wq0Gp/RbYk24GGHc9yIKNUvcGG+xo9nimI=;
 b=ZBC3VPL+ostyBiPv3SAS+8I+VM29YEfpXYAKHzVl4FBYnA9a/g5VGZZghp/bct2DYb
 YYBQLKTMLODLxhbiIQyWvaF02ouINoN/wNWQjcGwOn1/QxG4Qp4ZaxQCk5VbEC5HENiC
 JLbaE0+06XrhAwVqgZLgbEBsooQ0+Ou+j3vpOKkkidkrr0sYpaqZW7GGipyfBC7f5IIH
 4bFAtnTR8Jtazo0pwonPFgMRzH02kIQWNAnavAOU6n6nQmrDpjqRk456YO7Vsjihpon3
 G8NSm2AcQoCLBiRjiJY37oo7y1DEnC67t/7HFY+h3OOKdzjbUkFA0q5zuSma/UkuPljI
 6mmw==
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=ULvdp7Y43Wq0Gp/RbYk24GGHc9yIKNUvcGG+xo9nimI=;
 b=rRzzJ0uUiEREcr34lJQb0MRj1hJ+ay/Dnb8ptF1RxQUXlhLK/NmnGLfrmHTPTn7l5E
 58GtfCMSIRxCPKGSe7dUKb62OUjAFJpIwRir0otbsk8puzO2DL+KsRoYCyhjySLQ68PJ
 3yFJMrqpbjRax1smO0sNDcjNBZhN2zPEP+jT2J5cy1L9mMSOfLXf24y03iaadW0M53KB
 IIFmcb3zyWehPC+pVRnIAWq+lEGcFiHG0t5So3H3+QUA0leumae6XFVKLdVuJBEkk4VR
 h0Hv1/C4xAytC0VkNj2sCDZ8go+v0/EDUqc+NCslsBTCSY3xfty3AJ7Kx2nbju+KPLC4
 vTww==
X-Gm-Message-State: AOAM533JnB29KZfPtbhm4fCSGXGrgJzu4K4SzyAhDSeRzXqb0XYQpqwY
 HKdLwdKpqBCfXY7gSiJza2tWVD81mtR+CBbkJ6w=
X-Google-Smtp-Source: ABdhPJwCLDUFeTQMs3Bj7Z3G3kDq7Mwp1HGl78rjF3jCkuDJ7OFIByqFJOJjOzsfdAXVicx8VT8mr5m/2LbKNqq8cNw=
X-Received: by 2002:a9d:67cb:: with SMTP id c11mr2494633otn.290.1613646100625; 
 Thu, 18 Feb 2021 03:01:40 -0800 (PST)
MIME-Version: 1.0
References: <CAFvNmHTGkQJnsp7J8q0W3rf2j_djO0J0GNFzrhTpdAvN1GihEA@mail.gmail.com>
 <8231ddff-aaa4-4ee0-b25f-40ba9a540aab@gmail.com>
In-Reply-To: <8231ddff-aaa4-4ee0-b25f-40ba9a540aab@gmail.com>
From: Michael Folkson <michaelfolkson@gmail.com>
Date: Thu, 18 Feb 2021 11:01:29 +0000
Message-ID: <CAFvNmHSiZhJQ455=RkUVU00ZqagimjGPg_fhC-8oJV=WwM_o=Q@mail.gmail.com>
To: Ariel Lorenzo-Luaces <arielluaces@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000009efd0705bb9a4229"
X-Mailman-Approved-At: Thu, 18 Feb 2021 11:08:42 +0000
Cc: 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 11:01:44 -0000

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

Thanks for your response Ariel. It would be useful if you responded to
specific points I have made in the mailing list post or at least quote
these ephemeral "people" you speak of. I don't know if you're responding to
conversation on the IRC channel or on social media etc.

> The argument comes from a naive assumption that users MUST upgrade 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 must or
must not run.

I personally have never made this assumption. Of course users aren't forced
to run any particular software version, quite the opposite. Defaults set 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=3Dtrue
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
getting involved in politics) and a year later those handful of people just
become stuck at the moment of MUST_SIGNAL, unable to mine new blocks?

It is a possible outcome but the likely outcome is that miners activate
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
have this discussion now rather than be unprepared for that eventuality. If
LOT is set to false in a software release there is the possibility (T2 in
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/01838=
0.html)
of individuals or a proportion of the community changing LOT to true. In
that sense setting LOT=3Dfalse in a software release appears to be no more
safe than LOT=3Dtrue.

> The result: a wasted year of waiting and a minority of people who didn't
want to be lenient with miners by default.

There is the (unlikely but possible) possibility of a wasted year if 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
offers them clarity on what will happen over a year time period and removes
the need for coordinated or uncoordinated community UASF efforts on top of
LOT=3Dfalse.

> 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 other
change. Otherwise we risk arriving at the darkest timeline.

I don't know what you are recommending here to avoid "this darkest
timeline". Open discussions have occurred and are continuing and in my
mailing list post that you responded to **I recommended we propose
LOT=3Dfalse be set in protocol implementations such as Bitcoin Core**. I do
think this apocalyptic language isn't particularly helpful. In an open
consensus system discussion is healthy, we should prepare for bad or worst
case scenarios in advance and doing so is not antagonistic or destructive.
Mining pools have pledged 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 grateful that people like Alejandro have worked
hard on taprootactivation.com (and this effort has informed the discussion)
without taking pledges of support as cast iron guarantees.

TL;DR It sounds like you agree with my recommendation to set LOT=3Dfalse in
protocol implementations in my email :)




On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <arielluaces@gmail.com=
>
wrote:

> Something what strikes me about the conversation is the emotion
> surrounding the letters UASF.
>
> It appears as if people discuss UASF as if it's a massive tidal wave of
> support that is inevitable, like we saw during segwit activation. But the
> 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 another
> dimension it can have zero mining support, 51% support, 49% support, or a=
ny
> 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
> LOT=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 coordinatio=
n
> and safety are sometimes sprinkled into the argument.
>
> The argument comes from a naive assumption that users MUST upgrade 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 must or
> must not run.
>
> Does no one realize that it is a very possible outcome that if LOT=3Dtrue=
 is
> released there may be only a handful of people that begin running it whil=
e
> everyone else delays their upgrade (with the very good reason of not
> getting involved in politics) and a year later those handful of people ju=
st
> 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
> minority fork. Then a lot=3Dfalse could be started that ends up activatin=
g
> the feature now that the stubborn option has ran its course.
> 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 called
> BitcoinLenient and BitcoinStubborn.
> How is that strictly safer or more coordinated?
>
> I may be in the minority, or maybe a silent majority, or maybe a majority
> 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 miner=
s
> for Taproot and in the future then I prefer to just not activate anything
> at all. 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 network split down the middle.
>
> Maybe in 10 or 20 years, when other blockchains implement features like
> Taproot and many more, we will become envious enough to put aside our
> differences 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 oth=
er
> 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 <
> bitcoin-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 appeared
>> to be majority support for LOT=3Dfalse over LOT=3Dtrue in the first
>> meeting I (and others) thought the arguments had not been explored 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-February/01=
8380.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 form I
>> could. David Harding responded with an additional argument for
>> LOT=3Dfalse (F7) here:
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/01=
8415.html
>>
>> These meetings are very challenging given they are open to all, you
>> don=E2=80=99t know who will attend and you don=E2=80=99t know most peopl=
e=E2=80=99s views in
>> advance. I tried to give time for both the LOT=3Dtrue arguments and 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 had
>> 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 setting up t=
he livestream:
>> https://www.youtube.com/watch?v=3Dvpl5q1ovMLM)
>>
>> A summary of the meeting was provided by Luke Dashjr on Mastodon here:
>> https://bitcoinhackers.org/@lukedashjr/105742918779234566
>>
>> Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but 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. However, fr=
om
>> my perspective there was clearly more strong opposition (what would
>> usually be deemed a NACK in Bitcoin Core review terminology) from
>> Bitcoin Core contributors, Lightning developers and other community
>> 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 the meet=
ing in
>> person who are opposed to LOT=3Dtrue. I don=E2=80=99t want to put them i=
n the
>> spotlight for no reason but if you go through the conversation logs of
>> not only the meeting but the weeks of discussion prior to this meeting
>> 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 know how s=
trong
>> that preference was.
>>
>> I am only one voice but it is my current assessment that if we are to
>> attempt to finalize Taproot activation parameters and propose them to
>> the community at this time our only option is to propose LOT=3Dfalse.
>> Any further delay appears to me counterproductive in our collective
>> 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 #19573
>> 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 engaging
>> productively and in good faith.
>>
>>

--=20
Michael Folkson
Email: michaelfolkson@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

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

<div dir=3D"ltr">Thanks for your response Ariel. It would be useful if you =
responded to specific points I have made in the mailing list post or at lea=
st quote these ephemeral &quot;people&quot; you speak of. I don&#39;t know =
if you&#39;re responding to conversation on the IRC channel or on social me=
dia etc.<div><br></div><div>&gt; The argument comes from a naive assumption=
 that users MUST upgrade to the choice that is submitted into code. But in =
fact this isn&#39;t true and some voices in this discussion need to be more=
 humble about what users must or must not run.</div><div><br></div><div>I p=
ersonally have never made this assumption. Of course users aren&#39;t force=
d to run any particular software version, quite the opposite. Defaults set =
in software versions matter though as many users won&#39;t change them.</di=
v><div><br></div><div>&gt; Does no one realize that it is a very possible o=
utcome that if LOT=3Dtrue is released there may be only a handful of people=
 that begin running it while everyone else delays their upgrade (with the v=
ery good reason of not getting involved in politics) and a year later those=
 handful of people just become stuck at the moment of MUST_SIGNAL, unable t=
o mine new blocks?</div><div><br></div><div>It is a possible outcome but th=
e likely outcome is that miners activate Taproot before LOT is even relevan=
t. I think it is prudent to prepare for the unlikely but possible outcome t=
hat miners fail to activate and hence have this discussion now rather than =
be unprepared for that eventuality. If LOT is set to false in a software re=
lease there is the possibility (T2 in=C2=A0<a href=3D"https://lists.linuxfo=
undation.org/pipermail/bitcoin-dev/2021-February/018380.html">https://lists=
.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html</a>) o=
f individuals or a proportion of the community changing LOT to true. In tha=
t sense setting LOT=3Dfalse in a software release appears to be no more saf=
e than LOT=3Dtrue.</div><div><br></div><div>&gt; The result: a wasted year =
of waiting and a minority of people who didn&#39;t want to be lenient with =
miners by default.</div><div><br></div><div>There is the (unlikely but poss=
ible) possibility of a wasted year if LOT is set to false and miners fail t=
o activate. I&#39;m not convinced by this perception that LOT=3Dtrue is ant=
agonistic to miners. I actually think it offers them clarity on what will h=
appen over a year time period and removes the need for coordinated or uncoo=
rdinated community UASF efforts on top of LOT=3Dfalse.</div><div><br></div>=
<div>&gt; An activation mechanism is a consensus change like any other chan=
ge, can be contentious like any other change, and we must resolve it like a=
ny other change. Otherwise we risk arriving at the darkest timeline.</div><=
div><br></div><div>I don&#39;t know what you are recommending here to avoid=
 &quot;this darkest timeline&quot;. Open discussions have occurred and are =
continuing and in my mailing list post that you responded to **I recommende=
d we propose LOT=3Dfalse be set in protocol implementations such as Bitcoin=
 Core**. I do think this apocalyptic language isn&#39;t particularly helpfu=
l. In an open consensus system discussion is healthy, we should prepare for=
 bad or worst case scenarios in advance and doing so is not antagonistic or=
 destructive. Mining pools=C2=A0have pledged support for Taproot but we don=
&#39;t build secure systems based on pledges of support, we build them to m=
inimize trust in any human actors. We can be grateful that people like Alej=
andro have worked hard on <a href=3D"http://taprootactivation.com">taproota=
ctivation.com</a> (and this effort has informed the discussion) without tak=
ing pledges of support as cast iron guarantees.</div><div><br></div><div>TL=
;DR It sounds like you agree with my recommendation to set LOT=3Dfalse in p=
rotocol implementations in my email :)</div><div><br></div><div><br></div><=
/div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_att=
r">On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces &lt;<a href=3D"mail=
to:arielluaces@gmail.com">arielluaces@gmail.com</a>&gt; wrote:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir=3D"auto">Somet=
hing what strikes me about the conversation is the emotion surrounding the =
letters UASF.<br><br></div>
<div dir=3D"auto">It appears as if people discuss UASF as if it&#39;s a mas=
sive tidal wave of support that is inevitable, like we saw during segwit ac=
tivation. But the actual definition is &quot;any activation that is not a M=
ASF&quot;.<br><br></div>
<div dir=3D"auto">A UASF can consist of a single node, ten nodes, a thousan=
d, half of all nodes, all business&#39; nodes, or even all the non mining n=
odes. On another dimension it can have zero mining support, 51% support, 49=
% support, or any support right up against a miner activation threshold.<br=
><br></div>
<div dir=3D"auto">Hell a UASF doesn&#39;t even need code or even a single n=
ode running as long as it exists as a possibility in people&#39;s minds.<br=
><br></div>
<div dir=3D"auto">The only thing a UASF doesn&#39;t have is miner support a=
bove an agreed activation threshold (some number above %51).<br><br></div>
<div dir=3D"auto">I say this because it strikes me when people say that the=
y are for LOT=3Dtrue with the logic that since a UASF is guaranteed to happ=
en then it&#39;s better to just make it default from the beginning. Words l=
ike coordination and safety are sometimes sprinkled into the argument.<br><=
br></div>
<div dir=3D"auto">The argument comes from a naive assumption that users MUS=
T upgrade to the choice that is submitted into code. But in fact this isn&#=
39;t true and some voices in this discussion need to be more humble about w=
hat users must or must not run.<br><br></div>
<div dir=3D"auto">Does no one realize that it is a very possible outcome th=
at if LOT=3Dtrue is released there may be only a handful of people that beg=
in running 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 people just become stuck at the moment of MUST_SIGNAL, unable to mine ne=
w blocks? Or attracting a minority of miners, activating, and forking off i=
nto a minority fork. Then a lot=3Dfalse could be started that ends up activ=
ating the feature now that the stubborn option has ran its course.<br></div=
>
<div dir=3D"auto">The result: a wasted year of waiting and a minority of pe=
ople who didn&#39;t want to be lenient with miners by default. The chains c=
ould be called BitcoinLenient and BitcoinStubborn.<br></div>
<div dir=3D"auto">How is that strictly safer or more coordinated?<br><br></=
div>
<div dir=3D"auto">I may be in the minority, or maybe a silent majority, or =
maybe a majority that just hasn&#39;t considered this as a choice but hones=
tly if there is contention about whether we&#39;re going to be stubborn or =
lenient with miners for Taproot and in the future then I prefer to just not=
 activate anything at all. I&#39;m fine for calling bitcoin ossified, accep=
ting that segwit is Bitcoin&#39;s last network upgrade. Taproot is amazing =
but no new feature is worth a network split down the middle.<br><br></div>
<div dir=3D"auto">Maybe in 10 or 20 years, when other blockchains implement=
 features like Taproot and many more, we will become envious enough to put =
aside our differences on how to behave towards miners and finally activate =
Taproot.<br><br></div>
<div dir=3D"auto">An activation mechanism is a consensus change like any ot=
her change, can be contentious like any other change, and we must resolve i=
t like any other change. Otherwise we risk arriving at the darkest timeline=
.<br><br></div>
<div dir=3D"auto">Cheers<br></div>
<div dir=3D"auto">Ariel Lorenzo-Luaces<br></div>
<div class=3D"gmail_quote">On Feb 17, 2021, at 7:05 AM, 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:<block=
quote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex">
<pre>Yesterday (February 16th) we held a second meeting on Taproot<br>activ=
ation on IRC which again was open to all. Despite what appeared<br>to be ma=
jority support for LOT=3Dfalse over LOT=3Dtrue in the first<br>meeting I (a=
nd others) thought the arguments had not been explored in<br>depth and that=
 we should have a follow up meeting almost entirely<br>focused on whether L=
OT (lockinontimeout) should be set to true or<br>false.<br><br>The meeting =
was announced here:<br><a href=3D"https://lists.linuxfoundation.org/piperma=
il/bitcoin-dev/2021-February/018380.html" target=3D"_blank">https://lists.l=
inuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html</a><br><=
br>In that mailing list post I outlined the arguments for LOT=3Dtrue (T1 to=
<br>T6) and arguments for LOT=3Dfalse (F1 to F6) in their strongest form I<=
br>could. David Harding responded with an additional argument for<br>LOT=3D=
false (F7) here:<br><a href=3D"https://lists.linuxfoundation.org/pipermail/=
bitcoin-dev/2021-February/018415.html" target=3D"_blank">https://lists.linu=
xfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html</a><br><br>=
These meetings are very challenging given they are open to all, you<br>don=
=E2=80=99t know who will attend and you don=E2=80=99t know most people=E2=
=80=99s views in<br>advance. I tried to give time for both the LOT=3Dtrue a=
rguments and the<br>LOT=3Dfalse arguments to be discussed as I knew there w=
as support for<br>both. We only tried evaluating which had more support and=
 which had<br>more strong opposition towards the end of the meeting.<br><br=
>The conversation log is here:<br><a href=3D"http://gnusha.org/taproot-acti=
vation/2021-02-16.log" target=3D"_blank">http://gnusha.org/taproot-activati=
on/2021-02-16.log</a><br><br>(If you are so inclined you can watch a video =
of the meeting here.<br>Thanks to the YouTube account =E2=80=9CBitcoin=E2=
=80=9D for setting up the livestream:<br><a href=3D"https://www.youtube.com=
/watch?v=3Dvpl5q1ovMLM" target=3D"_blank">https://www.youtube.com/watch?v=
=3Dvpl5q1ovMLM</a>)<br><br>A summary of the meeting was provided by Luke Da=
shjr on Mastodon here:<br><a href=3D"https://bitcoinhackers.org/@lukedashjr=
/105742918779234566" target=3D"_blank">https://bitcoinhackers.org/@lukedash=
jr/105742918779234566</a><br><br>Today&#39;s #Bitcoin #Taproot meeting was =
IMO largely unproductive, but we<br>did manage to come to consensus on ever=
ything but LockinOnTimeout.<br><br>Activation height range: 693504-745920<b=
r><br>MASF threshold: 1815/2016 blocks (90%)<br><br>Keep in mind only ~100 =
people showed for the meetings, hardly<br>representative of the entire comm=
unity.<br><br>So, these details remain JUST a proposal for now.<br><br>It s=
eems inevitable that there won&#39;t be consensus on LOT.<br><br>Everyone w=
ill have to choose for himself. :/<br><br>Personally I agree with most of t=
his. I agree that there wasn=E2=80=99t<br>overwhelming consensus for either=
 LOT=3Dtrue or LOT=3Dfalse. However, from<br>my perspective there was clear=
ly more strong opposition (what would<br>usually be deemed a NACK in Bitcoi=
n Core review terminology) from<br>Bitcoin Core contributors, Lightning dev=
elopers and other community<br>members against LOT=3Dtrue than there was fo=
r LOT=3Dfalse. Andrew Chow<br>tried to summarize views from the meeting in =
this analysis:<br><a href=3D"https://gist.github.com/achow101/3e179501290ab=
b7049de198d46894c7c" target=3D"_blank">https://gist.github.com/achow101/3e1=
79501290abb7049de198d46894c7c</a><br><br>I am also aware of other current a=
nd previous Bitcoin Core<br>contributors and Lightning developers who didn=
=E2=80=99t attend the meeting in<br>person who are opposed to LOT=3Dtrue. I=
 don=E2=80=99t want to put them in the<br>spotlight for no reason but if yo=
u go through the conversation logs of<br>not only the meeting but the weeks=
 of discussion prior to this meeting<br>you will see their views evaluated =
on the ##taproot-activation<br>channel. In addition, on <a href=3D"http://t=
aprootactivation.com" target=3D"_blank">taprootactivation.com</a> some mini=
ng pools<br>expressed a preference for lot=3Dfalse though I don=E2=80=99t k=
now how strong<br>that preference was.<br><br>I am only one voice but it is=
 my current assessment that if we are to<br>attempt to finalize Taproot act=
ivation parameters and propose them to<br>the community at this time our on=
ly option is to propose LOT=3Dfalse.<br>Any further delay appears to me cou=
nterproductive in our collective<br>aim to get the Taproot soft fork activa=
ted as early as possible.<br><br>Obviously others are free to disagree with=
 that assessment and<br>continue discussions but personally I will be attem=
pting to avoid<br>those discussions unless prominent new information comes =
to light or<br>various specific individuals change their minds.<br><br>Next=
 week we are planning a code review of the Bitcoin Core PR #19573<br>which =
was initially delayed because of this LOT discussion. As I=E2=80=99ve<br>sa=
id previously that will be loosely following the format of the<br>Bitcoin C=
ore PR review club and will be lower level and more<br>technical. That is p=
lanned for Tuesday February 23rd at 19:00 UTC on<br>the IRC channel ##tapro=
ot-activation.<br><br>Thanks to the meeting participants (and those who joi=
ned the<br>discussion on the channel prior and post the meeting) for engagi=
ng<br>productively and in good faith.<br></pre></blockquote></div></div></b=
lockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr" cl=
ass=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"lt=
r"><font face=3D"arial, helvetica, sans-serif" color=3D"#000000">Michael Fo=
lkson</font><div><font face=3D"arial, helvetica, sans-serif" color=3D"#0000=
00">Email:=C2=A0<a href=3D"mailto:michaelfolkson@gmail.com" target=3D"_blan=
k">michaelfolkson@gmail.com</a></font></div><div><font face=3D"arial, helve=
tica, sans-serif" color=3D"#000000">Keybase: michaelfolkson</font></div><di=
v><font face=3D"arial, helvetica, sans-serif" color=3D"#000000">PGP: 43ED C=
999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3</font></div></div></div></div><=
/div></div></div></div></div></div></div>

--0000000000009efd0705bb9a4229--