diff options
author | Matt Corallo <lf-lists@mattcorallo.com> | 2021-02-18 09:42:58 -0500 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2021-02-18 14:43:05 +0000 |
commit | 45ec077716ac5d1dcae05f97d7b1bc3e2ac265af (patch) | |
tree | c91a476b015a91f26318acb1fedff12d5749c7c5 | |
parent | efbffbb0587535eb1ce078c53e96e7b00cb5dc84 (diff) | |
download | pi-bitcoindev-45ec077716ac5d1dcae05f97d7b1bc3e2ac265af.tar.gz pi-bitcoindev-45ec077716ac5d1dcae05f97d7b1bc3e2ac265af.zip |
Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
-rw-r--r-- | 3c/1b2d70353c7c2f74068a8819e735e3213cb0a3 | 354 |
1 files changed, 354 insertions, 0 deletions
diff --git a/3c/1b2d70353c7c2f74068a8819e735e3213cb0a3 b/3c/1b2d70353c7c2f74068a8819e735e3213cb0a3 new file mode 100644 index 000000000..941628df2 --- /dev/null +++ b/3c/1b2d70353c7c2f74068a8819e735e3213cb0a3 @@ -0,0 +1,354 @@ +Return-Path: <lf-lists@mattcorallo.com> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 34250C000D + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 18 Feb 2021 14:43:05 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp3.osuosl.org (Postfix) with ESMTP id 154D5605CE + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 18 Feb 2021 14:43:05 +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 lA2O6VhJRBKQ + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 18 Feb 2021 14:43:03 +0000 (UTC) +Received: by smtp3.osuosl.org (Postfix, from userid 1001) + id 3703660613; Thu, 18 Feb 2021 14:43:03 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 +Received: from mail.as397444.net (mail.as397444.net [69.59.18.99]) + by smtp3.osuosl.org (Postfix) with UTF8SMTPS id 39456605CE + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 18 Feb 2021 14:43:00 +0000 (UTC) +Received: by mail.as397444.net (Postfix) with UTF8SMTPSA id 4A18D4A3AFE; + Thu, 18 Feb 2021 14:42:58 +0000 (UTC) +X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/ +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com; + s=1613658063; t=1613659378; + bh=UQZXRtiGFgyN4gdfFzoWo007ROa7nbdJqr+k1AGAIiE=; + h=Date:Subject:To:Cc:References:From:In-Reply-To:From; + b=TRZxavcUpXMxWP9pnwyvBDgj5PSnKmj7VX1SfCdMST1oi9ymdH6NShS1yXUjmED3J + 2hNbua8eeXmiUxOtBoU5YqCRc3f/EfKUhQmDStHENSfZSXgj9BRGFqg3DbdwAf8iPM + tfZWKQP2t1RvVcJm1zOoUBhvf2cEe7SQWB+Cgct8GnaqfV7PsLZ0k6nvxAaaz/In2e + yNjkPeuLUsga8z6q3gk/oUK3/tDgpiWAej75nHI1BY9YBFzD0B2HhG1UlCEIiQOE2w + GYVjHFcsUTUWnc4QBk8SfTBJxKSeJBAM1UcVtFDiaxfN54m7nJRcSNoc0OSDGyFP97 + k/nrNu/75D3AQ== +Message-ID: <7b8543c3-8ff2-3a6a-b2d4-f4a6cf150d78@mattcorallo.com> +Date: Thu, 18 Feb 2021 09:42:58 -0500 +MIME-Version: 1.0 +Content-Language: en-US +To: Michael Folkson <michaelfolkson@gmail.com> +References: <CAFvNmHSHu0gqVgWxOCJnSTf5mxpWsMF9FrMQ+_X+uyR3P4QCsg@mail.gmail.com> + <8591CF93-E574-4C23-90D5-FA410637DECD@mattcorallo.com> + <CAFvNmHSwRGEy-kE8OA4mcDJ+fJjO7J1ckThWY=wqv4yge-MA1Q@mail.gmail.com> +From: Matt Corallo <lf-lists@mattcorallo.com> +In-Reply-To: <CAFvNmHSwRGEy-kE8OA4mcDJ+fJjO7J1ckThWY=wqv4yge-MA1Q@mail.gmail.com> +Content-Type: text/plain; charset=UTF-8; format=flowed +Content-Transfer-Encoding: 7bit +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Thu, 18 Feb 2021 14:43:05 -0000 + +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 because 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 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 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 <lf-lists@mattcorallo.com <mailto:lf-lists@mattcorallo.com>> wrote: +> +> If the eventual outcome is that different implementations (that have material *transaction processing* userbases, +> and I’m not sure to what extent that’s true 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-dev <bitcoin-dev@lists.linuxfoundation.org +>> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: +>> +>> +>> Right, that is one option. Personally I would prefer a Bitcoin Core release sets LOT=false (based on what I have +>> heard from Bitcoin Core contributors) and a community effort releases a version with LOT=true. 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=false 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 <ZmnSCPxj@protonmail.com <mailto:ZmnSCPxj@protonmail.com>> 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=true or LOT=false, would be to have a release that +>> requires a `taprootlot=1` or `taprootlot=0` 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 <bitcoin-dev@lists.linuxfoundation.org +>> <mailto:bitcoin-dev@lists.linuxfoundation.org>> 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=true 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 but 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/018380.html +>> <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=false in a software release +>> appears to be no more safe than LOT=true. +>> > > +>> > > > 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=true is antagonistic to miners. I actually think it +>> offers them clarity on what will happen over a year time period and removes the need for coordinated or +>> uncoordinated community UASF efforts on top of LOT=false. +>> > > +>> > > > 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. +>> > > +>> > > 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=false 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 <http://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=false in protocol implementations in my +>> email :) +>> > > +>> > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <arielluaces@gmail.com +>> <mailto: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 massive 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 have 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 above an agreed activation threshold (some number +>> above %51). +>> > > > I say this because it strikes me when people say that they are for LOT=true 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=true 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=false could be started that ends up 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 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 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. +>> > > > Cheers +>> > > > Ariel Lorenzo-Luaces +>> > > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org +>> <mailto:bitcoin-dev@lists.linuxfoundation.org>> 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=false over LOT=true 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/018380.html +>> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html> +>> > > > > +>> > > > > In that mailing list post I outlined the arguments for LOT=true (T1 to +>> > > > > T6) and arguments for LOT=false (F1 to F6) in their strongest form I +>> > > > > could. David Harding responded with an additional argument for +>> > > > > LOT=false (F7) here: +>> > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html +>> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html> +>> > > > > +>> > > > > These meetings are very challenging given they are open to all, you +>> > > > > don’t know who will attend and you don’t know most people’s views in +>> > > > > advance. I tried to give time for both the LOT=true arguments and the +>> > > > > LOT=false 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 “Bitcoin” for setting up the livestream: +>> > > > > https://www.youtube.com/watch?v=vpl5q1ovMLM <https://www.youtube.com/watch?v=vpl5q1ovMLM>) +>> > > > > +>> > > > > A summary of the meeting was provided by Luke Dashjr on Mastodon here: +>> > > > > https://bitcoinhackers.org/@lukedashjr/105742918779234566 +>> <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’t +>> > > > > overwhelming consensus for either LOT=true or LOT=false. However, from +>> > > > > my perspective there was clearly more strong opposition (what would +>> > > > > usually be deemed a NACK in Bitcoin Core review terminology) from +>> > > > > Bitcoin Core contributors, Lightning developers and other community +>> > > > > members against LOT=true than there was for LOT=false. 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’t attend the meeting in +>> > > > > person who are opposed to LOT=true. I don’t 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=false though I don’t 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=false. +>> > > > > 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’ve +>> > > > > said previously that will be loosely following the format of the +>> > > > > Bitcoin Core PR review club and will be lower level and more +>> > > > > technical. That is planned for Tuesday February 23rd at 19:00 UTC on +>> > > > > the IRC channel ##taproot-activation. +>> > > > > +>> > > > > 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 <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 <mailto:bitcoin-dev@lists.linuxfoundation.org> +>> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> +>> +>> +>> +>> +>> -- +>> Michael Folkson +>> Email: michaelfolkson@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 <mailto:bitcoin-dev@lists.linuxfoundation.org> +>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> +> +> +> +> -- +> Michael Folkson +> Email: michaelfolkson@gmail.com <mailto:michaelfolkson@gmail.com> +> Keybase: michaelfolkson +> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 + |