From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 126EEC000D for ; Thu, 18 Feb 2021 13:59:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id E6C2C60067 for ; Thu, 18 Feb 2021 13:59:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyJB_UUwjfeq for ; Thu, 18 Feb 2021 13:59:39 +0000 (UTC) Received: by smtp3.osuosl.org (Postfix, from userid 1001) id 1645B605FE; Thu, 18 Feb 2021 13:59:39 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from mail.as397444.net (mail.as397444.net [69.59.18.99]) by smtp3.osuosl.org (Postfix) with ESMTPS id 5700C605EF for ; Thu, 18 Feb 2021 13:59:36 +0000 (UTC) Received: by mail.as397444.net (Postfix) with ESMTPSA id B96E04A389A; Thu, 18 Feb 2021 13:59:34 +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=1613654463; t=1613656774; bh=K9+ZlO+CmdPG66sDJZk6TajCH6OqmZP/8b3Uzt92aOs=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=FXs5Q3z1WFvMbN0cwhChQpbASUupXGk/LqSjQWRR8CbLTUmH3jnG/qbCt2n/bqFab XeMhmWa6b04zygvBaFIrwnyT5KNweAULj8HK5PnmlxM9eVCJezrnirRjsYoLOgjFkE raLWytnkmTzzmTbVw4CgZMxl5MyzKP5oBodET4+yqkseuNNOwAQVM9GXq58jVaWKhx LcQ6eP7ZWQ5bSDfkYhshQH8A3wP3ku5gWi3m+w23hAjC7T1+nu1i+O2J94H4OZIFG1 mm8sgtiSNRdDuRvvK/uWm3N3WCgfKJEcGSRG9RxHf3foUu5+LkcrEo9arFncq6mvAh s0O/zpKRecOsQ== Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Matt Corallo Mime-Version: 1.0 (1.0) Date: Thu, 18 Feb 2021 08:59:34 -0500 Message-Id: <9C0CDEF6-E77D-496F-BC38-8A0241B5E046@mattcorallo.com> References: In-Reply-To: To: ZmnSCPxj , Bitcoin Protocol Discussion 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 13:59:41 -0000 Bitcoin is a consensus system. Please let=E2=80=99s not jump to (or even con= sider) options that discourage consensus. We all laughed at (and later acade= mics researched showed severe deficiencies in) Bitcoin XT=E2=80=99s =E2=80=9C= emergent consensus=E2=80=9D nonsense, why should we start doing things along= that line in Bitcoin? (Resent from the correct email) Matt > On Feb 18, 2021, at 06:52, ZmnSCPxj via bitcoin-dev wrote: >=20 > =EF=BB=BFGood morning all, >=20 >> "An activation mechanism is a consensus change like any other change, can= be contentious like any other change, and we must resolve it like any other= change. Otherwise we risk arriving at the darkest timeline." >>=20 >> Who's we here? >>=20 >> Release both and let the network decide. >=20 > A thing that could be done, without mandating either LOT=3Dtrue or LOT=3Df= alse, 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. >=20 > This assures everyone that neither choice is being forced on users, and in= stead what is being forced on users, is for users to make that choice themse= lves. >=20 > Regards, > ZmnSCPxj >=20 >>=20 >>> On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev wrote: >>>=20 >>> Thanks for your response Ariel. It would be useful if you responded to s= pecific points I have made in the mailing list post or at least quote these e= phemeral "people" you speak of. I don't know if you're responding to convers= ation on the IRC channel or on social media etc. >>>=20 >>>> The argument comes from a naive assumption that users MUST upgrade to t= he choice that is submitted into code. But in fact this isn't true and some v= oices in this discussion need to be more humble about what users must or mus= t not run. >>>=20 >>> I personally have never made this assumption. Of course users aren't for= ced to run any particular software version, quite the opposite. Defaults set= in software versions matter though as many users won't change them. >>>=20 >>>> Does no one realize that it is a very possible outcome that if LOT=3Dtr= ue is released there may be only a handful of people that begin running it w= hile everyone else delays their upgrade (with the very good reason of not ge= tting involved in politics) and a year later those handful of people just be= come stuck at the moment of MUST_SIGNAL, unable to mine new blocks? >>>=20 >>> It is a possible outcome but the likely outcome is that miners activate T= aproot before LOT is even relevant. I think it is prudent to prepare for the= unlikely but possible outcome that miners fail to activate and hence have t= his discussion now rather than be unprepared for that eventuality. If LOT is= set to false in a software release there is the possibility (T2 in https://= lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html) o= f 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 t= han LOT=3Dtrue. >>>=20 >>>> The result: a wasted year of waiting and a minority of people who didn'= t want to be lenient with miners by default. >>>=20 >>> There is the (unlikely but possible) possibility of a wasted year if LOT= is set to false and miners fail to activate. I'm not convinced by this perc= eption that LOT=3Dtrue is antagonistic to miners. I actually think it offers= them clarity on what will happen over a year time period and removes the ne= ed for coordinated or uncoordinated community UASF efforts on top of LOT=3Df= alse. >>>=20 >>>> An activation mechanism is a consensus change like any other change, ca= n be contentious like any other change, and we must resolve it like any othe= r change. Otherwise we risk arriving at the darkest timeline. >>>=20 >>> I don't know what you are recommending here to avoid "this darkest timel= ine". Open discussions have occurred and are continuing and in my mailing li= st post that you responded to **I recommended we propose LOT=3Dfalse be set i= n protocol implementations such as Bitcoin Core**. I do think this apocalypt= ic language isn't particularly helpful. In an open consensus system discussi= on is healthy, we should prepare for bad or worst case scenarios in advance a= nd doing so is not antagonistic or destructive. Mining pools have pledged su= pport for Taproot but we don't build secure systems based on pledges of supp= ort, we build them to minimize trust in any human actors. We can be grateful= that people like Alejandro have worked hard on taprootactivation.com (and t= his effort has informed the discussion) without taking pledges of support as= cast iron guarantees. >>>=20 >>> TL;DR It sounds like you agree with my recommendation to set LOT=3Dfalse= in protocol implementations in my email :) >>>=20 >>>> On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces wrote: >>>=20 >>>> Something what strikes me about the conversation is the emotion surroun= ding the letters UASF. >>>> It appears as if people discuss UASF as if it's a massive tidal wave of= support that is inevitable, like we saw during segwit activation. But the a= ctual definition is "any activation that is not a MASF". >>>> A UASF can consist of a single node, ten nodes, a thousand, half of all= nodes, all business' nodes, or even all the non mining nodes. On another di= mension it can have zero mining support, 51% support, 49% support, or any su= pport right up against a miner activation threshold. >>>> Hell a UASF doesn't even need code or even a single node running as lon= g as it exists as a possibility in people's minds. >>>> The only thing a UASF doesn't have is miner support above an agreed act= ivation threshold (some number above %51). >>>> I say this because it strikes me when people say that they are for LOT=3D= true with the logic that since a UASF is guaranteed to happen then it's bett= er to just make it default from the beginning. Words like coordination and s= afety are sometimes sprinkled into the argument. >>>> The argument comes from a naive assumption that users MUST upgrade to t= he choice that is submitted into code. But in fact this isn't true and some v= oices in this discussion need to be more humble about what users must or mus= t not run. >>>> Does no one realize that it is a very possible outcome that if LOT=3Dtr= ue is released there may be only a handful of people that begin running it w= hile everyone else delays their upgrade (with the very good reason of not ge= tting involved in politics) and a year later those handful of people just be= come stuck at the moment of MUST_SIGNAL, unable to mine new blocks? Or attra= cting a minority of miners, activating, and forking off into a minority fork= . Then a lot=3Dfalse could be started that ends up activating the feature no= w that the stubborn option has ran its course. >>>> The result: a wasted year of waiting and a minority of people who didn'= t want to be lenient with miners by default. The chains could be called Bitc= oinLenient and BitcoinStubborn. >>>> How is that strictly safer or more coordinated? >>>> I may be in the minority, or maybe a silent majority, or maybe a majori= ty that just hasn't considered this as a choice but honestly if there is con= tention about whether we're going to be stubborn or lenient with miners for T= aproot and in the future then I prefer to just not activate anything at all.= I'm fine for calling bitcoin ossified, accepting that segwit is Bitcoin's l= ast network upgrade. Taproot is amazing but no new feature is worth a networ= k split down the middle. >>>> Maybe in 10 or 20 years, when other blockchains implement features like= Taproot and many more, we will become envious enough to put aside our diffe= rences on how to behave towards miners and finally activate Taproot. >>>> An activation mechanism is a consensus change like any other change, ca= n be contentious like any other change, and we must resolve it like any othe= r 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: >>>>=20 >>>>> Yesterday (February 16th) we held a second meeting on Taproot >>>>> activation on IRC which again was open to all. Despite what appeared >>>>> to be majority support for LOT=3Dfalse over LOT=3Dtrue in the first >>>>> meeting I (and others) thought the arguments had not been explored in >>>>> depth and that we should have a follow up meeting almost entirely >>>>> focused on whether LOT (lockinontimeout) should be set to true or >>>>> false. >>>>>=20 >>>>> The meeting was announced here: >>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/= 018380.html >>>>>=20 >>>>> In that mailing list post I outlined the arguments for LOT=3Dtrue (T1 t= o >>>>> T6) and arguments for LOT=3Dfalse (F1 to F6) in their strongest form I= >>>>> could. David Harding responded with an additional argument for >>>>> LOT=3Dfalse (F7) here: >>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/= 018415.html >>>>>=20 >>>>> 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 peo= ple=E2=80=99s views in >>>>> advance. I tried to give time for both the LOT=3Dtrue arguments and th= e >>>>> LOT=3Dfalse arguments to be discussed as I knew there was support for >>>>> both. We only tried evaluating which had more support and which had >>>>> more strong opposition towards the end of the meeting. >>>>>=20 >>>>> The conversation log is here: >>>>> http://gnusha.org/taproot-activation/2021-02-16.log >>>>>=20 >>>>> (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) >>>>>=20 >>>>> A summary of the meeting was provided by Luke Dashjr on Mastodon here:= >>>>> https://bitcoinhackers.org/@lukedashjr/105742918779234566 >>>>>=20 >>>>> Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we= >>>>> did manage to come to consensus on everything but LockinOnTimeout. >>>>>=20 >>>>> Activation height range: 693504-745920 >>>>>=20 >>>>> MASF threshold: 1815/2016 blocks (90%) >>>>>=20 >>>>> Keep in mind only ~100 people showed for the meetings, hardly >>>>> representative of the entire community. >>>>>=20 >>>>> So, these details remain JUST a proposal for now. >>>>>=20 >>>>> It seems inevitable that there won't be consensus on LOT. >>>>>=20 >>>>> Everyone will have to choose for himself. :/ >>>>>=20 >>>>> Personally I agree with most of this. I agree that there wasn=E2=80=99= t >>>>> overwhelming consensus for either LOT=3Dtrue or LOT=3Dfalse. However, f= rom >>>>> my perspective there was clearly more strong opposition (what would >>>>> usually be deemed a NACK in Bitcoin Core review terminology) from >>>>> Bitcoin Core contributors, Lightning developers and other community >>>>> members against LOT=3Dtrue than there was for LOT=3Dfalse. Andrew Chow= >>>>> tried to summarize views from the meeting in this analysis: >>>>> https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c >>>>>=20 >>>>> I am also aware of other current and previous Bitcoin Core >>>>> contributors and Lightning developers who didn=E2=80=99t attend the me= eting 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 logs of= >>>>> not only the meeting but the weeks of discussion prior to this meeting= >>>>> you will see their views evaluated on the ##taproot-activation >>>>> channel. In addition, on taprootactivation.com some mining pools >>>>> expressed a preference for lot=3Dfalse though I don=E2=80=99t know how= strong >>>>> that preference was. >>>>>=20 >>>>> I am only one voice but it is my current assessment that if we are to >>>>> attempt to finalize Taproot activation parameters and propose them to >>>>> the community at this time our only option is to propose LOT=3Dfalse. >>>>> Any further delay appears to me counterproductive in our collective >>>>> aim to get the Taproot soft fork activated as early as possible. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Next week we are planning a code review of the Bitcoin Core PR #19573 >>>>> which was initially delayed because of this LOT discussion. As I=E2=80= =99ve >>>>> said previously that will be loosely following the format of the >>>>> Bitcoin Core PR review club and will be lower level and more >>>>> technical. That is planned for Tuesday February 23rd at 19:00 UTC on >>>>> the IRC channel ##taproot-activation. >>>>>=20 >>>>> Thanks to the meeting participants (and those who joined the >>>>> discussion on the channel prior and post the meeting) for engaging >>>>> productively and in good faith. >>>=20 >>> -- >>> Michael Folkson >>> Email: michaelfolkson@gmail.com >>> Keybase: michaelfolkson >>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >=20 >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev