From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 12163C000D for ; Thu, 18 Feb 2021 11:52:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 0E66786E15 for ; Thu, 18 Feb 2021 11:52:18 +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 XoJsZeJIumAv for ; Thu, 18 Feb 2021 11:52:15 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) by whitealder.osuosl.org (Postfix) with ESMTPS id 4953D86322 for ; Thu, 18 Feb 2021 11:52:14 +0000 (UTC) Date: Thu, 18 Feb 2021 11:52:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1613649131; bh=vBHGVwZCN+hasX/UJap8m5uvGLj9e7+UjziG1DlZiCM=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=QbFPe1g100cnebQAls2YjCR7+8wxMtp18h9EAmGLgTZysL+AL8qvEFhJY8dnBOSwX /LxrJ2nd8kr5NRL++MFPf/v5YIrqNZGbAlUHFdgQRvlhvtv8FAIEDFOEV48Nve6P1+ qEBCOj+hnmDuM9hZ0QKEJSVIgeRna6z6oIH7eOZw= To: Samson Mow , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <8231ddff-aaa4-4ee0-b25f-40ba9a540aab@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Michael Folkson 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 11:52:18 -0000 Good morning all, > "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 othe= r 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=3Dfa= lse, would be to have a release that requires a `taprootlot=3D1` or `taproo= tlot=3D0` and refuses to start if the parameter is not set. This assures everyone that neither choice is being forced on users, and ins= tead what is being forced on users, is for users to make that choice themse= lves. Regards, ZmnSCPxj > > 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 to = specific points I have made in the mailing list post or at least quote thes= e 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 to= 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 o= r must not run. > > > > I personally have never made this assumption. Of course users aren't fo= rced 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 i= t while everyone else delays their upgrade (with the very good reason of no= t 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? > > > > 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 ha= ve 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= =C2=A0https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February= /018380.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 did= n't want to be lenient with miners by default. > > > > There is the (unlikely but possible) possibility of a wasted year if LO= T 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 off= ers them clarity on what will happen over a year time period and removes th= e need for coordinated or uncoordinated community UASF efforts on top of LO= T=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 o= ther change. Otherwise we risk arriving at the darkest timeline. > > > > I don't know what you are recommending here to avoid "this darkest time= line". 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 apoc= alyptic language isn't particularly helpful. In an open consensus system di= scussion is healthy, we should prepare for bad or worst case scenarios in a= dvance and doing so is not antagonistic or destructive. Mining pools=C2= =A0have 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 taproot= activation.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=3Dfals= e 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 surro= unding 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 th= e actual definition is "any activation that is not a MASF". > > > 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. On another= 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 l= ong as it exists as a possibility in people's minds. > > > The only thing a UASF doesn't have is miner support above an agreed a= ctivation threshold (some number above %51). > > > I say this because it strikes me when people say that they are for LO= T=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= 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 so= me voices in this discussion need to be more humble about what users must o= r 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 i= t while everyone else delays their upgrade (with the very good reason of no= t 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 minori= ty fork. Then a lot=3Dfalse could be started that ends up activating the fe= ature now that the stubborn option has ran its course. > > > The result: a wasted year of waiting and a minority of people who did= n'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 majo= rity 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 = for Taproot and in the future then I prefer to just not activate anything a= t all. I'm fine for calling bitcoin ossified, accepting that segwit is Bitc= oin'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 li= ke 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 appeare= d > > > > 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-Februa= ry/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 for= m I > > > > could. David Harding responded with an additional argument for > > > > LOT=3Dfalse (F7) here: > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Februa= ry/018415.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 = people=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 f= or > > > > 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 the livestream: > > > > https://www.youtube.com/watch?v=3Dvpl5q1ovMLM) > > > > > > > > A summary of the meeting was provided by Luke Dashjr on Mastodon he= re: > > > > 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. Howeve= r, from > > > > 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 C= how > > > > 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= meeting in > > > > person who are opposed to LOT=3Dtrue. I don=E2=80=99t want to put t= hem in 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 meet= ing > > > > 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 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 propose them = to > > > > the community at this time our only option is to propose LOT=3Dfals= e. > > > > 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 o= r > > > > various specific individuals change their minds. > > > > > > > > Next week we are planning a code review of the Bitcoin Core PR #195= 73 > > > > 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 o= n > > > > 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. > > > > -- > > Michael Folkson > > Email:=C2=A0michaelfolkson@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