path: root/e0/6aa79d58a2fdb290854a0b58f6797016c12825

Return-Path: <arielluaces@gmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E7F93C000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 05:43:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id D1A7F87262
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 05:43:15 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id AqO0as7-m+qS
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 05:43:14 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com
 [209.85.214.174])
 by hemlock.osuosl.org (Postfix) with ESMTPS id 53ED68725F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 05:43:14 +0000 (UTC)
Received: by mail-pl1-f174.google.com with SMTP id s16so622364plr.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 17 Feb 2021 21:43:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=in-reply-to:references:thread-topic:user-agent:mime-version
 :content-transfer-encoding:subject:from:date:to:message-id;
 bh=MuLedtT6nSFdeE712AV4895DrYl7Lq6Y9tJ3Y13fBoA=;
 b=tsSYYVlMxeUJ3kQ1VuBbhZKKGFPohA0xNzNLlapHv9RCNZWGue0Q1q/2XjNEJV9Sck
 88s297CA1ulTFnSC8ZtoHD30LQ8oBtYRxr1LpJ38veCVm4UqUoXdDXbmLUxyD9s1zYvv
 udfBIqhwaNlrol6//laoU9dfo3OS+wl5rP/h4z8vft0cgYQWE4ahL46JHGErZbPa/LlM
 vJKzO1z/DphQxGoX+wE4FYvIr4icX3GCBeXh0fTcVjZKJeiZBL7g67tnsc6gRewJlE3w
 dXH6NLY2x0iWspVJovJCbn1vpcD7vL7twmKB+ccFPDYd674c1ttTaPbTcN7uVcjdhMja
 8YFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:in-reply-to:references:thread-topic:user-agent
 :mime-version:content-transfer-encoding:subject:from:date:to
 :message-id;
 bh=MuLedtT6nSFdeE712AV4895DrYl7Lq6Y9tJ3Y13fBoA=;
 b=QXEvoIFAPVysxG/b217mcx+bHhGeaBOg9p34sEAOH2LfBv3ftTuDJBTXM0C2H86n44
 DpRSA4RFfSXojnunqjxCqaJ1Vi7lFdvwi6rdRCR2IntuIxW4gT6ZM/kTxXSsT05lrHYp
 EJ5BdIAsCceEwpvTK/M7XrNn6vYV/15V7e6CK+ibl99vnpxy8hpPcisuMLs6pVDauQxu
 lhAL7nbt3crRo1Y1pzU7k/hQ6bgQPax9OJaYHgRBxYFyHydBsYIMwUFJCaFCfXiyl2Ry
 m64FCrY3GrW/PZ5pPnlizBJuRu4euT9hpNtjNf3wGIeX8HXQrpwsf7uIfhYj9sYmsDYX
 krAQ==
X-Gm-Message-State: AOAM533yWdeDAbaquHPtNhjjqEPunvt8BfgZNvwkOy/aCKoCdUriOOfo
 2mKnmCPCoOdmHAz3dvdxpcU=
X-Google-Smtp-Source: ABdhPJyt1cN1mEWyyVsBxm3LM+Yi9IOORnO3TBCdnDq7HdePuQ3nhNgLJFz34kJAxLJNDoC7SzKy4A==
X-Received: by 2002:a17:902:b48b:b029:e3:7808:aab4 with SMTP id
 y11-20020a170902b48bb02900e37808aab4mr2558238plr.54.1613626993835; 
 Wed, 17 Feb 2021 21:43:13 -0800 (PST)
Received: from [192.168.168.106] (d142-179-7-88.bchsia.telus.net.
 [142.179.7.88])
 by smtp.gmail.com with ESMTPSA id y200sm4391373pfc.103.2021.02.17.21.43.12
 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256);
 Wed, 17 Feb 2021 21:43:13 -0800 (PST)
In-Reply-To: <CAFvNmHTGkQJnsp7J8q0W3rf2j_djO0J0GNFzrhTpdAvN1GihEA@mail.gmail.com>
References: <CAFvNmHTGkQJnsp7J8q0W3rf2j_djO0J0GNFzrhTpdAvN1GihEA@mail.gmail.com>
X-Referenced-Uid: 24037
Thread-Topic: [bitcoin-dev] Yesterday's Taproot activation meeting on
 lockinontimeout (LOT)
X-Blue-Identity: !l=1440&o=96429&fo=101970&pl=1371&po=0&qs=PREFIX&f=HTML&n=Ariel%20Lorenzo-Luaces&e=arielluaces%40gmail.com&m=!%3AZjEwN2MyYjMtOWE0OC00NzJhLWEzYTQtYjc3MTEzNTNhODJm%3ASU5CT1g%3D%3AMjQwMzc%3D%3AANSWERED&p=1369&q=SHOW
User-Agent: Android
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="----37MWYK1484W2TQS9PRI1K4WNB5W1R0"
Content-Transfer-Encoding: 7bit
X-Local-Message-Id: <8231ddff-aaa4-4ee0-b25f-40ba9a540aab@gmail.com>
From: Ariel Lorenzo-Luaces <arielluaces@gmail.com>
Date: Wed, 17 Feb 2021 21:43:10 -0800
To: Michael Folkson <michaelfolkson@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <8231ddff-aaa4-4ee0-b25f-40ba9a540aab@gmail.com>
X-Mailman-Approved-At: Thu, 18 Feb 2021 10:18:48 +0000
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 05:43:16 -0000

------37MWYK1484W2TQS9PRI1K4WNB5W1R0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
 charset=UTF-8

Something what strikes me about the conversation is the emotion surrounding=
 the letters UASF=2E

It appears as if people discuss UASF as if it's a mas=
sive tidal wave of support that is inevitable, like we saw during segwit ac=
tivation=2E But the actual definition is "any activation that is not a MASF=
"=2E

A UASF can consist of a single node, ten nodes, a thousand, half of a=
ll nodes, all business' nodes, or even all the non mining nodes=2E On anoth=
er dimension it can have zero mining support, 51% support, 49% support, or =
any support right up against a miner activation threshold=2E

Hell a UASF d=
oesn't even need code or even a single node running as long as it exists as=
 a possibility in people's minds=2E

The only thing a UASF doesn't have is =
miner support above an agreed activation threshold (some number above %51)=
=2E

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=2E Words like coordinatio=
n and safety are sometimes sprinkled into the argument=2E

The argument com=
es from a naive assumption that users MUST upgrade to the choice that is su=
bmitted into code=2E But in fact this isn't true and some voices in this di=
scussion need to be more humble about what users must or must not run=2E

D=
oes 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 getti=
ng involved in politics) and a year later those handful of people just beco=
me stuck at the moment of MUST_SIGNAL, unable to mine new blocks? Or attrac=
ting a minority of miners, activating, and forking off into a minority fork=
=2E Then a lot=3Dfalse could be started that ends up activating the feature=
 now that the stubborn option has ran its course=2E
The result: a wasted ye=
ar of waiting and a minority of people who didn't want to be lenient with m=
iners by default=2E The chains could be called BitcoinLenient and BitcoinSt=
ubborn=2E
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 wheth=
er we'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=2E I'm fine for =
calling bitcoin ossified, accepting that segwit is Bitcoin's last network u=
pgrade=2E Taproot is amazing but no new feature is worth a network split do=
wn the middle=2E

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=2E

An activation mechanism is a consensus change like any other ch=
ange, can be contentious like any other change, and we must resolve it like=
 any other change=2E Otherwise we risk arriving at the darkest timeline=2E
=

Cheers
Ariel Lorenzo-Luaces


On Feb 17, 2021, 7:05 AM, at 7:05 AM, Michae=
l Folkson via bitcoin-dev <bitcoin-dev@lists=2Elinuxfoundation=2Eorg> wrote=
:
>Yesterday (February 16th) we held a second meeting on Taproot
>activatio=
n on IRC which again was open to all=2E Despite what appeared
>to be majori=
ty support for LOT=3Dfalse over LOT=3Dtrue in the first
>meeting I (and oth=
ers) thought the arguments had not been explored in
>depth and that we shou=
ld have a follow up meeting almost entirely
>focused on whether LOT (lockin=
ontimeout) should be set to true or
>false=2E
>
>The meeting was announced =
here:
>https://lists=2Elinuxfoundation=2Eorg/pipermail/bitcoin-dev/2021-Feb=
ruary/018380=2Ehtml
>
>In that mailing list post I outlined the arguments f=
or LOT=3Dtrue (T1 to
>T6) and arguments for LOT=3Dfalse (F1 to F6) in their=
 strongest form I
>could=2E David Harding responded with an additional argu=
ment for
>LOT=3Dfalse (F7) here:
>https://lists=2Elinuxfoundation=2Eorg/pip=
ermail/bitcoin-dev/2021-February/018415=2Ehtml
>
>These meetings are very c=
hallenging given they are open to all, you
>don=E2=80=99t know who will att=
end and you don=E2=80=99t know most people=E2=80=99s views in
>advance=2E 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=2E We only =
tried evaluating which had more support and which had
>more strong oppositi=
on towards the end of the meeting=2E
>
>The conversation log is here:
>http=
://gnusha=2Eorg/taproot-activation/2021-02-16=2Elog
>
>(If you are so incli=
ned you can watch a video of the meeting here=2E
>Thanks to the YouTube acc=
ount =E2=80=9CBitcoin=E2=80=9D for setting up the livestream:
>https://www=
=2Eyoutube=2Ecom/watch?v=3Dvpl5q1ovMLM)
>
>A summary of the meeting was pro=
vided by Luke Dashjr on Mastodon here:
>https://bitcoinhackers=2Eorg/@luked=
ashjr/105742918779234566
>
>Today's #Bitcoin #Taproot meeting was IMO large=
ly unproductive, but we
>did manage to come to consensus on everything but =
LockinOnTimeout=2E
>
>Activation height range: 693504-745920
>
>MASF thresh=
old: 1815/2016 blocks (90%)
>
>Keep in mind only ~100 people showed for the=
 meetings, hardly
>representative of the entire community=2E
>
>So, these d=
etails remain JUST a proposal for now=2E
>
>It seems inevitable that there =
won't be consensus on LOT=2E
>
>Everyone will have to choose for himself=2E=
 :/
>
>Personally I agree with most of this=2E I agree that there wasn=E2=
=80=99t
>overwhelming consensus for either LOT=3Dtrue or LOT=3Dfalse=2E How=
ever, from
>my perspective there was clearly more strong opposition (what w=
ould
>usually be deemed a NACK in Bitcoin Core review terminology) from
>Bi=
tcoin Core contributors, Lightning developers and other community
>members =
against LOT=3Dtrue than there was for LOT=3Dfalse=2E Andrew Chow
>tried to =
summarize views from the meeting in this analysis:
>https://gist=2Egithub=
=2Ecom/achow101/3e179501290abb7049de198d46894c7c
>
>I am also aware of othe=
r current and previous Bitcoin Core
>contributors and Lightning developers =
who didn=E2=80=99t attend the meeting in
>person who are opposed to LOT=3Dt=
rue=2E I don=E2=80=99t want to put them in the
>spotlight for no reason but=
 if you go through the conversation logs of
>not only the meeting but the w=
eeks of discussion prior to this meeting
>you will see their views evaluate=
d on the ##taproot-activation
>channel=2E In addition, on taprootactivation=
=2Ecom some mining pools
>expressed a preference for lot=3Dfalse though I d=
on=E2=80=99t know how strong
>that preference was=2E
>
>I am only one voice=
 but it is my current assessment that if we are to
>attempt to finalize Tap=
root activation parameters and propose them to
>the community at this time =
our only option is to propose LOT=3Dfalse=2E
>Any further delay appears to =
me counterproductive in our collective
>aim to get the Taproot soft fork ac=
tivated as early as possible=2E
>
>Obviously others are free to disagree wi=
th that assessment and
>continue discussions but personally I will be attem=
pting to avoid
>those discussions unless prominent new information comes to=
 light or
>various specific individuals change their minds=2E
>
>Next week =
we are planning a code review of the Bitcoin Core PR #19573
>which was init=
ially delayed because of this LOT discussion=2E As I=E2=80=99ve
>said previ=
ously that will be loosely following the format of the
>Bitcoin Core PR rev=
iew club and will be lower level and more
>technical=2E That is planned for=
 Tuesday February 23rd at 19:00 UTC on
>the IRC channel ##taproot-activatio=
n=2E
>
>Thanks to the meeting participants (and those who joined the
>discu=
ssion on the channel prior and post the meeting) for engaging
>productively=
 and in good faith=2E
>
>-- 
>Michael Folkson
>Email: michaelfolkson@gmail=
=2Ecom
>Keybase: michaelfolkson
>PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 01=
59 214C FEE3
>_______________________________________________
>bitcoin-dev =
mailing list
>bitcoin-dev@lists=2Elinuxfoundation=2Eorg
>https://lists=2Eli=
nuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev

------37MWYK1484W2TQS9PRI1K4WNB5W1R0
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head></head><body><div dir=3D"auto">Something what strikes me about =
the conversation is the emotion surrounding the letters UASF=2E<br><br></di=
v>
<div dir=3D"auto">It appears as if people discuss UASF as if it's a mass=
ive tidal wave of support that is inevitable, like we saw during segwit act=
ivation=2E But the actual definition is "any activation that is not a MASF"=
=2E<br><br></div>
<div dir=3D"auto">A UASF can consist of a single node, te=
n nodes, a thousand, half of all nodes, all business' nodes, or even all th=
e non mining nodes=2E On another dimension it can have zero mining support,=
 51% support, 49% support, or any support right up against a miner activati=
on threshold=2E<br><br></div>
<div dir=3D"auto">Hell a UASF doesn't even ne=
ed code or even a single node running as long as it exists as a possibility=
 in people's minds=2E<br><br></div>
<div dir=3D"auto">The only thing a UASF=
 doesn't have is miner support above an agreed activation threshold (some n=
umber above %51)=2E<br><br></div>
<div dir=3D"auto">I say this because it s=
trikes 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 defau=
lt from the beginning=2E Words like coordination and safety are sometimes s=
prinkled into the argument=2E<br><br></div>
<div dir=3D"auto">The argument =
comes from a naive assumption that users MUST upgrade to the choice that is=
 submitted into code=2E 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=2E=
<br><br></div>
<div dir=3D"auto">Does no one realize that it is a very poss=
ible 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, un=
able to mine new blocks? Or attracting a minority of miners, activating, an=
d forking off into a minority fork=2E Then a lot=3Dfalse could be started t=
hat ends up activating the feature now that the stubborn option has ran its=
 course=2E<br></div>
<div dir=3D"auto">The result: a wasted year of waiting=
 and a minority of people who didn't want to be lenient with miners by defa=
ult=2E The chains could be called BitcoinLenient and BitcoinStubborn=2E<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 m=
ajority, or maybe a majority that just hasn't considered this as a choice b=
ut honestly if there is contention about whether we'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=2E I'm fine for calling bitcoin ossified, acc=
epting that segwit is Bitcoin's last network upgrade=2E Taproot is amazing =
but no new feature is worth a network split down the middle=2E<br><br></div=
>
<div dir=3D"auto">Maybe in 10 or 20 years, when other blockchains impleme=
nt features like Taproot and many more, we will become envious enough to pu=
t aside our differences on how to behave towards miners and finally activat=
e Taproot=2E<br><br></div>
<div dir=3D"auto">An activation mechanism is a c=
onsensus change like any other change, can be contentious like any other ch=
ange, and we must resolve it like any other change=2E Otherwise we risk arr=
iving at the darkest timeline=2E<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=2Elinuxfoundation=2Eorg" target=3D"_blan=
k">bitcoin-dev@lists=2Elinuxfoundation=2Eorg</a>&gt; wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0=2E8ex; border-left: 1px so=
lid rgb(204, 204, 204); padding-left: 1ex;">
<pre class=3D"blue">Yesterday =
(February 16th) we held a second meeting on Taproot<br>activation on IRC wh=
ich again was open to all=2E Despite what appeared<br>to be majority suppor=
t for LOT=3Dfalse over LOT=3Dtrue in the first<br>meeting I (and others) th=
ought the arguments had not been explored in<br>depth and that we should ha=
ve a follow up meeting almost entirely<br>focused on whether LOT (lockinont=
imeout) should be set to true or<br>false=2E<br><br>The meeting was announc=
ed here:<br><a href=3D"https://lists=2Elinuxfoundation=2Eorg/pipermail/bitc=
oin-dev/2021-February/018380=2Ehtml">https://lists=2Elinuxfoundation=2Eorg/=
pipermail/bitcoin-dev/2021-February/018380=2Ehtml</a><br><br>In that mailin=
g list post I outlined the arguments for LOT=3Dtrue (T1 to<br>T6) and argum=
ents for LOT=3Dfalse (F1 to F6) in their strongest form I<br>could=2E David=
 Harding responded with an additional argument for<br>LOT=3Dfalse (F7) here=
:<br><a href=3D"https://lists=2Elinuxfoundation=2Eorg/pipermail/bitcoin-dev=
/2021-February/018415=2Ehtml">https://lists=2Elinuxfoundation=2Eorg/piperma=
il/bitcoin-dev/2021-February/018415=2Ehtml</a><br><br>These meetings are ve=
ry challenging given they are open to all, you<br>don=E2=80=99t know who wi=
ll attend and you don=E2=80=99t know most people=E2=80=99s views in<br>adva=
nce=2E I tried to give time for both the LOT=3Dtrue arguments and the<br>LO=
T=3Dfalse arguments to be discussed as I knew there was support for<br>both=
=2E We only tried evaluating which had more support and which had<br>more s=
trong opposition towards the end of the meeting=2E<br><br>The conversation =
log is here:<br><a href=3D"http://gnusha=2Eorg/taproot-activation/2021-02-1=
6=2Elog">http://gnusha=2Eorg/taproot-activation/2021-02-16=2Elog</a><br><br=
>(If you are so inclined you can watch a video of the meeting here=2E<br>Th=
anks to the YouTube account =E2=80=9CBitcoin=E2=80=9D for setting up the li=
vestream:<br><a href=3D"https://www=2Eyoutube=2Ecom/watch?v=3Dvpl5q1ovMLM">=
https://www=2Eyoutube=2Ecom/watch?v=3Dvpl5q1ovMLM</a>)<br><br>A summary of =
the meeting was provided by Luke Dashjr on Mastodon here:<br><a href=3D"htt=
ps://bitcoinhackers=2Eorg/@lukedashjr/105742918779234566">https://bitcoinha=
ckers=2Eorg/@lukedashjr/105742918779234566</a><br><br>Today's #Bitcoin #Tap=
root meeting was IMO largely unproductive, but we<br>did manage to come to =
consensus on everything but LockinOnTimeout=2E<br><br>Activation height ran=
ge: 693504-745920<br><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 community=2E<br><br>So, these details remain JUST a proposal=
 for now=2E<br><br>It seems inevitable that there won't be consensus on LOT=
=2E<br><br>Everyone will have to choose for himself=2E :/<br><br>Personally=
 I agree with most of this=2E I agree that there wasn=E2=80=99t<br>overwhel=
ming consensus for either LOT=3Dtrue or LOT=3Dfalse=2E However, from<br>my =
perspective there was clearly more strong opposition (what would<br>usually=
 be deemed a NACK in Bitcoin Core review terminology) from<br>Bitcoin Core =
contributors, Lightning developers and other community<br>members against L=
OT=3Dtrue than there was for LOT=3Dfalse=2E Andrew Chow<br>tried to summari=
ze views from the meeting in this analysis:<br><a href=3D"https://gist=2Egi=
thub=2Ecom/achow101/3e179501290abb7049de198d46894c7c">https://gist=2Egithub=
=2Ecom/achow101/3e179501290abb7049de198d46894c7c</a><br><br>I am also aware=
 of other current and previous Bitcoin Core<br>contributors and Lightning d=
evelopers who didn=E2=80=99t attend the meeting in<br>person who are oppose=
d to LOT=3Dtrue=2E I don=E2=80=99t want to put them in the<br>spotlight for=
 no reason but if you go through the conversation logs of<br>not only the m=
eeting but the weeks of discussion prior to this meeting<br>you will see th=
eir views evaluated on the ##taproot-activation<br>channel=2E In addition, =
on <a href=3D"http://taprootactivation=2Ecom">taprootactivation=2Ecom</a> s=
ome mining pools<br>expressed a preference for lot=3Dfalse though I don=E2=
=80=99t know how strong<br>that preference was=2E<br><br>I am only one voic=
e but it is my current assessment that if we are to<br>attempt to finalize =
Taproot activation parameters and propose them to<br>the community at this =
time our only option is to propose LOT=3Dfalse=2E<br>Any further delay appe=
ars to me counterproductive in our collective<br>aim to get the Taproot sof=
t fork activated as early as possible=2E<br><br>Obviously others are free t=
o disagree with that assessment and<br>continue discussions but personally =
I will be attempting to avoid<br>those discussions unless prominent new inf=
ormation comes to light or<br>various specific individuals change their min=
ds=2E<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=2E As=
 I=E2=80=99ve<br>said previously that will be loosely following the format =
of the<br>Bitcoin Core PR review club and will be lower level and more<br>t=
echnical=2E That is planned for Tuesday February 23rd at 19:00 UTC on<br>th=
e IRC channel ##taproot-activation=2E<br><br>Thanks to the meeting particip=
ants (and those who joined the<br>discussion on the channel prior and post =
the meeting) for engaging<br>productively and in good faith=2E<br></pre></b=
lockquote></div></body></html>
------37MWYK1484W2TQS9PRI1K4WNB5W1R0--