Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id CA1FCC000D for ; Fri, 19 Feb 2021 11:30:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id AC5086068A for ; Fri, 19 Feb 2021 11:30:22 +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 IR900OKtZhCn for ; Fri, 19 Feb 2021 11:30:19 +0000 (UTC) Received: by smtp3.osuosl.org (Postfix, from userid 1001) id 71A5E606D7; Fri, 19 Feb 2021 11:30:19 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by smtp3.osuosl.org (Postfix) with ESMTPS id 21E99606D8 for ; Fri, 19 Feb 2021 11:30:14 +0000 (UTC) Date: Fri, 19 Feb 2021 11:30:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1613734209; bh=7YKfckDAIxEgXJfR06tjEEm2qx389JMMyYN3/NAdEH4=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=j7ZL93H9jALcjcOjaeS+aA4Bt5JHgGNvoRw3wUzlWxS3ASHKtiasGD1DZFdKiB2cX 5FQkTbHFjQCF8wDiQmZJJX7N0al0tZBQlmVzeW9LtKg2BehDUb4vcvZSsbhUWEizHN tLShD1ohWzEH1LLIvPIrvC90+vcWTrB/OG16n2T4= To: Matt Corallo , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <3MD7z0ETqJZtDw2expUQkoDEwES5BnvCkgjBz4q8h9QRJTK86U9A-EL8pGTprlvjExItC3bz9AxGBNJuk0vqHBX6lnrKqmTEThy9VLA3pNs=@protonmail.com> In-Reply-To: References: <8591CF93-E574-4C23-90D5-FA410637DECD@mattcorallo.com> <7b8543c3-8ff2-3a6a-b2d4-f4a6cf150d78@mattcorallo.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: Fri, 19 Feb 2021 11:30:22 -0000 Good morning list, > This is absolutely the case, however note that the activation method itse= lf is consensus code which executes as a part > of a fork, and one which deserves as much scrutiny as anything else. Whil= e taproot is a model of how a soft-fork should > be designed, this doesn't imply anything about the consensus code which r= epresents the activation thereof. > > Hence all the debate around activation - ultimately its also defining a f= ork, and given the politics around it, one > which almost certainly carries significantly more risk than Taproot. > > Note that I don't believe anyone is advocating for "try to activate, and = if it fails, move on". Various people have > various views on how conservative and timelines for what to do at that po= int, but I believe most in this discussion are > OK with flag-day-based activation (given some level of care) if it become= s clear Taproot is supported by a vast majority > of Bitcoin users and is only not activating due to lagging miner upgrades= . Okay, I am backing off this proposal to force the LOT=3Dfalse/true decision= on users, it was not particularly serious anyway (and was more a reaction = to the request of Samson Mow to just release both versions, which to my min= d is no different from such a thing). Nonetheless, as a thought experiment: the main issue is that some number of= people run LOT=3Dtrue when miners do not activate Taproot early for some r= eason and we decide to leave LOT=3Dfalse for this particular bit until it t= imes out. The issue is that those people will get forked off the network at the end o= f this particular deployment attempt. I suspect those people will still exist whether or not Bitcoin Core support= s any kind of LOT=3Dtrue mode. ("Never again" for some people) How do we convince them to go run LOT=3Dfalse instead of getting themselves= forked off? Or do we simply let them? (and how is that different from asking each user to decide on LOT=3Dfalse/t= rue right now?) ("reasonable default"?) (fundamentally speaking you still have to educate the users on the ramifica= tions of accepting the default and changing it.) Another thought experiment: From the point of view of a user who strongly s= upports LOT=3Dtrue, would dev consensus around releasing LOT=3Dfalse be con= sidered as "developers forcing their views on users"? Why or why not? Regards, ZmnSCPxj > Matt > > On 2/18/21 10:04, Keagan McClelland wrote: > > > Hi all, > > I think it's important for us to consider what is actually being consid= ered for activation here. > > The designation of "soft fork" is accurate but I don't think it adequat= ely conveys how non-intrusive a change like this > > is. All that taproot does (unless I'm completely missing something) is = imbue a previously undefined script version with > > actual semantics. In order for a chain reorg to take place it would mea= n that someone would have to have a use case for > > that script version today. This is something I think that we can easily= check by digging through the UTXO set or > > history. If anyone is using that script version, we absolutely should n= ot be using it, but that doesn't mean that we > > can't switch to a script version that no one is actually using. > > If no one is even attempting to use the script version, then the change= has no effect on whether a chain split occurs > > because there is simply no block that contains a transaction that only = some of the network will accept. > > Furthermore, I don't know how Bitcoin can stand the test of time if we = allow developers who rely on "undefined behavior" > > (which the taproot script version presently is) to exert tremendous inf= luence over what code does or does not get run. > > This isn't a soft fork that makes some particular UTXO's unspendable. I= t isn't one that bans miners from collecting > > fees. It is a change that means that certain "always accept" transactio= ns actually have real conditions you have to > > meet. I can't imagine a less intrusive change. > > On the other hand, choosing to let L=3DF be a somewhat final call sets = a very real precedent that 10% of what I estimate > > to be 1% of bitcoin users can effectively block any change from here on= forward. At that point we are saying that miners > > are in control of network consensus in ways they have not been up until= now. I don't think this is a more desirable > > outcome to let ~0.1% of the network get to block /non-intrusive/=C2= =A0changes that the rest of the network wants. > > I can certainly live with an L=3DF attempt as a way to punt on the disc= ussion, maybe the activation happens and this will > > all be fine. But if it doesn't, I hardly think that users of Bitcoin ar= e just going to be like "well, guess that's it > > for Taproot". I have no idea what ensues at that point, but probably an= other community led UASF movement. > > I wasn't super well educated on this stuff back in '17 when Segwit went= down, as I was new at that time, so if I'm > > missing something please say so. But from my point of view, we can't tr= eat all soft forks as equal. > > Keagan > > On Thu, Feb 18, 2021 at 7:43 AM Matt Corallo via bitcoin-dev > mailto:bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > We've had several softforks in Bitcoin which, through the course of= their activation, had a several-block reorg. That > > should be indication enough that we need to very carefully consider= activation to ensure we reduce the risk of that as > > much as absolutely possible. Again, while I think Taproot is a huge= improvement and am looking forward to being able to > > use it, getting unlucky and hitting a 4-block reorg that happens to= include a double-spend and some PR around an > > exchange losing millions would be worse than having Taproot is good= . > > > > Matt > > > > On 2/18/21 09:26, Michael Folkson wrote: > > > Thanks for your response Matt. It is a fair challenge. There is = always going to be an element of risk with soft > > forks, > > > all we can do is attempt to minimize that risk. I would argue th= at risk has been minimized for Taproot. > > > > > > You know (better than I do in fact) that Bitcoin (and layers bui= lt on top of it) greatly benefit from upgrades > > such as > > > Taproot. To say we shouldn't do Taproot or any future soft forks= because there is a small but real risk of chain > > splits > > > I think is shortsighted. Indeed I think even if we collectively= =C2=A0decided not to do any future soft fork upgrades ever > > > again on this mailing list that wouldn't stop soft fork attempts= from other people in future. > > > > > > I don't think there is anything else we can do to minimize that = risk for the Taproot soft fork at this point > > though I'm > > > open to ideas. To reiterate that risk will never be zero. I don'= t think I see Bitcoin as fragile as you seem to > > (though > > > admittedly you have a much better understanding than me of what = happened in 2017). > > > > > > The likely scenario for the Taproot soft fork is LOT turns out t= o be entirely irrelevant and miners activate Taproot > > > before it becomes relevant. And even the unlikely worst case sce= nario would only cause short term disruption and > > > wouldn't kill Bitcoin long term. > > > > > > On Thu, Feb 18, 2021 at 2:01 PM Matt Corallo > > >= > wrote: > > > > > >=C2=A0 =C2=A0 =C2=A0If the eventual outcome is that different imp= lementations (that have material *transaction processing* userbases, > > >=C2=A0 =C2=A0 =C2=A0and 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 > > >=C2=A0 =C2=A0 =C2=A0activate Taproot. Seriously. > > > > > >=C2=A0 =C2=A0 =C2=A0Bitcoin is a consensus system. The absolute w= orst outcome at all possible is to have it fall out of consensus. > > > > > >=C2=A0 =C2=A0 =C2=A0Matt > > > > > >>=C2=A0 =C2=A0 =C2=A0On Feb 18, 2021, at 08:11, Michael Folkson v= ia bitcoin-dev > > > >>=C2=A0 =C2=A0 =C2=A0>> wrote: > > >> > > >>=C2=A0 =C2=A0 =C2=A0=EF=BB=BF > > >>=C2=A0 =C2=A0 =C2=A0Right, that is one option. Personally I woul= d prefer a Bitcoin Core release sets LOT=3Dfalse (based on what I have > > >>=C2=A0 =C2=A0 =C2=A0heard from Bitcoin Core contributors) and a = community effort releases a version with LOT=3Dtrue. I don't think > > users > > >>=C2=A0 =C2=A0 =C2=A0should be forced to choose something they ma= y have no context on before they are allowed to use Bitcoin Core. > > >> > > >>=C2=A0 =C2=A0 =C2=A0My current understanding is that roasbeef is= planning to set LOT=3Dfalse on btcd (an alternative protocol > > >>=C2=A0 =C2=A0 =C2=A0implementation to Bitcoin Core) and Luke Das= hjr hasn't yet decided on Bitcoin Knots. > > >> > > >> > > >> > > >>=C2=A0 =C2=A0 =C2=A0On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj > > >> = wrote: > > >> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Good morning all, > > >> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> "An activation mechanism is = a consensus change like any other change, can be contentious like any other > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0change, and we must resolve it= like any other change. Otherwise we risk arriving at the darkest timeline.= " > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Who's we here? > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Release both and let the net= work decide. > > >> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A thing that could be done, wi= thout mandating either LOT=3Dtrue or LOT=3Dfalse, would be to have a releas= e that > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0requires a `taprootlot=3D1` or= `taprootlot=3D0` and refuses to start if the parameter is not set. > > >> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This assures everyone that nei= ther choice is being forced on users, and instead what is being forced on > > users, > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is for users to make that choi= ce themselves. > > >> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regards, > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ZmnSCPxj > > >> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> On Thu, Feb 18, 2021 at 3:08= AM Michael Folkson via bitcoin-dev > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> wrote: > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > Thanks for your response A= riel. It would be useful if you responded to specific points I have made > > in the > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mailing list post or at least = quote these ephemeral "people" you speak of. I don't know if you're respond= ing > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to conversation on the IRC cha= nnel or on social media etc. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > The argument comes from = a naive assumption that users MUST upgrade to the choice that is submitted > > into > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0code. But in fact this isn't t= rue and some voices in this discussion need to be more humble about what us= ers > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0must or must not run. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > I personally have never ma= de this assumption. Of course users aren't forced to run any particular > > software > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0version, quite the opposite. D= efaults set in software versions matter though as many users won't change > > them. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > Does no one realize that= it is a very possible outcome that if LOT=3Dtrue is released there may be > > only a > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0handful of people that begin r= unning it while everyone else delays their upgrade (with the very good > > reason of > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not getting involved in politi= cs) and a year later those handful of people just become stuck at the > > moment of > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST_SIGNAL, unable to mine ne= w blocks? > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > It is a possible outcome b= ut the likely outcome is that miners activate Taproot before LOT is even > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0relevant. I think it is pruden= t to prepare for the unlikely but possible outcome that miners fail to > > activate > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and hence have this discussion= now rather than be unprepared for that eventuality. If LOT is set to > > false in a > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0software release there is the = possibility (T2 in > > >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Fe= bruary/018380.html > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > >) of individuals or a > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proportion of the community ch= anging LOT to true. In that sense setting LOT=3Dfalse in a software release > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0appears to be no more safe tha= n LOT=3Dtrue. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > The result: a wasted yea= r of waiting and a minority of people who didn't want to be lenient with > > miners > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by default. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > There is the (unlikely but= possible) possibility of a wasted year if LOT is set to false and miners f= ail > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to activate. I'm not convinced= by this perception that LOT=3Dtrue is antagonistic to miners. I actually > > think it > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0offers them clarity on what wi= ll happen over a year time period and removes the need for coordinated or > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uncoordinated community UASF e= fforts on top of LOT=3Dfalse. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > An activation mechanism = is a consensus change like any other change, can be contentious like any ot= her > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0change, and we must resolve it= like any other change. Otherwise we risk arriving at the darkest timeline. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > I don't know what you are = recommending here to avoid "this darkest timeline". Open discussions have > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0occurred and are continuing an= d in my mailing list post that you responded to **I recommended we propose > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LOT=3Dfalse be set in protocol= implementations such as Bitcoin Core**. I do think this apocalyptic langua= ge > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0isn't particularly helpful. In= an open consensus system discussion is healthy, we should prepare for bad = or > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0worst case scenarios in advanc= e and doing so is not antagonistic or destructive. Mining pools=C2=A0have p= ledged > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0support for Taproot but we don= 't build secure systems based on pledges of support, we build them to minim= ize > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0trust in any human actors. We = can be grateful that people like Alejandro have worked hard on > > >> taprootactivation.com > > (and this effort has informed the d= iscussion) without > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0taking pledges of support as c= ast iron guarantees. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > TL;DR It sounds like you a= gree with my recommendation to set LOT=3Dfalse in protocol implementations = in my > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0email :) > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > On Thu, Feb 18, 2021 at 5:= 43 AM Ariel Lorenzo-Luaces > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> wrote: > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > Something what strikes m= e about the conversation is the emotion surrounding the letters UASF. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > It appears as if people = discuss UASF as if it's a massive tidal wave of support that is > > inevitable, like > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0we saw during segwit activatio= n. But the actual definition is "any activation that is not a MASF". > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > A UASF can consist of a = single node, ten nodes, a thousand, half of all nodes, all business' nodes,= or > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0even all the non mining nodes.= On another dimension it can have zero mining support, 51% support, 49% > > support, > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0or any support right up agains= t a miner activation threshold. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > Hell a UASF doesn't even= need code or even a single node running as long as it exists as a possibil= ity > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in people's minds. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > The only thing a UASF do= esn't have is miner support above an agreed activation threshold (some numb= er > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0above %51). > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > I say this because it st= rikes me when people say that they are for LOT=3Dtrue with the logic that > > since a > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0UASF is guaranteed to happen t= hen it's better to just make it default from the beginning. Words like > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0coordination and safety are so= metimes sprinkled into the argument. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > The argument comes from = a naive assumption that users MUST upgrade to the choice that is submitted > > into > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0code. But in fact this isn't t= rue and some voices in this discussion need to be more humble about what us= ers > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0must or must not run. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > Does no one realize that= it is a very possible outcome that if LOT=3Dtrue is released there may be > > only a > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0handful of people that begin r= unning it while everyone else delays their upgrade (with the very good > > reason of > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not getting involved in politi= cs) and a year later those handful of people just become stuck at the > > moment of > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST_SIGNAL, unable to mine ne= w blocks? Or attracting a minority of miners, activating, and forking off > > into a > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0minority fork. Then a lot=3Dfa= lse could be started that ends up activating the feature now that the stubb= orn > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0option has ran its course. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > The result: a wasted yea= r of waiting and a minority of people who didn't want to be lenient with > > miners > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by default. The chains could b= e called BitcoinLenient and BitcoinStubborn. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > How is that strictly saf= er or more coordinated? > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > I may be in the minority= , or maybe a silent majority, or maybe a majority that just hasn't consider= ed > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this as a choice but honestly = if there is contention about whether we're going to be stubborn or lenient > > with > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0miners for Taproot and in the = future then I prefer to just not activate anything at all. I'm fine for > > calling > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bitcoin ossified, accepting th= at segwit is Bitcoin's last network upgrade. Taproot is amazing but no new > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0feature is worth a network spl= it down the middle. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > Maybe in 10 or 20 years,= when other blockchains implement features like Taproot and many more, we w= ill > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0become envious enough to put a= side our differences on how to behave towards miners and finally activate > > Taproot. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > An activation mechanism = is a consensus change like any other change, can be contentious like any ot= her > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0change, and we must resolve it= like any other change. Otherwise we risk arriving at the darkest timeline. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > Cheers > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > Ariel Lorenzo-Luaces > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > On Feb 17, 2021, at 7:05= AM, Michael Folkson via bitcoin-dev > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> wrote: > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Yesterday (February 16= th) we held a second meeting on Taproot > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > activation on IRC whic= h again was open to all. Despite what appeared > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > to be majority support= for LOT=3Dfalse over LOT=3Dtrue in the first > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > meeting I (and others)= thought the arguments had not been explored in > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > depth and that we shou= ld have a follow up meeting almost entirely > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > focused on whether LOT= (lockinontimeout) should be set to true or > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > false. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > The meeting was announ= ced here: > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > https://lists.linuxfou= ndation.org/pipermail/bitcoin-dev/2021-February/018380.html > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > In that mailing list p= ost I outlined the arguments for LOT=3Dtrue (T1 to > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > T6) and arguments for = LOT=3Dfalse (F1 to F6) in their strongest form I > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > could. David Harding r= esponded with an additional argument for > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > LOT=3Dfalse (F7) here: > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > https://lists.linuxfou= ndation.org/pipermail/bitcoin-dev/2021-February/018415.html > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > These meetings are ver= y challenging given they are open to all, you > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > don=E2=80=99t know who= will attend and you don=E2=80=99t know most people=E2=80=99s views in > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > advance. I tried to gi= ve time for both the LOT=3Dtrue arguments and the > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > LOT=3Dfalse arguments = to be discussed as I knew there was support for > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > both. We only tried ev= aluating which had more support and which had > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > more strong opposition= towards the end of the meeting. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > The conversation log i= s here: > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > http://gnusha.org/tapr= oot-activation/2021-02-16.log > > > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > (If you are so incline= d you can watch a video of the meeting here. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Thanks to the YouTube = account =E2=80=9CBitcoin=E2=80=9D for setting up the livestream: > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > https://www.youtube.co= m/watch?v=3Dvpl5q1ovMLM > > >) > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > A summary of the meeti= ng was provided by Luke Dashjr on Mastodon here: > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > https://bitcoinhackers= .org/@lukedashjr/105742918779234566 > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Today's #Bitcoin #Tapr= oot meeting was IMO largely unproductive, but we > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > did manage to come to = consensus on everything but LockinOnTimeout. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Activation height rang= e: 693504-745920 > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > MASF threshold: 1815/2= 016 blocks (90%) > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Keep in mind only ~100= people showed for the meetings, hardly > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > representative of the = entire community. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > So, these details rema= in JUST a proposal for now. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > It seems inevitable th= at there won't be consensus on LOT. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Everyone will have to = choose for himself. :/ > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Personally I agree wit= h most of this. I agree that there wasn=E2=80=99t > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > overwhelming consensus= for either LOT=3Dtrue or LOT=3Dfalse. However, from > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > my perspective there w= as clearly more strong opposition (what would > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > usually be deemed a NA= CK in Bitcoin Core review terminology) from > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Bitcoin Core contribut= ors, Lightning developers and other community > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > members against LOT=3D= true than there was for LOT=3Dfalse. Andrew Chow > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > tried to summarize vie= ws from the meeting in this analysis: > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > https://gist.github.co= m/achow101/3e179501290abb7049de198d46894c7c > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > I am also aware of oth= er current and previous Bitcoin Core > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > contributors and Light= ning developers who didn=E2=80=99t attend the meeting in > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > person who are opposed= to LOT=3Dtrue. I don=E2=80=99t want to put them in the > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > spotlight for no reaso= n but if you go through the conversation logs of > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > not only the meeting b= ut the weeks of discussion prior to this meeting > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > you will see their vie= ws evaluated on the ##taproot-activation > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > channel. In addition, = on taprootactivation.com > > > some = mining pools > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > expressed a preference= for lot=3Dfalse though I don=E2=80=99t know how strong > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > that preference was. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > I am only one voice bu= t it is my current assessment that if we are to > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > attempt to finalize Ta= proot activation parameters and propose them to > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > the community at this = time our only option is to propose LOT=3Dfalse. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Any further delay appe= ars to me counterproductive in our collective > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > aim to get the Taproot= soft fork activated as early as possible. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Obviously others are f= ree to disagree with that assessment and > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > continue discussions b= ut personally I will be attempting to avoid > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > those discussions unle= ss prominent new information comes to light or > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > various specific indiv= iduals change their minds. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Next week we are plann= ing a code review of the Bitcoin Core PR #19573 > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > which was initially de= layed because of this LOT discussion. As I=E2=80=99ve > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > said previously that w= ill be loosely following the format of the > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Bitcoin Core PR review= club and will be lower level and more > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > technical. That is pla= nned for Tuesday February 23rd at 19:00 UTC on > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > the IRC channel ##tapr= oot-activation. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Thanks to the meeting = participants (and those who joined the > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > discussion on the chan= nel prior and post the meeting) for engaging > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > productively and in go= od faith. > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > -- > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > Michael Folkson > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > Email: michaelfolkson@gmai= l.com > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > Keybase: michaelfolkson > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > PGP: 43ED C999 9F85 1D40 E= AF4 9835 92D6 0159 214C FEE3 > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > __________________________= _____________________ > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > bitcoin-dev mailing list > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > bitcoin-dev@lists.linuxfou= ndation.org > > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > https://lists.linuxfoundat= ion.org/mailman/listinfo/bitcoin-dev > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > > > > >> > > >> > > >> > > >> > > >>=C2=A0 =C2=A0 =C2=A0-- > > >>=C2=A0 =C2=A0 =C2=A0Michael Folkson > > >>=C2=A0 =C2=A0 =C2=A0Email: michaelfolkson@gmail.com > > > > >>=C2=A0 =C2=A0 =C2=A0Keybase: michaelfolkson > > >>=C2=A0 =C2=A0 =C2=A0PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159= 214C FEE3 > > >>=C2=A0 =C2=A0 =C2=A0____________________________________________= ___ > > >>=C2=A0 =C2=A0 =C2=A0bitcoin-dev mailing list > > >> bitcoin-dev@lists.linuxfoundation.org > > > > > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > >>=C2=A0 =C2=A0 =C2=A0 > > > > > > > > > > > > > > -- > > > 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 > > > > > > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev