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

+

+