Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id C074EC000D for ; Fri, 19 Feb 2021 12:05:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id B911D86CCE for ; Fri, 19 Feb 2021 12:05:26 +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 vJ51uoCYqBs0 for ; Fri, 19 Feb 2021 12:05:23 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by whitealder.osuosl.org (Postfix) with ESMTPS id 5FB3F87117 for ; Fri, 19 Feb 2021 12:05:23 +0000 (UTC) Received: from mail-pg1-f176.google.com ([209.85.215.176]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1M73XX-1lDMSM2pxP-008bdX for ; Fri, 19 Feb 2021 13:05:21 +0100 Received: by mail-pg1-f176.google.com with SMTP id t11so3976136pgu.8 for ; Fri, 19 Feb 2021 04:05:21 -0800 (PST) X-Gm-Message-State: AOAM530OViQ7qjTScgdMhQhLE6qrNE19Fa5d2jnvWUWvuZDIXPWmqopt 30oMt1gIxt4nXlBjTimy5EQ51P+Ja5BQ+xj7nZI= X-Google-Smtp-Source: ABdhPJwYWYbY8BofSK7MQzfaCFgyX1pFc1JLqk/986Elza4NxoVIKc/hIgZRaQRUGence2TuaOWkkzjbmE2D1FQcA6Q= X-Received: by 2002:a63:4d4e:: with SMTP id n14mr8245300pgl.37.1613736320385; Fri, 19 Feb 2021 04:05:20 -0800 (PST) MIME-Version: 1.0 References: <8591CF93-E574-4C23-90D5-FA410637DECD@mattcorallo.com> <7b8543c3-8ff2-3a6a-b2d4-f4a6cf150d78@mattcorallo.com> <3MD7z0ETqJZtDw2expUQkoDEwES5BnvCkgjBz4q8h9QRJTK86U9A-EL8pGTprlvjExItC3bz9AxGBNJuk0vqHBX6lnrKqmTEThy9VLA3pNs=@protonmail.com> In-Reply-To: <3MD7z0ETqJZtDw2expUQkoDEwES5BnvCkgjBz4q8h9QRJTK86U9A-EL8pGTprlvjExItC3bz9AxGBNJuk0vqHBX6lnrKqmTEThy9VLA3pNs=@protonmail.com> From: Adam Back Date: Fri, 19 Feb 2021 12:05:09 +0000 X-Gmail-Original-Message-ID: Message-ID: To: ZmnSCPxj , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:NyZnkFh9WSk3eESfJR0yJ8dwO+1eILGAM6OAnJQPH1moXsvZG5E ih2G2nf1OeJRGzef/RdU4WqEojcNIk3VZq6EEM7quvYZfC260H5MYqTCkazExz6lGaGcxXZ SN7kgehw+2vVoAwjiy4JYFjigAG5GBKEG0PRFHdaHpV5VpocbHhUsf8N0RQx910MnTsH8rE EcquBCpebtH1SpwddA9Rw== X-UI-Out-Filterresults: notjunk:1;V03:K0:byFmdS61EVU=:ZEZEs5n5OPJw+6HsNp1tae 2daqMipip8UeHPwU7i62souDuOfWY+W1jT5wd0LlxphWQeYNac47s39L3bco6DjqFYAwrZKNv uPNn9P93cnvuHfJg1bzCyZl5vTtPU1OYy253mwXillNCKlu3tpshg395X/XZxGIEY8XA60C1P IYU9WHpPKgFzydE7tQZx4VDzez2+rnBxuWMjZ5PhjKeLbuglqKOfRXOelvnPHapVtfp1U0Nls /9GqJfFposEvVnUWOpSxcCVXLAO2uy783fthKrO2kUugJicaAIpEhwlxZW/3Po29PtQxl53c5 SMYsaJbPptsp3sjoDWtS/EokIg2NQzXSf2iETSlTgRzqpwcd4BGdsyW4fUGHvvokZvllXYkSj qqQ4mPKWmJI7ibufXRye9P/6E0hTW1QaIe5U7RcRm4dqZpUPNeFF+O2jwsxOFmjq4Wr8dB6Re B1aZaOiuXA== X-Mailman-Approved-At: Fri, 19 Feb 2021 12:42:43 +0000 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 12:05:26 -0000 Personally I don't really have much of a view and think either LOT=3Dtrue or false is better in the context, they both seem safe given the current context, where basically everyone is saying "are we there yet", including pools (88.7% going out of their way to say YES https://taprootactivation.com). Not that pools are deciding of anything, being service providers to miners, who can and will switch pool fast, and miners in-turn being service providers to the market and as the various forks showed will follow the market. I think it's a very good idea for safety, if there is a tested and reviewed code with an option to force LOT=3Dtrue, even if the bitcoin-core implementation ends up defaulting to LOT=3Dfalse. Part of the danger is rushed versions of things like BIP 91 to avoid a chain split where miners left brinkmanship just a bit too late, to avert BIP 148 forking, and BIP 91 was used to expedite activation to avoid that. The rushed proposal, code, review, ship cycle on that was dangerously fast - less time and eyes for review was the danger. > would dev consensus around releasing LOT=3Dfalse be considered as "develo= pers forcing their views on users"? given there are clearly people of both views, or for now don't care but might later, it would minimally be friendly and useful if bitcoin-core has a LOT=3Dtrue option - and that IMO goes some way to avoid the assumptive control via defaults. Otherwise it could be read as saying "developers on average disapprove, but if you, the market disagree, go figure it out for yourself" which is not a good message for being defensive and avoiding mis-interpretation of code repositories or shipped defaults as "control". Adam On Fri, 19 Feb 2021 at 11:30, ZmnSCPxj via bitcoin-dev wrote: > > Good morning list, > > > This is absolutely the case, however note that the activation method it= self is consensus code which executes as a part > > of a fork, and one which deserves as much scrutiny as anything else. Wh= ile taproot is a model of how a soft-fork should > > be designed, this doesn't imply anything about the consensus code which= represents the activation thereof. > > > > Hence all the debate around activation - ultimately its also defining a= fork, 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, an= d if it fails, move on". Various people have > > various views on how conservative and timelines for what to do at that = point, but I believe most in this discussion are > > OK with flag-day-based activation (given some level of care) if it beco= mes clear Taproot is supported by a vast majority > > of Bitcoin users and is only not activating due to lagging miner upgrad= es. > > > Okay, I am backing off this proposal to force the LOT=3Dfalse/true decisi= on on users, it was not particularly serious anyway (and was more a reactio= n to the request of Samson Mow to just release both versions, which to my m= ind 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= reason and we decide to leave LOT=3Dfalse for this particular bit until it= times out. > The issue is that those people will get forked off the network at the end= of this particular deployment attempt. > > I suspect those people will still exist whether or not Bitcoin Core suppo= rts any kind of LOT=3Dtrue mode. > ("Never again" for some people) > > How do we convince them to go run LOT=3Dfalse instead of getting themselv= es forked off? > Or do we simply let them? > > (and how is that different from asking each user to decide on LOT=3Dfalse= /true right now?) > ("reasonable default"?) > (fundamentally speaking you still have to educate the users on the ramifi= cations of accepting the default and changing it.) > > > Another thought experiment: From the point of view of a user who strongly= supports LOT=3Dtrue, would dev consensus around releasing LOT=3Dfalse be c= onsidered 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 cons= idered for activation here. > > > The designation of "soft fork" is accurate but I don't think it adequ= ately conveys how non-intrusive a change like this > > > is. All that taproot does (unless I'm completely missing something) i= s imbue a previously undefined script version with > > > actual semantics. In order for a chain reorg to take place it would m= ean that someone would have to have a use case for > > > that script version today. This is something I think that we can easi= ly check by digging through the UTXO set or > > > history. If anyone is using that script version, we absolutely should= not 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 chan= ge has no effect on whether a chain split occurs > > > because there is simply no block that contains a transaction that onl= y some of the network will accept. > > > Furthermore, I don't know how Bitcoin can stand the test of time if w= e allow developers who rely on "undefined behavior" > > > (which the taproot script version presently is) to exert tremendous i= nfluence over what code does or does not get run. > > > This isn't a soft fork that makes some particular UTXO's unspendable.= It isn't one that bans miners from collecting > > > fees. It is a change that means that certain "always accept" transact= ions 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 set= s 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 unt= il now. I don't think this is a more desirable > > > outcome to let ~0.1% of the network get to block /non-intrusive/ chan= ges that the rest of the network wants. > > > I can certainly live with an L=3DF attempt as a way to punt on the di= scussion, maybe the activation happens and this will > > > all be fine. But if it doesn't, I hardly think that users of Bitcoin = are just going to be like "well, guess that's it > > > for Taproot". I have no idea what ensues at that point, but probably = another community led UASF movement. > > > I wasn't super well educated on this stuff back in '17 when Segwit we= nt 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 = treat 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 consid= er activation to ensure we reduce the risk of that as > > > much as absolutely possible. Again, while I think Taproot is a hu= ge 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 go= od. > > > > > > Matt > > > > > > On 2/18/21 09:26, Michael Folkson wrote: > > > > Thanks for your response Matt. It is a fair challenge. There i= s always going to be an element of risk with soft > > > forks, > > > > all we can do is attempt to minimize that risk. I would argue = that risk has been minimized for Taproot. > > > > > > > > You know (better than I do in fact) that Bitcoin (and layers b= uilt on top of it) greatly benefit from upgrades > > > such as > > > > Taproot. To say we shouldn't do Taproot or any future soft for= ks because there is a small but real risk of chain > > > splits > > > > I think is shortsighted. Indeed I think even if we collectivel= y decided not to do any future soft fork upgrades ever > > > > again on this mailing list that wouldn't stop soft fork attemp= ts from other people in future. > > > > > > > > I don't think there is anything else we can do to minimize tha= t risk for the Taproot soft fork at this point > > > though I'm > > > > open to ideas. To reiterate that risk will never be zero. I do= n't think I see Bitcoin as fragile as you seem to > > > (though > > > > admittedly you have a much better understanding than me of wha= t happened in 2017). > > > > > > > > The likely scenario for the Taproot soft fork is LOT turns out= to be entirely irrelevant and miners activate Taproot > > > > before it becomes relevant. And even the unlikely worst case s= cenario 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: > > > > > > > > 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 tru= e with Knots) ship different consensus rules, we should stop 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-de= v > > > > > >> >> wrote: > > > >> > > > >> =EF=BB=BF > > > >> Right, that is one option. Personally I would prefer a Bi= tcoin Core release sets LOT=3Dfalse (based on what I have > > > >> heard from Bitcoin Core contributors) and a community eff= ort releases a version with LOT=3Dtrue. I don't think > > > users > > > >> should be forced to choose something they may have no con= text on before they are allowed to use Bitcoin Core. > > > >> > > > >> My current understanding is that roasbeef is planning to = set LOT=3Dfalse on btcd (an alternative protocol > > > >> implementation to Bitcoin Core) and Luke Dashjr hasn't ye= t decided on Bitcoin Knots. > > > >> > > > >> > > > >> > > > >> On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj > > > >= > wrote: > > > >> > > > >> 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 other 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=3Dfalse, would be to have a release that > > > >> requires a `taprootlot=3D1` or `taprootlot=3D0` and r= efuses to start if the parameter is not set. > > > >> > > > >> This assures everyone that neither choice is being fo= rced on users, and instead what is being forced on > > > users, > > > >> is for users to make that choice themselves. > > > >> > > > >> 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 usefu= l if you responded to specific points I have made > > > in the > > > >> mailing list post or at least quote these ephemeral "= people" you speak of. I don't know if you're responding > > > >> to conversation 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 some 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 forced to run any particular > > > software > > > >> version, quite the opposite. Defaults 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 if LOT=3Dtrue is released there may be > > > only a > > > >> handful of people that begin running it while everyon= e else delays their upgrade (with the very good > > > reason of > > > >> not getting involved in politics) and a year later th= ose handful of people just become stuck at the > > > moment of > > > >> MUST_SIGNAL, unable to mine new blocks? > > > >> > > > > > >> > > It is a possible outcome but the likely outcome i= s that miners activate Taproot before LOT is even > > > >> relevant. I think it is prudent to prepare for the un= likely but possible outcome that miners fail to > > > activate > > > >> and hence have this discussion now rather than be unp= repared 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 > > > > > > >> > > >) 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 mino= rity of people who didn't want to be lenient with > > > miners > > > >> by default. > > > >> > > > > > >> > > 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 perception tha= t LOT=3Dtrue is antagonistic to miners. I actually > > > think it > > > >> offers them clarity on what will happen over a year t= ime period and removes the need for coordinated or > > > >> uncoordinated community UASF efforts on top of LOT=3D= false. > > > >> > > > > > >> > > > An activation mechanism is a consensus change l= ike 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. > > > >> > > > > > >> > > I don't know what you are recommending here to av= oid "this darkest timeline". Open discussions have > > > >> occurred and are continuing and in my mailing list po= st that you responded to **I recommended we propose > > > >> LOT=3Dfalse be set in protocol implementations such a= s Bitcoin Core**. I do think this apocalyptic language > > > >> isn't particularly helpful. In an open consensus syst= em discussion is healthy, we should prepare for bad or > > > >> worst case scenarios in advance and doing so is not a= ntagonistic or destructive. Mining pools have 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 pe= ople like Alejandro have worked hard on > > > >> taprootactivation.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 recommenda= tion to set LOT=3Dfalse in protocol implementations in my > > > >> email :) > > > >> > > > > > >> > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Lua= ces > > > > > >> >> wrote: > > > >> > > > > > >> > > > Something what strikes me about the conversatio= n is the emotion surrounding 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 actual defin= ition 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 dimension i= t can have zero mining support, 51% support, 49% > > > support, > > > >> or any support right up against a miner activation th= reshold. > > > >> > > > Hell a UASF doesn't even need code or even a si= ngle node running as long as it exists as a possibility > > > >> in people's minds. > > > >> > > > The only thing a UASF doesn't have is miner sup= port above an agreed activation threshold (some number > > > >> above %51). > > > >> > > > I say this because it strikes me when people sa= y that they are for LOT=3Dtrue with the logic that > > > since a > > > >> UASF is guaranteed to happen then it's better to just= make it default from the beginning. 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 some 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=3Dtrue is released there may be > > > only a > > > >> handful of people that begin running it while everyon= e else delays their upgrade (with the very good > > > reason of > > > >> not getting involved in politics) and a year later th= ose handful of people 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 > > > >> minority fork. Then a lot=3Dfalse could be started th= at ends up activating the feature now that the stubborn > > > >> option has ran its course. > > > >> > > > The result: a wasted year of waiting and a mino= rity of people who didn't want to be lenient with > > > miners > > > >> by default. The chains could be called BitcoinLenient= and BitcoinStubborn. > > > >> > > > How is that strictly safer or more coordinated? > > > >> > > > I may be in the minority, or maybe a silent maj= ority, or maybe a majority 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 at all. 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 network 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 differences on= how to behave towards miners and finally activate > > > Taproot. > > > >> > > > An activation mechanism is a consensus change l= ike 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. > > > >> > > > Cheers > > > >> > > > Ariel Lorenzo-Luaces > > > >> > > > On Feb 17, 2021, at 7:05 AM, Michael Folkson vi= a bitcoin-dev > > > > > > >> >> wrote: > > > >> > > > > > > >> > > > > Yesterday (February 16th) we held a second me= eting on Taproot > > > >> > > > > activation on IRC which again was open to all= . Despite what appeared > > > >> > > > > to be majority support for LOT=3Dfalse over L= OT=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 mee= ting almost entirely > > > >> > > > > focused on whether LOT (lockinontimeout) shou= ld be set to true or > > > >> > > > > false. > > > >> > > > > > > > >> > > > > The meeting was announced here: > > > >> > > > > https://lists.linuxfoundation.org/pipermail/b= itcoin-dev/2021-February/018380.html > > > > > > >> > > > > > > >> > > > > > > > >> > > > > In that mailing list post I outlined the argu= ments for LOT=3Dtrue (T1 to > > > >> > > > > T6) and arguments for LOT=3Dfalse (F1 to F6) = in their strongest form I > > > >> > > > > could. David Harding responded with an additi= onal argument for > > > >> > > > > LOT=3Dfalse (F7) here: > > > >> > > > > https://lists.linuxfoundation.org/pipermail/b= itcoin-dev/2021-February/018415.html > > > > > > >> > > > > > > >> > > > > > > > >> > > > > These meetings are very challenging given the= y are open to all, you > > > >> > > > > don=E2=80=99t know who will attend and you do= n=E2=80=99t know most people=E2=80=99s views in > > > >> > > > > advance. I tried to give time for both the LO= T=3Dtrue arguments and the > > > >> > > > > LOT=3Dfalse arguments to be discussed as I kn= ew 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. > > > >> > > > > > > > >> > > > > 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=9CBitcoi= n=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 here: > > > >> > > > > https://bitcoinhackers.org/@lukedashjr/105742= 918779234566 > > > > > > >> > > > > > > >> > > > > > > > >> > > > > Today's #Bitcoin #Taproot meeting was IMO lar= gely 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 conse= nsus 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. However, from > > > >> > > > > my perspective there was clearly more strong = opposition (what would > > > >> > > > > usually be deemed a NACK in Bitcoin Core revi= ew terminology) from > > > >> > > > > Bitcoin Core contributors, Lightning develope= rs 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/3e179501290a= bb7049de198d46894c7c > > > > > > >> > > > > > > >> > > > > > > > >> > > > > I am also aware of other current and previous= Bitcoin Core > > > >> > > > > contributors and Lightning developers who did= n=E2=80=99t attend the 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 logs of > > > >> > > > > not only the meeting but the weeks of discuss= ion prior to this meeting > > > >> > > > > you will see their views evaluated on the ##t= aproot-activation > > > >> > > > > channel. In addition, on taprootactivation.co= m > > > > 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 asse= ssment that if we are to > > > >> > > > > attempt to finalize Taproot activation parame= ters and propose them to > > > >> > > > > the community at this time our only option is= to propose LOT=3Dfalse. > > > >> > > > > Any further delay appears to me counterproduc= tive in our collective > > > >> > > > > aim to get the Taproot soft fork activated as= early as possible. > > > >> > > > > > > > >> > > > > Obviously others are free to disagree with th= at assessment and > > > >> > > > > continue discussions but personally I will be= attempting to avoid > > > >> > > > > those discussions unless prominent new inform= ation comes to light or > > > >> > > > > various specific individuals change their min= ds. > > > >> > > > > > > > >> > > > > Next week we are planning a code review of th= e Bitcoin Core PR #19573 > > > >> > > > > which was initially delayed because of this L= OT discussion. As I=E2=80=99ve > > > >> > > > > said previously that will be loosely followin= g the format of the > > > >> > > > > Bitcoin Core PR review club and will be lower= level and more > > > >> > > > > technical. That is planned for Tuesday Februa= ry 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 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/listinf= o/bitcoin-dev > > > > > > >> > > > > > > >> > > > >> > > > >> > > > >> > > > >> -- > > > >> 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-de= v > > > > > > >> > > > > > > > > > > > > > > > > > > > -- > > > > 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 > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev