Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6A51FC000D for ; 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 ; 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 ; 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 ; 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 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: In-Reply-To: To: Michael Folkson , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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 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 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 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
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.

Bitcoi= n is a consensus system. The absolute worst outcome at all possible is to ha= ve it fall out of consensus.

Matt

On Feb 18, 2021, a= t 08:11, Michael Folkson via bitcoin-dev <bitcoin-dev@lists.linuxfoundati= on.org> wrote:

=EF=BB=BF
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;

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.



On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <= ;ZmnSCPxj@protonmail.com> w= rote:
Good morning= all,

> "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.

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.

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.

Regards,
ZmnSCPxj

>
> On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <bitco= in-dev@lists.linuxfoundation.org> wrote:
>
> > 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.
> >
> > > 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.
> >
> > 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. > >
> > > 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= ?
> >
> > 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;https://lists.linux= foundation.org/pipermail/bitcoin-dev/2021-February/018380.html) 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.
> >
> > > 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 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.
> >
> > > 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.
> >
> > 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 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 taprootactiva= tion.com (and this effort has informed the discussion) without taking pl= edges of support as cast iron guarantees.
> >
> > TL;DR It sounds like you agree with my recommendation to set LOT=3D= false in protocol implementations in my email :)
> >
> > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <arielluaces@gmail.com&g= t; wrote:
> >
> > > Something what strikes me about the conversation is the emoti= on surrounding the letters UASF.
> > > 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".
> > > 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.
> > > 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.
> > > The only thing a UASF doesn't have is miner support above an a= greed activation threshold (some number above %51).
> > > 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.
> > > 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.
> > > 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.
> > > 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.
> > > How is that strictly safer or more coordinated?
> > > 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.
> > > 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.
> > > 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.
> > > Cheers
> > > Ariel Lorenzo-Luaces
> > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev &= lt;bitcoin-dev@lists.linuxfoundation.org> wrote:
> > >
> > > > Yesterday (February 16th) we held a second meeting on Ta= proot
> > > > activation on IRC which again was open to all. Despite w= hat appeared
> > > > to be majority support for LOT=3Dfalse over LOT=3Dtrue i= n the first
> > > > meeting I (and others) thought the arguments had not bee= n explored in
> > > > depth and that we should have a follow up meeting almost= entirely
> > > > focused on whether LOT (lockinontimeout) should be set t= o true or
> > > > false.
> > > >
> > > > The meeting was announced here:
> > > > h= ttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.= html
> > > >
> > > > In that mailing list post I outlined the arguments for L= OT=3Dtrue (T1 to
> > > > T6) and arguments for LOT=3Dfalse (F1 to F6) in their st= rongest form I
> > > > could. David Harding responded with an additional argume= nt for
> > > > LOT=3Dfalse (F7) here:
> > > > h= ttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.= html
> > > >
> > > > These meetings are very challenging given they are open t= o all, you
> > > > don=E2=80=99t know who will attend and you don=E2=80=99t= know most people=E2=80=99s views in
> > > > advance. I tried to give time for both the LOT=3Dtrue ar= guments and the
> > > > LOT=3Dfalse arguments to be discussed as I knew there wa= s support for
> > > > both. We only tried evaluating which had more support an= d which had
> > > > more strong opposition towards the end of the meeting. > > > >
> > > > The conversation log is here:
> > > > http://gnusha.org/taproot-activ= ation/2021-02-16.log
> > > >
> > > > (If you are so inclined you can watch a video of the mee= ting here.
> > > > Thanks to the YouTube account =E2=80=9CBitcoin=E2=80=9D f= or setting up the livestream:
> > > > https://www.youtube.com/watch?v=3Dvpl= 5q1ovMLM)
> > > >
> > > > A summary of the meeting was provided by Luke Dashjr on M= astodon here:
> > > > https://bitcoinhackers.or= g/@lukedashjr/105742918779234566
> > > >
> > > > Today's #Bitcoin #Taproot meeting was IMO largely unprod= uctive, but we
> > > > did manage to come to consensus on everything but Lockin= OnTimeout.
> > > >
> > > > Activation height range: 693504-745920
> > > >
> > > > MASF threshold: 1815/2016 blocks (90%)
> > > >
> > > > Keep in mind only ~100 people showed for the meetings, h= ardly
> > > > 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=3Dfa= lse. However, from
> > > > my perspective there was clearly more strong opposition (= what would
> > > > usually be deemed a NACK in Bitcoin Core review terminol= ogy) from
> > > > Bitcoin Core contributors, Lightning developers and othe= r community
> > > > members against LOT=3Dtrue than there was for LOT=3Dfals= e. Andrew Chow
> > > > tried to summarize views from the meeting in this analys= is:
> > > > https://gist.gith= ub.com/achow101/3e179501290abb7049de198d46894c7c
> > > >
> > > > I am also aware of other current and previous Bitcoin Co= re
> > > > contributors and Lightning developers who didn=E2=80=99t= attend the meeting in
> > > > person who are opposed to LOT=3Dtrue. I don=E2=80=99t wa= nt to put them in the
> > > > spotlight for no reason but if you go through the conver= sation logs of
> > > > not only the meeting but the weeks of discussion prior t= o this meeting
> > > > you will see their views evaluated on the ##taproot-acti= vation
> > > > channel. In addition, on taprootactivation.com som= e mining pools
> > > > expressed a preference for lot=3Dfalse though I don=E2=80= =99t know how strong
> > > > 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 pr= opose 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 p= ossible.
> > > >
> > > > Obviously others are free to disagree with that assessme= nt 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 C= ore PR #19573
> > > > which was initially delayed because of this LOT discussi= on. As I=E2=80=99ve
> > > > said previously that will be loosely following the forma= t of the
> > > > Bitcoin Core PR review club and will be lower level and m= ore
> > > > technical. That is planned for Tuesday February 23rd at 1= 9: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) fo= r engaging
> > > > 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




--
Michael Folk= son
Keybase: michaelfolkson
PGP: 43ED C999 9F8= 5 1D40 EAF4 9835 92D6 0159 214C FEE3
_______________________________________________
bitcoi= n-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /span>
= --Apple-Mail-64F839EB-5A59-4AF8-A785-6D2A8A56FE3F--