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> 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 <zmnsc...@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> 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 >> > > <ariellua...@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> 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: michaelfolk...@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: michaelfolk...@gmail.com > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
