From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4D57BC000D for ; Thu, 18 Feb 2021 15:01:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 2D962605CE for ; Thu, 18 Feb 2021 15:01:17 +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 ZRsW_QRBBBGY for ; Thu, 18 Feb 2021 15:01:14 +0000 (UTC) Received: by smtp3.osuosl.org (Postfix, from userid 1001) id 99B99605F9; Thu, 18 Feb 2021 15:01:14 +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 4E2226064A for ; Thu, 18 Feb 2021 15:01:11 +0000 (UTC) Received: by mail.as397444.net (Postfix) with UTF8SMTPSA id 6E0374A3BF8; Thu, 18 Feb 2021 15:01:09 +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=1613659263; t=1613660469; bh=p4H5iYwb9scCRM7AJrX3NscyZjF7VzgJjspo+L0uSfo=; h=Date:Subject:To:References:From:In-Reply-To:From; b=YkRJGqGfRxvodyAO2AdURawftIP6vZBt5w/v74d65Fw4SOOnIDbHKpIHal7sCqADY TSt4IsYOc/9xNiV3wJLH76Z02Wqgw1NCZ4Xs8gRAP6VQXlezcvwK5iNT+EW0QQH7Dm +yBF6J2cXSlPo3S/UQZ9utxhXCiCiRG5vJKg2Ug3spwYCmzoM6AjP5CEdLeFYuoQT8 5nBYBWqtOQJg2BZ2i2fKJgeTFO8RbyQlDwhlkYxBbQxWNkfXQAJZnPZ4mbXGKUr7Kt hGP46F/XRNqbOuX/t24HiPvKLmpU8lTHpjRhXHogBUgJFKV8gOmo4nSSd0WRuMgnuz I56qQldijklyg== Message-ID: <924c5cab-17c5-49c5-779d-10fc6a4067bd@bluematt.me> Date: Thu, 18 Feb 2021 10:01:09 -0500 MIME-Version: 1.0 Content-Language: en-US To: Bitcoin Protocol Discussion , Michael Folkson References: <8591CF93-E574-4C23-90D5-FA410637DECD@mattcorallo.com> <7b8543c3-8ff2-3a6a-b2d4-f4a6cf150d78@mattcorallo.com> <4a8a1978-f265-e81c-0286-b927b964fc98@mattcorallo.com> From: Matt Corallo In-Reply-To: <4a8a1978-f265-e81c-0286-b927b964fc98@mattcorallo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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:01:17 -0000 To ensure we're on the same page, here - I'm not advocating we give up on Taproot. Indeed, without having dug deep into the issue, my overall impression is that Knots has a tiny transaction-processing userbase and it likely isn't worth giving deep thought to whether it forks itself off from the network or not. My point is that, if it were the case that various implementations of Bitcoin's consensus that have material userbases were to release either a configurable consensus mechanism (without incredible care being given to it, not just a "we can't decide, whatever" argument) or a different consensus, we'd be much, much better off not having Taproot at all. Matt On 2/18/21 09:53, Matt Corallo via bitcoin-dev wrote: > You say "short term PR", I say "risking millions of user dollars". > > On 2/18/21 09:51, Michael Folkson wrote: >>  > 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. >> >> We are at the point where an upgrade that confers significant long term benefits for the whole ecosystem is not as >> important as bad short term PR? That is a depressing outlook if that is what you believe. >> >> Even in that worst case scenario exchanges should not lose money if they are competent and are able to manage that risk. >> >> On Thu, Feb 18, 2021 at 2:42 PM Matt Corallo > 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 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 >>     >> 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 >     >>      >>     >> 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 >>     >> 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 >     >>      >>         >> 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 >>     >>      >>         >     >) 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 >     > (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 >     >>      >>         >> 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 >>     >>      >>         >> 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 >>     >>      >>         >     > >>      >>         > > > > >>      >>         > > > > 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 >>     >>      >>         >     > >>      >>         > > > > >>      >>         > > > > 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 >>     >     > >>      >>         > > > > >>      >>         > > > > (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 >>     >) >>      >>         > > > > >>      >>         > > > > A summary of the meeting was provided by Luke Dashjr on 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’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 >>     >>      >>         >     > >>      >>         > > > > >>      >>         > > > > 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 >>     > 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 >     > >>      >>         > > 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 >>     >>      >>         >     > >>      >> >>      >> >>      >> >>      >> >>      >>     -- >>      >>     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 >>     >>      >>     >     > >>      > >>      > >>      > >>      > -- >>      > Michael Folkson >>      > Email: michaelfolkson@gmail.com >     > >>      > Keybase: michaelfolkson >>      > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 >> >> >> >> -- >> 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