Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id BE744C000D for ; Thu, 18 Feb 2021 15:05:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 924A06062D for ; Thu, 18 Feb 2021 15:05:16 +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 pNft8Hrb09N8 for ; Thu, 18 Feb 2021 15:05:12 +0000 (UTC) Received: by smtp3.osuosl.org (Postfix, from userid 1001) id 6DC87605F9; Thu, 18 Feb 2021 15:05:12 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) by smtp3.osuosl.org (Postfix) with ESMTPS id 6ABFB60656 for ; Thu, 18 Feb 2021 15:05:07 +0000 (UTC) Received: by mail-wr1-f45.google.com with SMTP id r21so3320505wrr.9 for ; Thu, 18 Feb 2021 07:05:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I2nYbvjRVLrv/1t7CyvIAMQgM5wO3wQHMEJbGJ2G73Q=; b=Cm8DvMZPP/V+9BG+V5aMLME9WmoTKDs24LN0ychdtRIuPXK3jikgnhjpOIhzlNqcGb Sx/cA2jeTj0hqocABV0WeH84X5+U2svxln4DOFYgcIK/Z2luuuhf61u2w0vBONx6W5wI d+vDmUquHNoREO49CrA2w4NQy26mjFkGJvoRT1hGbXSL6Ydrhz/gYDHnxCmlKAUfb6IP im0G/TR2XNCMNCqZ2IF4LIkRM5pEf/DEkLpWpq4JXsa+myeAaihN5TIlQiy0SLRhX/OY fD2kRn1uCGd4tpwS7Lm0bQBmiGk9QkfIq17kA37vkNbGkBZTXd8BayjnmaCzuFKv7Sag EPjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=I2nYbvjRVLrv/1t7CyvIAMQgM5wO3wQHMEJbGJ2G73Q=; b=q0HcNcfsn3it34LZjI2yK1QqurB2bDPJXZ/inN/YSrzt+0e6ALYtqjVrLz0KBXL+E/ iLelKRQ94bnn1Bv5+HYhQuX0G2adWsR/tGKKM9FouczYe3Iq9mHsfx1wzOWVYm22dRH6 DGCsZoYC4PAp25Bmy8pqvR1cIRMItJgAlzLB5KGOLDQ8gP3C3oF1iZCNgCcFP6dx2Sh7 pGRisRb2bjXNF8gvHv5kg++QtUbv5ATj5a8bHsNbkXsCo5bR62JvX24l0QrufrzJktaA Xh0rZ2H0n7nhbY/NFQwMxdCY3ozi5NroX47eX6KT2r/xYY7hh4RDzPxHkrti/DMxUblg FqDw== X-Gm-Message-State: AOAM531g7I+pvTr7r6DbAiDK5DlLDlX6ej1Q25IoN/ipvNIAHJZfRiG6 djw0cNp4GbGnlR6OB10TMH/tJGIpi0DLmgla+W8= X-Google-Smtp-Source: ABdhPJyq+Catym2CYUJZWZQQEABpVJd0irApyWwsNeRpUnzLJbew0aM0NeGAhQkIf2eK2RsANA6vZocaynCs2vH9mbs= X-Received: by 2002:adf:97d3:: with SMTP id t19mr4901396wrb.164.1613660705246; Thu, 18 Feb 2021 07:05:05 -0800 (PST) MIME-Version: 1.0 References: <8591CF93-E574-4C23-90D5-FA410637DECD@mattcorallo.com> <7b8543c3-8ff2-3a6a-b2d4-f4a6cf150d78@mattcorallo.com> In-Reply-To: <7b8543c3-8ff2-3a6a-b2d4-f4a6cf150d78@mattcorallo.com> From: Keagan McClelland Date: Thu, 18 Feb 2021 08:04:53 -0700 Message-ID: To: Matt Corallo , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000001fd22805bb9da901" X-Mailman-Approved-At: Thu, 18 Feb 2021 15:48:01 +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: Thu, 18 Feb 2021 15:05:16 -0000 --0000000000001fd22805bb9da901 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, I think it's important for us to consider what is actually being considered for activation here. The designation of "soft fork" is accurate but I don't think it adequately 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 mean 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 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 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 influence 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" transactions 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 ve= ry 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* changes that the rest of the network wants. I can certainly live with an L=3DF attempt as a way to punt on the discussion, 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 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 treat all soft forks as equal. Keagan On Thu, Feb 18, 2021 at 7:43 AM Matt Corallo via bitcoin-dev < 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 that risk > has been minimized for Taproot. > > > > You know (better than I do in fact) that Bitcoin (and layers built on > top of it) greatly benefit from upgrades such as > > Taproot. To say we shouldn't do Taproot or any future soft forks becaus= e > there is a small but real risk of chain splits > > I think is shortsighted. Indeed I think even if we collectively decided > 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 fo= r > 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 happene= d > 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 scenario > 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 hav= e > material *transaction processing* userbases, > > and I=E2=80=99m not sure to what extent that=E2=80=99s true with Kn= ots) 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-dev < > bitcoin-dev@lists.linuxfoundation.org > >> > wrote: > >> > >> =EF=BB=BF > >> Right, that is one option. Personally I would prefer a Bitcoin Cor= e > release sets LOT=3Dfalse (based on what I have > >> heard from Bitcoin Core contributors) and a community effort > releases a version with LOT=3Dtrue. I don't think users > >> should be forced to choose something they may have no context on > before they are allowed to use Bitcoin Core. > >> > >> 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 yet 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 othe= r > change, can be contentious like any other > >> change, and we must resolve it like any other change. Otherwis= e > 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=3Dtru= e > or LOT=3Dfalse, would be to have a release that > >> requires a `taprootlot=3D1` or `taprootlot=3D0` and refuses to > start if the parameter is not set. > >> > >> This assures everyone that neither choice is being forced 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 useful 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 everyone else > delays their upgrade (with the very good reason of > >> not getting involved in politics) and a year later those > 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 is that > miners activate Taproot before LOT is even > >> relevant. I think it is prudent to prepare for the unlikely bu= t > possible outcome that miners fail to activate > >> and hence have this 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/018= 380.html > >> < > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018= 380.html>) > of individuals or a > >> proportion of the community changing LOT to true. In that sens= e > 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 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 that LOT=3Dt= rue > is antagonistic to miners. I actually think it > >> offers them clarity on what will happen over a year time perio= d > and removes the need for coordinated or > >> uncoordinated community UASF efforts on top of LOT=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 other change. Otherwis= e > we risk arriving at the darkest timeline. > >> > > > >> > > I don't know what you are recommending here to avoid "this > darkest timeline". Open discussions have > >> occurred and are continuing and in my mailing list post that > you responded to **I recommended we propose > >> LOT=3Dfalse be set in protocol implementations such as Bitcoin > Core**. I do think this apocalyptic language > >> isn't particularly helpful. In an open consensus system > discussion is healthy, we should prepare for bad or > >> worst case scenarios in advance and doing so is not > antagonistic 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 people 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 recommendation to > set LOT=3Dfalse in protocol implementations in my > >> email :) > >> > > > >> > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces < > arielluaces@gmail.com > >> > wrote: > >> > > > >> > > > Something what strikes me about the conversation is the > emotion surrounding the letters UASF. > >> > > > It appears as if people discuss UASF as if it's a massiv= e > tidal wave of support that is inevitable, like > >> we saw during segwit activation. But the actual definition is > "any activation that is not a MASF". > >> > > > A UASF can consist of a single node, ten nodes, a > thousand, half of all nodes, all business' nodes, or > >> even all the non mining nodes. On another dimension it can hav= e > zero mining support, 51% support, 49% support, > >> or any support right up against a miner activation threshold. > >> > > > Hell a UASF doesn't even need code or even a single node > running as long as it exists as a possibility > >> in people's minds. > >> > > > The only thing a UASF doesn't have is miner support abov= e > an agreed activation threshold (some number > >> above %51). > >> > > > I say this because it strikes me when people say 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 everyone else > delays their upgrade (with the very good reason of > >> not getting involved in politics) and a year later those > 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 that ends u= p > activating the feature now that the stubborn > >> option has ran its course. > >> > > > The result: a wasted year of waiting and a minority of > people who didn't want to be lenient with miners > >> by default. The chains could be called BitcoinLenient and > BitcoinStubborn. > >> > > > How is that strictly safer or more coordinated? > >> > > > I may be in the minority, or maybe a silent majority, 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 implemen= t > 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 like any > other change, can be contentious like any other > >> change, and we must resolve it like any other change. Otherwis= e > 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 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. > >> > > > > > >> > > > > The meeting was announced here: > >> > > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018= 380.html > >> < > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018= 380.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 form I > >> > > > > could. David Harding responded with an additional > argument for > >> > > > > LOT=3Dfalse (F7) here: > >> > > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018= 415.html > >> < > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018= 415.html > > > >> > > > > > >> > > > > These meetings are very challenging given they are ope= n > 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 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 < > 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 < > https://www.youtube.com/watch?v=3Dvpl5q1ovMLM>) > >> > > > > > >> > > > > A summary of the meeting was provided by Luke Dashjr o= n > Mastodon here: > >> > > > > > 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. However, from > >> > > > > my perspective there was clearly more strong oppositio= n > (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=3Dfa= lse. > Andrew Chow > >> > > > > tried to summarize views from the meeting in this > analysis: > >> > > > > > https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c > >> < > 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 > 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 < > http://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=3Dfalse. > >> > > > > 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 or > >> > > > > various specific individuals change their minds. > >> > > > > > >> > > > > 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 an= d > more > >> > > > > technical. That is planned for Tuesday February 23rd a= t > 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 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 bitcoin-dev@lists.linuxfoundation.org> > >> > > > https://lists.linuxfoundation.org/mailman/listinfo/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 bitcoin-dev@lists.linuxfoundation.org> > >> https://lists.linuxfoundation.org/mailman/listinfo/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-dev > --0000000000001fd22805bb9da901 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I think it's importan= t for us to consider what is actually being considered for activation here.=

The designation of "soft fork" is accurate bu= t I don't think it adequately conveys how non-intrusive a change like t= his is. All that taproot does (unless I'm completely missing something)= is imbue a previously undefined script version with actual semantics. In o= rder for a chain reorg to take place it would mean 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 an= yone is using that script version, we absolutely should not be using it, bu= t that doesn't mean that we can't switch to a script version that n= o one is actually using.

If no one is even attempt= ing to use the script version, then the change has no effect on whether a c= hain split occurs because there is simply no block that contains a transact= ion that only some of the network will accept.

Fur= thermore, I don't know how Bitcoin can stand the test of time if we all= ow developers who rely on "undefined behavior" (which the taproot= script version presently is) to exert tremendous influence over what code = does or does not get run. This isn't a soft fork that makes some partic= ular UTXO's unspendable. It isn't one that bans miners from collect= ing fees. It is a change that means that certain "always accept" = transactions actually have real conditions you have to meet. I can't im= agine a less intrusive change.

On the other hand, = choosing to let L=3DF be a somewhat final call sets a very real precedent t= hat 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 ar= e 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 netw= ork get to block non-intrusive=C2=A0changes that the rest of the net= work wants.

I can certainly live with an L=3DF att= empt as a way to punt on the discussion, maybe the activation happens and t= his will all be fine. But if it doesn't, I hardly think that users of B= itcoin are just going to be like "well, guess that's it for Taproo= t". I have no idea what ensues at that point, but probably another com= munity 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 po= int 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 <bitcoin-d= ev@lists.linuxfoundation.org> wrote:
We've had several softforks in Bitcoin whic= h, through the course of their activation, had a several-block reorg. That =
should be indication enough that we need to very carefully consider activat= ion to ensure we reduce the risk of that as
much as absolutely possible. Again, while I think Taproot is a huge improve= ment 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 that ris= k has been minimized for Taproot.
>
> You know (better than I do in fact) that Bitcoin (and layers built on = top of it) greatly benefit from upgrades such as
> Taproot. To say we shouldn't do Taproot or any future soft forks b= ecause there is a small but real risk of chain splits
> I think is shortsighted. Indeed I think even if we collectively=C2=A0d= ecided not to do any future soft fork upgrades ever
> again on this mailing list that wouldn't stop soft fork attempts f= rom other people in future.
>
> I don't think there is anything else we can do to minimize that ri= sk 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 happen= ed in 2017).
>
> The likely scenario for the Taproot soft fork is LOT turns out to be e= ntirely irrelevant and miners activate Taproot
> before it becomes relevant. And even the unlikely worst case scenario = would only cause short term disruption and
> wouldn't kill Bitcoin long term.
>
> On Thu, Feb 18, 2021 at 2:01 PM Matt Corallo <lf-lists@mattcorallo.com <m= ailto:lf-list= s@mattcorallo.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0If the eventual outcome is that different implement= ations (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 a= nd not
>=C2=A0 =C2=A0 =C2=A0activate Taproot. Seriously.
>
>=C2=A0 =C2=A0 =C2=A0Bitcoin is a consensus system. The absolute worst o= utcome 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 via = bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org
>>=C2=A0 =C2=A0 =C2=A0<mailto:bitcoin-dev@lists.linuxfoundation.or= g>> wrote:
>>
>>=C2=A0 =C2=A0 =C2=A0=EF=BB=BF
>>=C2=A0 =C2=A0 =C2=A0Right, that is one option. Personally I would p= refer a Bitcoin Core release sets LOT=3Dfalse (based on what I have
>>=C2=A0 =C2=A0 =C2=A0heard from Bitcoin Core contributors) and a com= munity effort releases a version with LOT=3Dtrue. I don't think users >>=C2=A0 =C2=A0 =C2=A0should be forced to choose something they may h= ave no context on before they are allowed to use Bitcoin Core.
>>
>>=C2=A0 =C2=A0 =C2=A0My current understanding is that roasbeef is pl= anning to set LOT=3Dfalse on btcd (an alternative protocol
>>=C2=A0 =C2=A0 =C2=A0implementation to Bitcoin Core) and Luke Dashjr= hasn't yet decided on Bitcoin Knots.
>>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <<= a href=3D"mailto:ZmnSCPxj@protonmail.com" target=3D"_blank">ZmnSCPxj@proton= mail.com <mailto:ZmnSCPxj@protonmail.com>> 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 mechanis= m 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 li= ke any other change. Otherwise we risk arriving at the darkest timeline.&qu= ot;
>>=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, witho= ut mandating either LOT=3Dtrue or LOT=3Dfalse, would be to have a release t= hat
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0requires a `taprootlot=3D1` or `t= aprootlot=3D0` and refuses to start if the parameter is not set.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This assures everyone that neithe= r choice is being forced on users, and instead what is being forced on user= s,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is for users to make that choice = 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 <bitcoin-dev@lists.linuxfoundation.o= rg
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:bitcoin-dev@lists.linu= xfoundation.org>> wrote:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > Thanks for your respons= e Ariel. 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 quo= te these ephemeral "people" you speak of. I don't know if you= 're responding
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to conversation on the IRC channe= l 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 subm= itted into
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0code. But in fact this isn't = true and some voices in this discussion need to be more humble about what u= sers
>>=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= made this assumption. Of course users aren't forced to run any particu= lar software
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0version, quite the opposite. Defa= ults 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 realiz= e that it is a very possible outcome that if LOT=3Dtrue is released there m= ay be only a
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0handful of people that begin runn= ing 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 politics)= and a year later those handful of people just become stuck at the moment o= f
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST_SIGNAL, unable to mine new b= locks?
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> >
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > It is a possible outcom= e but 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 prudent t= o prepare for the unlikely but possible outcome that miners fail to activat= e
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and hence have this discussion no= w 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 pos= sibility (T2 in
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://lists.linuxfoundation.org/pipermail/bitcoin-= dev/2021-February/018380.html
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://lists.linuxfoundation.org/pipermail/bitc= oin-dev/2021-February/018380.html>) of individuals or a
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proportion of the community chang= ing 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 than L= OT=3Dtrue.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> >
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > The result: a wast= ed year of waiting and a minority of people who didn't want to be lenie= nt 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 miner= s fail
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to activate. I'm not convince= d 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 will = 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 effo= rts 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 mech= anism 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 li= ke 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 y= ou are recommending here to avoid "this darkest timeline". Open d= iscussions have
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0occurred and are continuing and i= n 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 im= plementations such as Bitcoin Core**. I do think this apocalyptic language<= br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0isn't particularly helpful. I= n 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 advance a= nd doing so is not antagonistic or destructive. Mining pools=C2=A0have pled= ged
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0support for Taproot but we don= 9;t build secure systems based on pledges of support, we build them to mini= mize
>>=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
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0taprootactivation.com <= http://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 cast= 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 yo= u agree with my recommendation to set LOT=3Dfalse in protocol implementatio= ns 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 <arielluaces@gmail.com
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:arielluaces@gmail.com>> wrot= e:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> >
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > Something what str= ikes me about the conversation is the emotion surrounding the letters UASF.=
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > It appears as if p= eople discuss UASF as if it's a massive tidal wave of support that is i= nevitable, like
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0we saw during segwit activation. = 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&#= 39; 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% suppor= t,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0or any support right up against a= miner activation threshold.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > Hell a UASF doesn&= #39;t even need code or even a single node running as long as it exists as = a possibility
>>=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 U= ASF doesn't have is miner support above an agreed activation threshold = (some number
>>=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 strikes 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 then= 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 somet= imes 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 subm= itted into
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0code. But in fact this isn't = true and some voices in this discussion need to be more humble about what u= sers
>>=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 realiz= e that it is a very possible outcome that if LOT=3Dtrue is released there m= ay be only a
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0handful of people that begin runn= ing 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 politics)= and a year later those handful of people just become stuck at the moment o= f
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST_SIGNAL, unable to mine new b= locks? 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=3Dfalse= could be started that ends up activating the feature now that the stubborn=
>>=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 wast= ed year of waiting and a minority of people who didn't want to be lenie= nt with miners
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by default. The chains could be c= alled BitcoinLenient and BitcoinStubborn.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > How is that strict= ly safer or more coordinated?
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > I may be in the mi= nority, or maybe a silent majority, or maybe a majority that just hasn'= t considered
>>=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 fut= ure then I prefer to just not activate anything at all. I'm fine for ca= lling
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bitcoin ossified, accepting that = 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 split = 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 will
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0become envious enough to put asid= e our differences on how to behave towards miners and finally activate Tapr= oot.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > An activation mech= anism 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 li= ke 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-Luac= es
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > On Feb 17, 2021, a= t 7:05 AM, Michael Folkson via bitcoin-dev <bitcoin-dev@lists.linuxfound= ation.org
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:bitcoin-dev@lists.linu= xfoundation.org>> wrote:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > >
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Yesterday (Fe= bruary 16th) we held a second meeting on Taproot
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > activation on= IRC which again was open to all. Despite what appeared
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > to be majorit= y support for LOT=3Dfalse over LOT=3Dtrue in the first
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > meeting I (an= d others) thought the arguments had not been explored in
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > depth and tha= t we should have a follow up meeting almost entirely
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > focused on wh= ether 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 w= as announced here:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > https://lists.linuxfoundation.or= g/pipermail/bitcoin-dev/2021-February/018380.html
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://lists.linuxfoundation.org/pipermail/bitc= oin-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> > > > In that maili= ng list post I outlined the arguments for LOT=3Dtrue (T1 to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > T6) and argum= ents for LOT=3Dfalse (F1 to F6) in their strongest form I
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > could. David = Harding responded 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.linuxfoundation.or= g/pipermail/bitcoin-dev/2021-February/018415.html
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://lists.linuxfoundation.org/pipermail/bitc= oin-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> > > > These meeting= s are very 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 view= s in
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > advance. I tr= ied to give time for both the LOT=3Dtrue arguments and the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > LOT=3Dfalse a= rguments to be discussed as I knew there was support for
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > both. We only= tried evaluating which had more support and which had
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > more strong o= pposition 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 conversat= ion log is here:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > http://gnusha.org/taproot-activation/2021-02-16.log <http://gnusha.org/taproot-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 s= o inclined 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.com/watch?v=3Dvpl5q1ovMLM <https://www.youtube.com/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 meeting was provided by Luke Dashjr on Mastodon here:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > https://bitcoinhackers.org/@lukedashjr/10574291877923456= 6
>>=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> > > > Today's #= Bitcoin #Taproot 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 he= ight range: 693504-745920
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > MASF threshol= d: 1815/2016 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> > > > representativ= e 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 det= ails remain 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 inev= itable that 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 with 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 perspectiv= e there was clearly more strong opposition (what would
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > usually be de= emed a NACK in Bitcoin Core review terminology) from
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > Bitcoin Core = contributors, Lightning developers and other community
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > members again= st LOT=3Dtrue than there was for LOT=3Dfalse. Andrew Chow
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > tried to summ= arize views from the meeting in this analysis:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > https://gist.github.com/achow101/3e179501290abb7= 049de198d46894c7c
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://gist.github.com/achow101/3e179501290abb7049de198d46894c= 7c>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > >
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > I am also awa= re of other current and previous Bitcoin Core
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > contributors = and Lightning developers who didn=E2=80=99t attend the meeting in
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > person who ar= e 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 reason but if you go through the conversation logs of
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > not only the = meeting but the weeks of discussion prior to this meeting
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > you will see = their views evaluated on the ##taproot-activation
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > channel. In a= ddition, on taprootactivation.com <http://taprootactivation.co= m> some mining pools
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > expressed a p= reference for lot=3Dfalse though I don=E2=80=99t know how strong
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > that preferen= ce 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 but it is my current assessment that if we are to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > attempt to fi= nalize Taproot 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 d= elay appears to me counterproductive in our collective
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > aim to get th= e 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 oth= ers are free to disagree with that assessment and
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > continue disc= ussions but personally I will be attempting to avoid
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > those discuss= ions unless prominent new information comes to light or
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > various speci= fic individuals 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 planning a code review of the Bitcoin Core PR #19573
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > which was ini= tially delayed because of this LOT discussion. As I=E2=80=99ve
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > said previous= ly that will 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. Th= at is planned for Tuesday February 23rd at 19:00 UTC on
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > the IRC chann= el ##taproot-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 channel prior and post the meeting) for engaging
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > productively = and in good 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@gmail.com = <mailto:mi= chaelfolkson@gmail.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 1D4= 0 EAF4 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 lis= t
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > bitcoin-dev@lists.linux= foundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>=
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-de= v
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev&= gt;
>>
>>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0--
>>=C2=A0 =C2=A0 =C2=A0Michael Folkson
>>=C2=A0 =C2=A0 =C2=A0Email: michaelfolkson@gmail.com <mailto:michaelfolkson@gmail.com>
>>=C2=A0 =C2=A0 =C2=A0Keybase: michaelfolkson
>>=C2=A0 =C2=A0 =C2=A0PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 21= 4C FEE3
>>=C2=A0 =C2=A0 =C2=A0_______________________________________________=
>>=C2=A0 =C2=A0 =C2=A0bitcoin-dev mailing list
>>=C2=A0 =C2=A0 =C2=A0bitcoin-dev@lists.linuxfoundation.org <m= ailto:bitcoin-dev@lists.linuxfoundation.org>
>>=C2=A0 =C2=A0 =C2=A0https://li= sts.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>=C2=A0 =C2=A0 =C2=A0<https:= //lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
>
> --
> Michael Folkson
> Email: m= ichaelfolkson@gmail.com <mailto: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/mail= man/listinfo/bitcoin-dev
--0000000000001fd22805bb9da901--