* [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) @ 2021-02-17 12:51 Michael Folkson 2021-02-18 5:43 ` Ariel Lorenzo-Luaces 2021-02-21 16:21 ` Erik Aronesty 0 siblings, 2 replies; 42+ messages in thread From: Michael Folkson @ 2021-02-17 12:51 UTC (permalink / raw) To: bitcoin-dev 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-17 12:51 [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) Michael Folkson @ 2021-02-18 5:43 ` Ariel Lorenzo-Luaces 2021-02-18 11:01 ` Michael Folkson 2021-02-21 16:21 ` Erik Aronesty 1 sibling, 1 reply; 42+ messages in thread From: Ariel Lorenzo-Luaces @ 2021-02-18 5:43 UTC (permalink / raw) To: Michael Folkson, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 8040 bytes --] 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, 7:05 AM, 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: 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 [-- Attachment #2: Type: text/html, Size: 9033 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-18 5:43 ` Ariel Lorenzo-Luaces @ 2021-02-18 11:01 ` Michael Folkson 2021-02-18 11:11 ` Samson Mow 0 siblings, 1 reply; 42+ messages in thread From: Michael Folkson @ 2021-02-18 11:01 UTC (permalink / raw) To: Ariel Lorenzo-Luaces; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 11712 bytes --] 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 <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> 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 [-- Attachment #2: Type: text/html, Size: 14120 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-18 11:01 ` Michael Folkson @ 2021-02-18 11:11 ` Samson Mow 2021-02-18 11:52 ` ZmnSCPxj 0 siblings, 1 reply; 42+ messages in thread From: Samson Mow @ 2021-02-18 11:11 UTC (permalink / raw) To: Michael Folkson, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 12581 bytes --] "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. 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 < > 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> 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 > [-- Attachment #2: Type: text/html, Size: 15284 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-18 11:11 ` Samson Mow @ 2021-02-18 11:52 ` ZmnSCPxj 2021-02-18 12:20 ` Michael Folkson 2021-02-18 13:59 ` Matt Corallo 0 siblings, 2 replies; 42+ messages in thread From: ZmnSCPxj @ 2021-02-18 11:52 UTC (permalink / raw) To: Samson Mow, Bitcoin Protocol Discussion; +Cc: Michael Folkson 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 <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> 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-18 11:52 ` ZmnSCPxj @ 2021-02-18 12:20 ` Michael Folkson 2021-02-18 14:01 ` Matt Corallo 2021-02-18 13:59 ` Matt Corallo 1 sibling, 1 reply; 42+ messages in thread From: Michael Folkson @ 2021-02-18 12:20 UTC (permalink / raw) To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 14534 bytes --] 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> 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 < > 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> 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 [-- Attachment #2: Type: text/html, Size: 18501 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-18 12:20 ` Michael Folkson @ 2021-02-18 14:01 ` Matt Corallo 2021-02-18 14:26 ` Michael Folkson 0 siblings, 1 reply; 42+ messages in thread From: Matt Corallo @ 2021-02-18 14:01 UTC (permalink / raw) To: Michael Folkson, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 15100 bytes --] 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 <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> 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 <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> 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 [-- Attachment #2: Type: text/html, Size: 19459 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-18 14:01 ` Matt Corallo @ 2021-02-18 14:26 ` Michael Folkson 2021-02-18 14:42 ` Matt Corallo 0 siblings, 1 reply; 42+ messages in thread From: Michael Folkson @ 2021-02-18 14:26 UTC (permalink / raw) To: Matt Corallo; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 17102 bytes --] 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> 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> 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> 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 < >> 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> 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 [-- Attachment #2: Type: text/html, Size: 22184 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-18 14:26 ` Michael Folkson @ 2021-02-18 14:42 ` Matt Corallo 2021-02-18 14:51 ` Michael Folkson 2021-02-18 15:04 ` Keagan McClelland 0 siblings, 2 replies; 42+ messages in thread From: Matt Corallo @ 2021-02-18 14:42 UTC (permalink / raw) To: Michael Folkson; +Cc: Bitcoin Protocol Discussion 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-18 14:42 ` Matt Corallo @ 2021-02-18 14:51 ` Michael Folkson 2021-02-18 14:53 ` Matt Corallo 2021-02-18 15:04 ` Keagan McClelland 1 sibling, 1 reply; 42+ messages in thread From: Michael Folkson @ 2021-02-18 14:51 UTC (permalink / raw) To: Matt Corallo; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 22240 bytes --] > 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 <lf-lists@mattcorallo•com> 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 <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 > -- Michael Folkson Email: michaelfolkson@gmail•com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 [-- Attachment #2: Type: text/html, Size: 31620 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-18 14:51 ` Michael Folkson @ 2021-02-18 14:53 ` Matt Corallo 2021-02-18 15:01 ` Matt Corallo 0 siblings, 1 reply; 42+ messages in thread From: Matt Corallo @ 2021-02-18 14:53 UTC (permalink / raw) To: Michael Folkson; +Cc: Bitcoin Protocol Discussion 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 <lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo•com>> 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 <lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo•com> > <mailto: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> > >> <mailto: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> > <mailto: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> > >> <mailto: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> > >> <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> <http://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> > >> <mailto: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> > >> <mailto: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> > >> <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> > >> <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> <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> > <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> > >> <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> > >> <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> > <http://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> <mailto: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> > <mailto: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> > >> <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> <mailto: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> > <mailto: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> > >> <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> <mailto:michaelfolkson@gmail•com > <mailto:michaelfolkson@gmail•com>> > > Keybase: michaelfolkson > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > > > > -- > Michael Folkson > Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com> > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-18 14:53 ` Matt Corallo @ 2021-02-18 15:01 ` Matt Corallo 0 siblings, 0 replies; 42+ messages in thread From: Matt Corallo @ 2021-02-18 15:01 UTC (permalink / raw) To: Bitcoin Protocol Discussion, Michael Folkson 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 <lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo•com>> 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 <lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo•com> >> <mailto: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> >> >> <mailto: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> >> <mailto: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> >> >> <mailto: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> >> >> <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> <http://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> >> >> <mailto: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> >> >> <mailto: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> >> >> <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> >> >> <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> <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> >> <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> >> >> <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> >> >> <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> >> <http://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> <mailto: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> >> <mailto: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> >> >> <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> <mailto: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> >> <mailto: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> >> >> <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> <mailto:michaelfolkson@gmail•com >> <mailto:michaelfolkson@gmail•com>> >> > Keybase: michaelfolkson >> > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 >> >> >> >> -- >> 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 > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-18 14:42 ` Matt Corallo 2021-02-18 14:51 ` Michael Folkson @ 2021-02-18 15:04 ` Keagan McClelland 2021-02-18 15:18 ` Matt Corallo 1 sibling, 1 reply; 42+ messages in thread From: Keagan McClelland @ 2021-02-18 15:04 UTC (permalink / raw) To: Matt Corallo, Bitcoin Protocol Discussion; +Cc: Michael Folkson [-- Attachment #1: Type: text/plain, Size: 24387 bytes --] 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=F be a somewhat final call sets a very real precedent that 10% of what I estimate to be 1% of bitcoin users can effectively block any change from here on forward. At that point we are saying that miners are in control of network consensus in ways they have not been up 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=F 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 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 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 33600 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-18 15:04 ` Keagan McClelland @ 2021-02-18 15:18 ` Matt Corallo 2021-02-19 2:20 ` Ariel Luaces 2021-02-19 11:30 ` ZmnSCPxj 0 siblings, 2 replies; 42+ messages in thread From: Matt Corallo @ 2021-02-18 15:18 UTC (permalink / raw) To: Keagan McClelland, Bitcoin Protocol Discussion; +Cc: Michael Folkson This is absolutely the case, however note that the activation method itself is consensus code which executes as a part of a fork, and one which deserves as much scrutiny as anything else. While taproot is a model of how a soft-fork should be designed, this doesn't imply anything about the consensus code which represents the activation thereof. Hence all the debate around activation - ultimately its also defining a fork, and given the politics around it, one which almost certainly carries significantly more risk than Taproot. Note that I don't believe anyone is advocating for "try to activate, and if it fails, move on". Various people have various views on how conservative and timelines for what to do at that point, but I believe most in this discussion are OK with flag-day-based activation (given some level of care) if it becomes clear Taproot is supported by a vast majority of Bitcoin users and is only not activating due to lagging miner upgrades. Matt On 2/18/21 10:04, Keagan McClelland wrote: > Hi all, > > I think it's important for us to consider what is actually being 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=F be a somewhat final call sets a very real precedent that 10% of what I estimate > to be 1% of bitcoin users can effectively block any change from here on forward. At that point we are saying that miners > are in control of network consensus in ways they have not been up 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=F 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 > <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: > > We've had several softforks in Bitcoin which, through the course of their activation, had a several-block reorg. That > should be indication enough that we need to very carefully 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> > <mailto: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> > >> <mailto: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> > <mailto: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> > >> <mailto: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> > >> <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> <http://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> > >> <mailto: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> > >> <mailto: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> > >> <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> > >> <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> <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> > <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> > >> <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> > >> <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> > <http://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> <mailto: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> > <mailto: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> > >> <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> <mailto: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> > <mailto: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> > >> <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> <mailto: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> > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-18 15:18 ` Matt Corallo @ 2021-02-19 2:20 ` Ariel Luaces 2021-02-19 11:30 ` ZmnSCPxj 1 sibling, 0 replies; 42+ messages in thread From: Ariel Luaces @ 2021-02-19 2:20 UTC (permalink / raw) To: Matt Corallo, Bitcoin Protocol Discussion Hi Michael I think you're right, sorry for getting a little apocalyptic at the end there lol. > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org > > 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. I'm mostly referring to the two IRC discussions. I normally try to avoid singling people out that's why I didn't refer to anyone in perticular. Here I'll list a couple of quotes from these ephemeral people, while reading them keep in mind what would happen if a majority users and miners decide to just avoid the latest version. - 11:06: "LOT=true does not split the chain. It strictly reduces the liklihood of that." - 11:06: "LOT=false has chainsplit risks, not LOT=true" - 08:59 "I guess it would be helpful to hear miners' answers to that question." Response: 09:01 "not sure why; miners don't decide anything in this regard it's more of `Taproot is activating. Please accelerate it if you can`" Reading the logs again I see some voices that do consider the right that users and miners have to run whatever version they want Response: 09:03 "I ask because you said something that's equivalent to `miners don't get to decide which version of core their run`." - T1, T2, T3, and T6 have language that assumes mass support for a UASF and then proceed to make conclusions on what is safer and easier to coordinate A voice in the discussion expressed the same point I'm making: 10:53 "I disagree with T1: i don't think there is any logical consequence in hardcoding LOT=true ensuring Taproot activation and even less ensuring no political shenanigans. We obviously need economic majority to run it and that would open way more political arguments that they bluntly take part in an UASF without any bad behaviour from miners." - 11:14 "we know people will run LOT=true regardless of the default, so it will be safer if LOT=true is made the default" - 11:18 "With LOT=true, attempted UASFs are not necessary" - 11:18 "why give them the ability to act maliciously in the first place?" Response:11:18"LOT=false does not; people choosing to run software that will enforce taproot under some reasonable circumstances provides the information. LOT=false just reduces the risk of unexpected results from resulting in danger." Response: 11:18 "LOT=false strictly increases the risks though.." Response: 11:18 "please stop saying that, there are tradeoffs both ways." - 11:11 "LOT=false gives miners the ability to decide [in response to someone saying that LOT=false gives everyone else in the community the ability to decide]" This quote is a bit more nuanced because the implication is that LOT=true doesn't give the ability to decide. But in reality they have the ability to decide to not upgrade. Users can also not upgrade to be in solidarity with miners to protect them from unfair distrust and aggression. All the arguments above for LOT=true are rooted in the assumption that everyone must upgrade to the latest version because of course they will...? But that's not a given. There are examples of people being aware that miners and users can run any version they want. I misjudged the number of people who know that LOT=true doesn't guarantee anything. - 11:17 "The LOT=True crowd seems to have an underlying assumption that a UASF will occur instead of something more orderly like Modern Softfork Activation suggested, why? I don't think chances of that happening are very high unless things play out similarly to Segwit but it doesn't look like that." - 11:17 "UASFs can be made much more difficult with a counter-UASF.... UASFs like this one and segwit relied on intolerant-minority effects" (I'm assuming counter-UASF means not upgrading as opposed to upgrading to a new client that rejects the activation flag) > 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. If you look at https://taprootactivation.com/ no miners seem to be expressing any support at all for lot=true. To pre-empt the counter argument, I know that miners don't decide, I'm just using that poll as a proxy to estimate whether they would be antagonized by the promotion of LOT=true. I'm not a miner and I think the "fork will happen regardless of the consequences" attitude is antagonistic towards everyone in general, not just miners. The LOT=true activation mechanism may be tolerated today because Taproot has wide support. But in order to prevent future antagonistic behavior around future network changes (possibly more controversial ones) we should continue the norm of including miners in the activation process, as the friends they are. This idea that LOT=true provides clarity is another is another example of an argument rooted in the assumption that users will upgrade because of course they will. No activation mechanism provides ANY guarantees and neither does LOT=true so it's infair to frame it as if it does. This is your argument Michael, please don't take anything I say personally I'm just arguing the points. > 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. If a LOT=true client is released I think the likely outcome is that people won't upgrade at all and I would say that miners failing to activate will become more likely than you think, strictly due to a loud group promoting LOT=true. It's true that some will stubbornly run LOT=true regardless. But if they have not been provoked to do so then I would hope the community promotes unity and shuns needlessly conflictive attitudes to avoid the, admittedly inevitable, network split from gathering momentum (a counter-UASF). I hope individuals opt for unity and become intolerant (counter-UASF) of intolerance (unprovoked-UASF). > TL;DR It sounds like you agree with my recommendation to set LOT=false in protocol implementations in my email :) Yes I do agree with the recommendation of LOT=false. Thank you for organizing the discussion. On Thu, Feb 18, 2021 at 3:12 AM Samson Mow <samson.mow@gmail•com> wrote: > > "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? By "we" I meant everyone involved in the discussion of the activation mechanism. The discussion is slowly growing and eventually has to reach social media. > > Release both and let the network decide. If two clients are released with matching activation parameters except for opposing LOT then LOT=true kind of spoils the LOT=false choice (only if LOT=true manages to gather support) because running LOT=false is being complicit/tolerant of the aggressive attitude of LOT=true. In the case of both being released I would opt for running neither and I hope most users and miners do too. Again, with the caveat that only if there is visible significant support for LOT=true. And yes, the "significant" is a subjective word and, based on risk appetite, is different for everyone. That's part of the issue. A funny metaphor is that if someone is visibly pissing in a pool I'm not going to swim on the other side of the pool, I just won't swim at all and go do whatever I was doing before. Cheers Ariel Lorenzo-Luaces On Thu, Feb 18, 2021 at 7:18 AM Matt Corallo via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > This is absolutely the case, however note that the activation method itself is consensus code which executes as a part > of a fork, and one which deserves as much scrutiny as anything else. While taproot is a model of how a soft-fork should > be designed, this doesn't imply anything about the consensus code which represents the activation thereof. > > Hence all the debate around activation - ultimately its also defining a fork, and given the politics around it, one > which almost certainly carries significantly more risk than Taproot. > > Note that I don't believe anyone is advocating for "try to activate, and if it fails, move on". Various people have > various views on how conservative and timelines for what to do at that point, but I believe most in this discussion are > OK with flag-day-based activation (given some level of care) if it becomes clear Taproot is supported by a vast majority > of Bitcoin users and is only not activating due to lagging miner upgrades. > > Matt > > On 2/18/21 10:04, Keagan McClelland wrote: > > Hi all, > > > > I think it's important for us to consider what is actually being 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=F be a somewhat final call sets a very real precedent that 10% of what I estimate > > to be 1% of bitcoin users can effectively block any change from here on forward. At that point we are saying that miners > > are in control of network consensus in ways they have not been up 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=F 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 > > <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: > > > > We've had several softforks in Bitcoin which, through the course of their activation, had a several-block reorg. That > > should be indication enough that we need to very carefully 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> > > <mailto: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> > > >> <mailto: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> > > <mailto: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> > > >> <mailto: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> > > >> <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> <http://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> > > >> <mailto: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> > > >> <mailto: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> > > >> <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> > > >> <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> <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> > > <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> > > >> <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> > > >> <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> > > <http://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> <mailto: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> > > <mailto: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> > > >> <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> <mailto: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> > > <mailto: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> > > >> <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> <mailto: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> > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-18 15:18 ` Matt Corallo 2021-02-19 2:20 ` Ariel Luaces @ 2021-02-19 11:30 ` ZmnSCPxj 2021-02-19 12:05 ` Adam Back 1 sibling, 1 reply; 42+ messages in thread From: ZmnSCPxj @ 2021-02-19 11:30 UTC (permalink / raw) To: Matt Corallo, Bitcoin Protocol Discussion; +Cc: Michael Folkson Good morning list, > This is absolutely the case, however note that the activation method itself is consensus code which executes as a part > of a fork, and one which deserves as much scrutiny as anything else. While taproot is a model of how a soft-fork should > be designed, this doesn't imply anything about the consensus code which represents the activation thereof. > > Hence all the debate around activation - ultimately its also defining a fork, and given the politics around it, one > which almost certainly carries significantly more risk than Taproot. > > Note that I don't believe anyone is advocating for "try to activate, and if it fails, move on". Various people have > various views on how conservative and timelines for what to do at that point, but I believe most in this discussion are > OK with flag-day-based activation (given some level of care) if it becomes clear Taproot is supported by a vast majority > of Bitcoin users and is only not activating due to lagging miner upgrades. Okay, I am backing off this proposal to force the LOT=false/true decision on users, it was not particularly serious anyway (and was more a reaction to the request of Samson Mow to just release both versions, which to my mind is no different from such a thing). Nonetheless, as a thought experiment: the main issue is that some number of people run LOT=true when miners do not activate Taproot early for some reason and we decide to leave LOT=false for this particular bit until it times out. The issue is that those people will get forked off the network at the end of this particular deployment attempt. I suspect those people will still exist whether or not Bitcoin Core supports any kind of LOT=true mode. ("Never again" for some people) How do we convince them to go run LOT=false instead of getting themselves forked off? Or do we simply let them? (and how is that different from asking each user to decide on LOT=false/true right now?) ("reasonable default"?) (fundamentally speaking you still have to educate the users on the ramifications of accepting the default and changing it.) Another thought experiment: From the point of view of a user who strongly supports LOT=true, would dev consensus around releasing LOT=false be considered as "developers forcing their views on users"? Why or why not? Regards, ZmnSCPxj > Matt > > On 2/18/21 10:04, Keagan McClelland wrote: > > > Hi all, > > I think it's important for us to consider what is actually being 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=F be a somewhat final call sets a very real precedent that 10% of what I estimate > > to be 1% of bitcoin users can effectively block any change from here on forward. At that point we are saying that miners > > are in control of network consensus in ways they have not been up 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=F 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 > > mailto:bitcoin-dev@lists•linuxfoundation.org> wrote: > > > > We've had several softforks in Bitcoin which, through the course of their activation, had a several-block reorg. That > > should be indication enough that we need to very carefully 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> > > <mailto: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> > > >> <mailto: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> > > <mailto: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> > > >> <mailto: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> > > >> <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> <http://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> > > >> <mailto: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> > > >> <mailto: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> > > >> <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> > > >> <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> <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> > > <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> > > >> <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> > > >> <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> > > <http://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> <mailto: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> > > <mailto: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> > > >> <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> <mailto: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> > > <mailto: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> > > >> <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> <mailto: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> > > > > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-19 11:30 ` ZmnSCPxj @ 2021-02-19 12:05 ` Adam Back 2021-02-19 14:13 ` Matt Corallo 0 siblings, 1 reply; 42+ messages in thread From: Adam Back @ 2021-02-19 12:05 UTC (permalink / raw) To: ZmnSCPxj, Bitcoin Protocol Discussion; +Cc: Michael Folkson Personally I don't really have much of a view and think either LOT=true or false is better in the context, they both seem safe given the current context, where basically everyone is saying "are we there yet", including pools (88.7% going out of their way to say YES https://taprootactivation.com). Not that pools are deciding of anything, being service providers to miners, who can and will switch pool fast, and miners in-turn being service providers to the market and as the various forks showed will follow the market. I think it's a very good idea for safety, if there is a tested and reviewed code with an option to force LOT=true, even if the bitcoin-core implementation ends up defaulting to LOT=false. Part of the danger is rushed versions of things like BIP 91 to avoid a chain split where miners left brinkmanship just a bit too late, to avert BIP 148 forking, and BIP 91 was used to expedite activation to avoid that. The rushed proposal, code, review, ship cycle on that was dangerously fast - less time and eyes for review was the danger. > would dev consensus around releasing LOT=false be considered as "developers forcing their views on users"? given there are clearly people of both views, or for now don't care but might later, it would minimally be friendly and useful if bitcoin-core has a LOT=true option - and that IMO goes some way to avoid the assumptive control via defaults. Otherwise it could be read as saying "developers on average disapprove, but if you, the market disagree, go figure it out for yourself" which is not a good message for being defensive and avoiding mis-interpretation of code repositories or shipped defaults as "control". Adam On Fri, 19 Feb 2021 at 11:30, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > Good morning list, > > > This is absolutely the case, however note that the activation method itself is consensus code which executes as a part > > of a fork, and one which deserves as much scrutiny as anything else. While taproot is a model of how a soft-fork should > > be designed, this doesn't imply anything about the consensus code which represents the activation thereof. > > > > Hence all the debate around activation - ultimately its also defining a fork, and given the politics around it, one > > which almost certainly carries significantly more risk than Taproot. > > > > Note that I don't believe anyone is advocating for "try to activate, and if it fails, move on". Various people have > > various views on how conservative and timelines for what to do at that point, but I believe most in this discussion are > > OK with flag-day-based activation (given some level of care) if it becomes clear Taproot is supported by a vast majority > > of Bitcoin users and is only not activating due to lagging miner upgrades. > > > Okay, I am backing off this proposal to force the LOT=false/true decision on users, it was not particularly serious anyway (and was more a reaction to the request of Samson Mow to just release both versions, which to my mind is no different from such a thing). > > > Nonetheless, as a thought experiment: the main issue is that some number of people run LOT=true when miners do not activate Taproot early for some reason and we decide to leave LOT=false for this particular bit until it times out. > The issue is that those people will get forked off the network at the end of this particular deployment attempt. > > I suspect those people will still exist whether or not Bitcoin Core supports any kind of LOT=true mode. > ("Never again" for some people) > > How do we convince them to go run LOT=false instead of getting themselves forked off? > Or do we simply let them? > > (and how is that different from asking each user to decide on LOT=false/true right now?) > ("reasonable default"?) > (fundamentally speaking you still have to educate the users on the ramifications of accepting the default and changing it.) > > > Another thought experiment: From the point of view of a user who strongly supports LOT=true, would dev consensus around releasing LOT=false be considered as "developers forcing their views on users"? > Why or why not? > > > Regards, > ZmnSCPxj > > > Matt > > > > On 2/18/21 10:04, Keagan McClelland wrote: > > > > > Hi all, > > > I think it's important for us to consider what is actually being 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=F be a somewhat final call sets a very real precedent that 10% of what I estimate > > > to be 1% of bitcoin users can effectively block any change from here on forward. At that point we are saying that miners > > > are in control of network consensus in ways they have not been up 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=F 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 > > > mailto:bitcoin-dev@lists•linuxfoundation.org> wrote: > > > > > > We've had several softforks in Bitcoin which, through the course of their activation, had a several-block reorg. That > > > should be indication enough that we need to very carefully 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> > > > <mailto: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> > > > >> <mailto: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> > > > <mailto: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> > > > >> <mailto: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> > > > >> <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> <http://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> > > > >> <mailto: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> > > > >> <mailto: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> > > > >> <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> > > > >> <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> <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> > > > <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> > > > >> <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> > > > >> <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> > > > <http://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> <mailto: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> > > > <mailto: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> > > > >> <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> <mailto: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> > > > <mailto: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> > > > >> <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> <mailto: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> > > > > > > > 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-19 12:05 ` Adam Back @ 2021-02-19 14:13 ` Matt Corallo 2021-02-19 17:48 ` Matt Corallo 0 siblings, 1 reply; 42+ messages in thread From: Matt Corallo @ 2021-02-19 14:13 UTC (permalink / raw) To: Adam Back; +Cc: Michael Folkson, Bitcoin Protocol Discussion (Also in response to ZMN...) Bitcoin Core has a long-standing policy of not shipping options which shoot yourself in the foot. I’d be very disappointed if that changed now. People are of course more than welcome to run such software themselves, but I anticipate the loud minority on Twitter and here aren’t processing enough transactions or throwing enough financial weight behind their decision for them to do anything but just switch back if they find themselves on a chain with no blocks. There’s nothing we can (or should) do to prevent people from threatening to (and possibly) forking themselves off of bitcoin, but that doesn’t mean we should encourage it either. The work Bitcoin Core maintainers and developers do is to recommend courses of action which they believe have reasonable levels of consensus and are technically sound. Luckily, there’s strong historical precedent for people deciding to run other software around forks, so misinterpretation is not very common (just like there’s strong historical precedent for miners not unilaterally deciding forks in the case of Segwit). Matt > On Feb 19, 2021, at 07:08, Adam Back <adam@cypherspace•org> wrote: >> would dev consensus around releasing LOT=false be considered as "developers forcing their views on users"? > > given there are clearly people of both views, or for now don't care > but might later, it would minimally be friendly and useful if > bitcoin-core has a LOT=true option - and that IMO goes some way to > avoid the assumptive control via defaults. > Otherwise it could be read as saying "developers on average > disapprove, but if you, the market disagree, go figure it out for > yourself" which is not a good message for being defensive and avoiding > mis-interpretation of code repositories or shipped defaults as > "control". ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-19 14:13 ` Matt Corallo @ 2021-02-19 17:48 ` Matt Corallo 2021-02-20 2:55 ` ZmnSCPxj 2021-02-22 5:16 ` Anthony Towns 0 siblings, 2 replies; 42+ messages in thread From: Matt Corallo @ 2021-02-19 17:48 UTC (permalink / raw) To: Bitcoin Protocol Discussion, Adam Back, ZmnSCPxj; +Cc: Michael Folkson It was pointed out to me that this discussion is largely moot as the software complexity for Bitcoin Core to ship an option like this is likely not practical/what people would wish to see. Bitcoin Core does not have infrastructure to handle switching consensus rules with the same datadir - after running with uasf=true for some time, valid blocks will be marked as invalid, and additional development would need to occur to enable switching back to uasf=false. This is complex, critical code to get right, and the review and testing cycles needed seem to be not worth it. Instead, the only practical way to ship such an option would be to treat it as a separate chain (the same way regtest, testnet, and signet are treated), including its own separate datadir and the like. Matt On 2/19/21 09:13, Matt Corallo via bitcoin-dev wrote: > (Also in response to ZMN...) > > Bitcoin Core has a long-standing policy of not shipping options which shoot yourself in the foot. I’d be very disappointed if that changed now. People are of course more than welcome to run such software themselves, but I anticipate the loud minority on Twitter and here aren’t processing enough transactions or throwing enough financial weight behind their decision for them to do anything but just switch back if they find themselves on a chain with no blocks. > > There’s nothing we can (or should) do to prevent people from threatening to (and possibly) forking themselves off of bitcoin, but that doesn’t mean we should encourage it either. The work Bitcoin Core maintainers and developers do is to recommend courses of action which they believe have reasonable levels of consensus and are technically sound. Luckily, there’s strong historical precedent for people deciding to run other software around forks, so misinterpretation is not very common (just like there’s strong historical precedent for miners not unilaterally deciding forks in the case of Segwit). > > Matt > >> On Feb 19, 2021, at 07:08, Adam Back <adam@cypherspace•org> wrote: >>> would dev consensus around releasing LOT=false be considered as "developers forcing their views on users"? >> >> given there are clearly people of both views, or for now don't care >> but might later, it would minimally be friendly and useful if >> bitcoin-core has a LOT=true option - and that IMO goes some way to >> avoid the assumptive control via defaults. > >> Otherwise it could be read as saying "developers on average >> disapprove, but if you, the market disagree, go figure it out for >> yourself" which is not a good message for being defensive and avoiding >> mis-interpretation of code repositories or shipped defaults as >> "control". > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-19 17:48 ` Matt Corallo @ 2021-02-20 2:55 ` ZmnSCPxj 2021-02-20 17:20 ` Ariel Lorenzo-Luaces 2021-02-22 5:16 ` Anthony Towns 1 sibling, 1 reply; 42+ messages in thread From: ZmnSCPxj @ 2021-02-20 2:55 UTC (permalink / raw) To: Matt Corallo; +Cc: Michael Folkson, Bitcoin Protocol Discussion Good morning list, > It was pointed out to me that this discussion is largely moot as the software complexity for Bitcoin Core to ship an > option like this is likely not practical/what people would wish to see. > > Bitcoin Core does not have infrastructure to handle switching consensus rules with the same datadir - after running with > uasf=true for some time, valid blocks will be marked as invalid, and additional development would need to occur to > enable switching back to uasf=false. This is complex, critical code to get right, and the review and testing cycles > needed seem to be not worth it. Without implying anything else, this can be worked around by a user maintaining two `datadir`s and running two clients. This would have an "external" client running an LOT=X (where X is whatever the user prefers) and an "internal" client that is at most 0.21.0, which will not impose any LOT rules. The internal client then uses `connect=` directive to connect locally to the external client and connects only to that client, using it as a firewall. The external client can be run pruned in order to reduce diskspace resource usage (the internal client can remain unpruned if that is needed by the user, e.g. for LN implementation sthat need to look up arbitrary short-channel-ids). Bandwidth usage should be same since the internal client only connects to the external client and the OS should optimize that case. CPU usage is doubled, though. (the general idea came from gmax, just to be clear, though the below use is from me) Then the user can select LOT=C or LOT=!C (where C is whatever Bitcoin Core ultimately ships with) on the external client based on the user preferences. If Taproot is not MASF-activated and LOT=!U is what dominates later (where U is whatever the user decided on), the user can decide to just destroy the external node and connect the internal node directly to the network (optionally upgrading the internal node to LOT=!U) as a way to "change their mind in view of the economy". The internal node will then follow the dominant chain. Regards, ZmnSCPxj > > Instead, the only practical way to ship such an option would be to treat it as a separate chain (the same way regtest, > testnet, and signet are treated), including its own separate datadir and the like. > > Matt > > On 2/19/21 09:13, Matt Corallo via bitcoin-dev wrote: > > > (Also in response to ZMN...) > > Bitcoin Core has a long-standing policy of not shipping options which shoot yourself in the foot. I’d be very disappointed if that changed now. People are of course more than welcome to run such software themselves, but I anticipate the loud minority on Twitter and here aren’t processing enough transactions or throwing enough financial weight behind their decision for them to do anything but just switch back if they find themselves on a chain with no blocks. > > There’s nothing we can (or should) do to prevent people from threatening to (and possibly) forking themselves off of bitcoin, but that doesn’t mean we should encourage it either. The work Bitcoin Core maintainers and developers do is to recommend courses of action which they believe have reasonable levels of consensus and are technically sound. Luckily, there’s strong historical precedent for people deciding to run other software around forks, so misinterpretation is not very common (just like there’s strong historical precedent for miners not unilaterally deciding forks in the case of Segwit). > > Matt > > > > > On Feb 19, 2021, at 07:08, Adam Back adam@cypherspace•org wrote: > > > > > > > would dev consensus around releasing LOT=false be considered as "developers forcing their views on users"? > > > > > > given there are clearly people of both views, or for now don't care > > > but might later, it would minimally be friendly and useful if > > > bitcoin-core has a LOT=true option - and that IMO goes some way to > > > avoid the assumptive control via defaults. > > > > > Otherwise it could be read as saying "developers on average > > > disapprove, but if you, the market disagree, go figure it out for > > > yourself" which is not a good message for being defensive and avoiding > > > mis-interpretation of code repositories or shipped defaults as > > > "control". > > > > bitcoin-dev mailing list > > bitcoin-dev@lists•linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-20 2:55 ` ZmnSCPxj @ 2021-02-20 17:20 ` Ariel Lorenzo-Luaces 2021-02-21 14:30 ` Matt Corallo 0 siblings, 1 reply; 42+ messages in thread From: Ariel Lorenzo-Luaces @ 2021-02-20 17:20 UTC (permalink / raw) To: ZmnSCPxj, Bitcoin Protocol Discussion, ZmnSCPxj [-- Attachment #1: Type: text/plain, Size: 5112 bytes --] What would be the tradeoffs of a BIP8(false, ∞) option? That would remove some of the concerns of having to coordinate a UASF with an approaching deadline. Cheers Ariel Lorenzo-Luaces On Feb 19, 2021, 6:55 PM, at 6:55 PM, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >Good morning list, > >> It was pointed out to me that this discussion is largely moot as the >software complexity for Bitcoin Core to ship an >> option like this is likely not practical/what people would wish to >see. >> >> Bitcoin Core does not have infrastructure to handle switching >consensus rules with the same datadir - after running with >> uasf=true for some time, valid blocks will be marked as invalid, and >additional development would need to occur to >> enable switching back to uasf=false. This is complex, critical code >to get right, and the review and testing cycles >> needed seem to be not worth it. > >Without implying anything else, this can be worked around by a user >maintaining two `datadir`s and running two clients. >This would have an "external" client running an LOT=X (where X is >whatever the user prefers) and an "internal" client that is at most >0.21.0, which will not impose any LOT rules. >The internal client then uses `connect=` directive to connect locally >to the external client and connects only to that client, using it as a >firewall. >The external client can be run pruned in order to reduce diskspace >resource usage (the internal client can remain unpruned if that is >needed by the user, e.g. for LN implementation sthat need to look up >arbitrary short-channel-ids). >Bandwidth usage should be same since the internal client only connects >to the external client and the OS should optimize that case. >CPU usage is doubled, though. > >(the general idea came from gmax, just to be clear, though the below >use is from me) > >Then the user can select LOT=C or LOT=!C (where C is whatever Bitcoin >Core ultimately ships with) on the external client based on the user >preferences. > >If Taproot is not MASF-activated and LOT=!U is what dominates later >(where U is whatever the user decided on), the user can decide to just >destroy the external node and connect the internal node directly to the >network (optionally upgrading the internal node to LOT=!U) as a way to >"change their mind in view of the economy". >The internal node will then follow the dominant chain. > > >Regards, >ZmnSCPxj > >> >> Instead, the only practical way to ship such an option would be to >treat it as a separate chain (the same way regtest, >> testnet, and signet are treated), including its own separate datadir >and the like. >> >> Matt >> >> On 2/19/21 09:13, Matt Corallo via bitcoin-dev wrote: >> >> > (Also in response to ZMN...) >> > Bitcoin Core has a long-standing policy of not shipping options >which shoot yourself in the foot. I’d be very disappointed if that >changed now. People are of course more than welcome to run such >software themselves, but I anticipate the loud minority on Twitter and >here aren’t processing enough transactions or throwing enough financial >weight behind their decision for them to do anything but just switch >back if they find themselves on a chain with no blocks. >> > There’s nothing we can (or should) do to prevent people from >threatening to (and possibly) forking themselves off of bitcoin, but >that doesn’t mean we should encourage it either. The work Bitcoin Core >maintainers and developers do is to recommend courses of action which >they believe have reasonable levels of consensus and are technically >sound. Luckily, there’s strong historical precedent for people deciding >to run other software around forks, so misinterpretation is not very >common (just like there’s strong historical precedent for miners not >unilaterally deciding forks in the case of Segwit). >> > Matt >> > >> > > On Feb 19, 2021, at 07:08, Adam Back adam@cypherspace•org wrote: >> > > >> > > > would dev consensus around releasing LOT=false be considered as >"developers forcing their views on users"? >> > > >> > > given there are clearly people of both views, or for now don't >care >> > > but might later, it would minimally be friendly and useful if >> > > bitcoin-core has a LOT=true option - and that IMO goes some way >to >> > > avoid the assumptive control via defaults. >> > >> > > Otherwise it could be read as saying "developers on average >> > > disapprove, but if you, the market disagree, go figure it out for >> > > yourself" which is not a good message for being defensive and >avoiding >> > > mis-interpretation of code repositories or shipped defaults as >> > > "control". >> > >> > 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 [-- Attachment #2: Type: text/html, Size: 6259 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-20 17:20 ` Ariel Lorenzo-Luaces @ 2021-02-21 14:30 ` Matt Corallo 0 siblings, 0 replies; 42+ messages in thread From: Matt Corallo @ 2021-02-21 14:30 UTC (permalink / raw) To: Ariel Lorenzo-Luaces, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 6116 bytes --] I don’t think “some vocal users are going to threaten to fork themselves off” is good justification for technical decisions. It’s important to communicate and for everyone to agree/understand that a failed BIP 8/9 activation, in the scenario people are worried about, is not the end of the story for Taproot activation. If it is clear that Taproot has broad consensus but some miners failed to upgrade in time (as it presumably would be), a flag day activation seems merited and I’m not sure anyone has argued against this. That said, forced-signaling via a UASF/BIP8(true)-style fork carries material additional risk that a classic flag-day activation does not, so let’s not optimize for something like that. Matt > On Feb 21, 2021, at 08:26, Ariel Lorenzo-Luaces via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > > What would be the tradeoffs of a BIP8(false, ∞) option? That would remove some of the concerns of having to coordinate a UASF with an approaching deadline. > > Cheers > Ariel Lorenzo-Luaces >> On Feb 19, 2021, at 6:55 PM, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >> Good morning list, >> >>> It was pointed out to me that this discussion is largely moot as the software complexity for Bitcoin Core to ship an >>> option like this is likely not practical/what people would wish to see. >>> >>> Bitcoin Core does not have infrastructure to handle switching consensus rules with the same datadir - after running with >>> uasf=true for some time, valid blocks will be marked as invalid, and additional development would need to occur to >>> enable switching back to uasf=false. This is complex, critical code to get right, and the review and testing cycles >>> needed seem to be not worth it. >> >> Without implying anything else, this can be worked around by a user maintaining two `datadir`s and running two clients. >> This would have an "external" client running an LOT=X (where X is whatever the user prefers) and an "internal" client that is at most 0.21.0, which will not impose any LOT rules. >> The internal client then uses `connect=` directive to connect locally to the external client and connects only to that client, using it as a firewall. >> The external client can be run pruned in order to reduce diskspace resource usage (the internal client can remain unpruned if that is needed by the user, e.g. for LN implementation sthat need to look up arbitrary short-channel-ids). >> Bandwidth usage should be same since the internal client only connects to the external client and the OS should optimize that case. >> CPU usage is doubled, though. >> >> (the general idea came from gmax, just to be clear, though the below use is from me) >> >> Then the user can select LOT=C or LOT=!C (where C is whatever Bitcoin Core ultimately ships with) on the external client based on the user preferences. >> >> If Taproot is not MASF-activated and LOT=!U is what dominates later (where U is whatever the user decided on), the user can decide to just destroy the external node and connect the internal node directly to the network (optionally upgrading the internal node to LOT=!U) as a way to "change their mind in view of the economy". >> The internal node will then follow the dominant chain. >> >> >> Regards, >> ZmnSCPxj >> >>> >>> Instead, the only practical way to ship such an option would be to treat it as a separate chain (the same way regtest, >>> testnet, and signet are treated), including its own separate datadir and the like. >>> >>> Matt >>> >>>> On 2/19/21 09:13, Matt Corallo via bitcoin-dev wrote: >>>> >>>> (Also in response to ZMN...) >>>> Bitcoin Core has a long-standing policy of not shipping options which shoot yourself in the foot. I’d be very disappointed if that changed now. People are of course more than welcome to run such software themselves, but I anticipate the loud minority on Twitter and here aren’t processing enough transactions or throwing enough financial weight behind their decision for them to do anything but just switch back if they find themselves on a chain with no blocks. >>>> There’s nothing we can (or should) do to prevent people from threatening to (and possibly) forking themselves off of bitcoin, but that doesn’t mean we should encourage it either. The work Bitcoin Core maintainers and developers do is to recommend courses of action which they believe have reasonable levels of consensus and are technically sound. Luckily, there’s strong historical precedent for people deciding to run other software around forks, so misinterpretation is not very common (just like there’s strong historical precedent for miners not unilaterally deciding forks in the case of Segwit). >>>> Matt >>>> >>>>>> On Feb 19, 2021, at 07:08, Adam Back adam@cypherspace•org wrote: >>>>>> >>>>>> would dev consensus around releasing LOT=false be considered as "developers forcing their views on users"? >>>>> >>>>> given there are clearly people of both views, or for now don't care >>>>> but might later, it would minimally be friendly and useful if >>>>> bitcoin-core has a LOT=true option - and that IMO goes some way to >>>>> avoid the assumptive control via defaults. >>>> >>>>> Otherwise it could be read as saying "developers on average >>>>> disapprove, but if you, the market disagree, go figure it out for >>>>> yourself" which is not a good message for being defensive and avoiding >>>>> mis-interpretation of code repositories or shipped defaults as >>>>> "control". >>>> >>>> bitcoin-dev mailing list >>>> bitcoin-dev@lists•linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 7613 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-19 17:48 ` Matt Corallo 2021-02-20 2:55 ` ZmnSCPxj @ 2021-02-22 5:16 ` Anthony Towns 2021-02-22 6:44 ` Matt Corallo 1 sibling, 1 reply; 42+ messages in thread From: Anthony Towns @ 2021-02-22 5:16 UTC (permalink / raw) To: Matt Corallo, Bitcoin Protocol Discussion; +Cc: Michael Folkson On Fri, Feb 19, 2021 at 12:48:00PM -0500, Matt Corallo via bitcoin-dev wrote: > It was pointed out to me that this discussion is largely moot as the > software complexity for Bitcoin Core to ship an option like this is likely > not practical/what people would wish to see. > Bitcoin Core does not have infrastructure to handle switching consensus > rules with the same datadir - after running with uasf=true for some time, > valid blocks will be marked as invalid, I don't think this is true? With the current proposed bip8 code, lockinontimeout=true will cause headers to be marked as invalid, and won't process the block further. If a node running lockinontimeout=true accepts the header, then it will apply the same consensus rules as a lockinontimeout=false node. I don't think an invalid header will be added to the block index at all, so a node restart should always cleanly allow it to be reconsidered. The test case in https://github.com/bitcoin/bitcoin/pull/19573/commits/bd8517135fc839c3332fea4d9c8373b94c8c9de8 tests that a node that had rejected a chain due to lockinontimeout=true will reorg to that chain after being restarted as a byproduct of the way it tests different cases (the nodes set a new startheight, but retain their lockinontimeout settings). (I think with the current bip8 code, if you switch from lockinontimeout=false to lockinontimeout=true and the tip of the current most work chain is after the timeoutheight and did not lockin, then you will continue following that chain until a taproot-invalid transaction is inclued, rather than immediately reorging to a shorter chain that complies with the lockinontimeout=true rules) Cheers, aj ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-22 5:16 ` Anthony Towns @ 2021-02-22 6:44 ` Matt Corallo 2021-02-22 10:16 ` Anthony Towns 0 siblings, 1 reply; 42+ messages in thread From: Matt Corallo @ 2021-02-22 6:44 UTC (permalink / raw) To: Anthony Towns; +Cc: Michael Folkson, Bitcoin Protocol Discussion Hmm, indeed, I may have missed that you can skip the headers issues by not persisting them, though there are other follow-on effects that are concerning and I think still make my point valid. A node feeding you invalid headers (used to be) cause for a ban - is that information still persisted? More importantly, nodes on both sides of the fork need to find each other. There’s not a great way to do that without forking the address database, DNS seeds and defining a new protocol magic. Matt > On Feb 22, 2021, at 00:16, Anthony Towns <aj@erisian•com.au> wrote: > > On Fri, Feb 19, 2021 at 12:48:00PM -0500, Matt Corallo via bitcoin-dev wrote: >> It was pointed out to me that this discussion is largely moot as the >> software complexity for Bitcoin Core to ship an option like this is likely >> not practical/what people would wish to see. >> Bitcoin Core does not have infrastructure to handle switching consensus >> rules with the same datadir - after running with uasf=true for some time, >> valid blocks will be marked as invalid, > > I don't think this is true? With the current proposed bip8 code, > lockinontimeout=true will cause headers to be marked as invalid, and > won't process the block further. If a node running lockinontimeout=true > accepts the header, then it will apply the same consensus rules as a > lockinontimeout=false node. > > I don't think an invalid header will be added to the block index at all, > so a node restart should always cleanly allow it to be reconsidered. > > The test case in > > https://github.com/bitcoin/bitcoin/pull/19573/commits/bd8517135fc839c3332fea4d9c8373b94c8c9de8 > > tests that a node that had rejected a chain due to lockinontimeout=true > will reorg to that chain after being restarted as a byproduct of the way > it tests different cases (the nodes set a new startheight, but retain > their lockinontimeout settings). > > > (I think with the current bip8 code, if you switch from > lockinontimeout=false to lockinontimeout=true and the tip of the current > most work chain is after the timeoutheight and did not lockin, then you > will continue following that chain until a taproot-invalid transaction > is inclued, rather than immediately reorging to a shorter chain that > complies with the lockinontimeout=true rules) > > Cheers, > aj > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-22 6:44 ` Matt Corallo @ 2021-02-22 10:16 ` Anthony Towns 2021-02-22 14:00 ` Matt Corallo 0 siblings, 1 reply; 42+ messages in thread From: Anthony Towns @ 2021-02-22 10:16 UTC (permalink / raw) To: Matt Corallo; +Cc: Michael Folkson, Bitcoin Protocol Discussion On Mon, Feb 22, 2021 at 01:44:55AM -0500, Matt Corallo wrote: > A node feeding you invalid headers (used to be) cause for a ban [...] Headers that are invalid due to MUST_SIGNAL rules are marked as BLOCK_RECENT_CONSENSUS_CHANGE so don't directly result in a ban. If you're doing headers-first relay, I think that will also prevent hitting the BLOCK_MISSING_PREV case, which would result in a ban. If a lockinontimeout=true node is requesting compact blocks from a lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase, I think that could result in a ban. > More importantly, nodes on both sides of the fork need to find each other. (If there was going to be an ongoing fork there'd be bigger things to worry about...) I think the important specific case of this is something like "if a chain where taproot is impossible to activate is temporarily the most work, miners with lockinontimeout=true need to be well connected so they don't end up competing with each other while they're catching back up". Actually, that same requirement might be more practically for a signet feature we were thinking about -- namely having "optional reorgs", ie every now and then we'd mine 1-6 blocks and then reorg them out; but also flag the soon-to-be-stale blocks in some way so that if you didn't want to have to deal with reorgs you could easily ignore them. Having it be possible for the "I want to see reorgs!" nodes to be able to find each other seems like it might be a similar problem (avoiding having the "don't-want-reorgs" nodes ban the "want-reorgs" nodes too perhaps). Cheers, aj ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-22 10:16 ` Anthony Towns @ 2021-02-22 14:00 ` Matt Corallo 2021-02-22 16:27 ` Anthony Towns 2021-02-22 16:31 ` Jorge Timón 0 siblings, 2 replies; 42+ messages in thread From: Matt Corallo @ 2021-02-22 14:00 UTC (permalink / raw) To: Anthony Towns; +Cc: Michael Folkson, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1298 bytes --] > On Feb 22, 2021, at 05:16, Anthony Towns <aj@erisian•com.au> wrote: > > If a lockinontimeout=true node is requesting compact blocks from a > lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase, > I think that could result in a ban. > >> More importantly, nodes on both sides of the fork need to find each other. > > (If there was going to be an ongoing fork there'd be bigger things to > worry about...) I think it should be clear that a UASF-style command line option to allow consensus rule changes in the node in the short term, immediately before a fork carries some risk of a fork, even if I agree it may not persist over months. We can’t simply ignore that. > I think the important specific case of this is something like "if a chain > where taproot is impossible to activate is temporarily the most work, > miners with lockinontimeout=true need to be well connected so they don't > end up competing with each other while they're catching back up". Between this and your above point, I think we probably agree - there is material technical complexity hiding behind a “change the consensus rules“ option. Given it’s not a critical feature by any means, putting resources into fixing these issues probably isn’t worth it. Matt [-- Attachment #2: Type: text/html, Size: 1968 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-22 14:00 ` Matt Corallo @ 2021-02-22 16:27 ` Anthony Towns 2021-02-22 16:31 ` Jorge Timón 1 sibling, 0 replies; 42+ messages in thread From: Anthony Towns @ 2021-02-22 16:27 UTC (permalink / raw) To: Matt Corallo; +Cc: Michael Folkson, Bitcoin Protocol Discussion On Mon, Feb 22, 2021 at 09:00:29AM -0500, Matt Corallo wrote: > I think it should be clear that a UASF-style command line option to allow > consensus rule changes in the node in the short term, immediately before a fork > carries some risk of a fork, even if I agree it may not persist over months. We > can’t simply ignore that. I don't think a "-set-bip8-lockinontimeout=taproot" option on its own would be very safe -- if we were sure it was safe, because we were sure that everyone would eventually set lockinontimeout=true, then we would set lockinontimeout=true from day one and not need an option. I haven't seen/had any good ideas on how to make the option safe, or at least make it obvious that you shouldn't be setting it if you don't really understand what you're getting yourself into. [0] And that's even if you assume that the code was perfectly capable of handling forks in some theoretically optimal way. So at least for the time being, I don't think a config param / command line option is a good idea for bip8. IMHO, YMMV, IANABDFL etc. > I think the important specific case of this is something like "if a chain > where taproot is impossible to activate is temporarily the most work, > miners with lockinontimeout=true need to be well connected so they don't > end up competing with each other while they're catching back up". > Between this and your above point, I think we probably agree - there is > material technical complexity hiding behind a “change the consensus rules“ > option. Given it’s not a critical feature by any means, putting resources into > fixing these issues probably isn’t worth it. For reference, the "preferentially peer with other UASF nodes" PR for the BIP148 client was https://github.com/UASF/bitcoin/pull/24 List discussion was at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014618.html I think I'll add playing around with that and reorgs on a signet to my todo list to see how it goes in cases other than ones that are (hopefully) vanishingly unlikely to ever happen in practice. Cheers, aj [0] In some sense, this is exactly the opposite sentiment compared to earonesty's comment: https://github.com/bitcoin/bitcoin/pull/10900#issuecomment-317333312 I mean, I guess could solve the unsafe-now-but-maybe-safe-later problem generally with a signature: -authorise-dangerous-options-key=XXXX -lockinontimeout=taproot:YYYY where YYYY is a signature of "dangerous:lockinontimeout=taproot" or similar by the key XXXX, and XXXX defaults to some (multisig?) key controlled by some bitcoin people, who'll only sign that when there's clear evidence that it will be reasonably safe, and maybe to "cert-transparency" or something as well. So that allows having an option become available by publishing a signature, without having to recompile the code. And it could still be overriden by people who know what they're doing if the default key owners are being weird. And maybe the "dangerous" part is enough to prevent people from randomly cut-and-pasting it from a website into their bitcoin.conf. I dunno. No bad ideas when brainstorming... ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-22 14:00 ` Matt Corallo 2021-02-22 16:27 ` Anthony Towns @ 2021-02-22 16:31 ` Jorge Timón 2021-02-22 16:48 ` Jorge Timón 1 sibling, 1 reply; 42+ messages in thread From: Jorge Timón @ 2021-02-22 16:31 UTC (permalink / raw) To: Matt Corallo, Bitcoin Protocol Discussion; +Cc: Michael Folkson Sorry, I haven't read everything. I just want to say what I think is the best option and why. Let's say something like 2 years in which miners can signal activation after which, the MUST signal it for their blocks to be valid (I think this is LOT=true, but I don't remember what LOT stands for). Some may argue than it's easier to move from LOT=false to LOT=true than viceversa (I think I'm getting this right), but either way different clients could interpret things more differently more easily and, you know, that's really bad. If anyone is against the consensus change itself, what they should do is run a client in which the must is turned into a MUST NOT. Whenever miners signal activation, blocks aren't valid so that it doesn't happen. That way both sides can be cleanly separated and both communities (assuming there's a community of users opposing the change) can stick together with their own in the same chain. That is, having only 2 chains in total if there are users opposing the change or only one if not, but never 2 chains for people who want the change or 2 chains for pople who don't want it. Just my two sats, please nobody ask me "why would anyone oppose taproot?" or anything similar. Because I'm trying to generalize here, if we're talking about activation, I think the specifics of the change are kind of irrelevant. Separately: thanks to everyone who worked on taproot. On Mon, Feb 22, 2021 at 3:00 PM Matt Corallo via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > > > On Feb 22, 2021, at 05:16, Anthony Towns <aj@erisian•com.au> wrote: > > If a lockinontimeout=true node is requesting compact blocks from a > lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase, > I think that could result in a ban. > > More importantly, nodes on both sides of the fork need to find each other. > > > (If there was going to be an ongoing fork there'd be bigger things to > worry about...) > > > I think it should be clear that a UASF-style command line option to allow consensus rule changes in the node in the short term, immediately before a fork carries some risk of a fork, even if I agree it may not persist over months. We can’t simply ignore that. > > I think the important specific case of this is something like "if a chain > where taproot is impossible to activate is temporarily the most work, > miners with lockinontimeout=true need to be well connected so they don't > end up competing with each other while they're catching back up". > > > Between this and your above point, I think we probably agree - there is material technical complexity hiding behind a “change the consensus rules“ option. Given it’s not a critical feature by any means, putting resources into fixing these issues probably isn’t worth it. > > Matt > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-22 16:31 ` Jorge Timón @ 2021-02-22 16:48 ` Jorge Timón 2021-02-23 2:10 ` Jeremy 0 siblings, 1 reply; 42+ messages in thread From: Jorge Timón @ 2021-02-22 16:48 UTC (permalink / raw) To: Bitcoin Protocol Discussion Just to clarify, I'm not saying bitcoin core should maintain the "oppose proposal" part of the software. presumably people opposing the change don't want much of the recent software changes anyway. But perhaps it wouldn't be so bad, to oppose other proposals, perhaps. I don't expect anyone to want this, but if people want it I offer myself to code it, I mean, just imagine that a day after publishing a bitcoin core release with activation software for taproot some one, let's say in New York reach an Agreement to "just use the same activation mechanism, but for our 32 mb hardfork, it's about time, now computers are 64 bits anyway". How convenient would it be to just cancel that with 2 lines in bitcoin core? Not that I think it will be necessary, but perhaps we want it just in case. On Mon, Feb 22, 2021 at 5:31 PM Jorge Timón <jtimon@jtimon•cc> wrote: > > Sorry, I haven't read everything. I just want to say what I think is > the best option and why. > Let's say something like 2 years in which miners can signal activation > after which, the MUST signal it for their blocks to be valid (I think > this is LOT=true, but I don't remember what LOT stands for). > Some may argue than it's easier to move from LOT=false to LOT=true > than viceversa (I think I'm getting this right), but either way > different clients could interpret things more differently more easily > and, you know, that's really bad. > If anyone is against the consensus change itself, what they should do > is run a client in which the must is turned into a MUST NOT. Whenever > miners signal activation, blocks aren't valid so that it doesn't > happen. > That way both sides can be cleanly separated and both communities > (assuming there's a community of users opposing the change) can stick > together with their own in the same chain. That is, having only 2 > chains in total if there are users opposing the change or only one if > not, but never 2 chains for people who want the change or 2 chains for > pople who don't want it. > > Just my two sats, please nobody ask me "why would anyone oppose > taproot?" or anything similar. Because I'm trying to generalize here, > if we're talking about activation, I think the specifics of the change > are kind of irrelevant. > > Separately: thanks to everyone who worked on taproot. > > > On Mon, Feb 22, 2021 at 3:00 PM Matt Corallo via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: > > > > > > > > On Feb 22, 2021, at 05:16, Anthony Towns <aj@erisian•com.au> wrote: > > > > If a lockinontimeout=true node is requesting compact blocks from a > > lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase, > > I think that could result in a ban. > > > > More importantly, nodes on both sides of the fork need to find each other. > > > > > > (If there was going to be an ongoing fork there'd be bigger things to > > worry about...) > > > > > > I think it should be clear that a UASF-style command line option to allow consensus rule changes in the node in the short term, immediately before a fork carries some risk of a fork, even if I agree it may not persist over months. We can’t simply ignore that. > > > > I think the important specific case of this is something like "if a chain > > where taproot is impossible to activate is temporarily the most work, > > miners with lockinontimeout=true need to be well connected so they don't > > end up competing with each other while they're catching back up". > > > > > > Between this and your above point, I think we probably agree - there is material technical complexity hiding behind a “change the consensus rules“ option. Given it’s not a critical feature by any means, putting resources into fixing these issues probably isn’t worth it. > > > > Matt > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists•linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-22 16:48 ` Jorge Timón @ 2021-02-23 2:10 ` Jeremy 2021-02-23 19:33 ` Keagan McClelland 2021-02-24 7:18 ` Anthony Towns 0 siblings, 2 replies; 42+ messages in thread From: Jeremy @ 2021-02-23 2:10 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 5577 bytes --] Not responding to anyone in particular, but it strikes me that one can think about the case where a small minority (let's say H = 20%?) of nodes select the opposite of what Core releases (LOT=false, LOT=true). I'm ignoring the case where a critical bug is discovered in Taproot for reasons I could expand on if anyone is interested (I don't think LOT=true/false has much of a diff in that regard). You'll note an asymmetry with LOT=true / false analysis. LOT=true nodes are clearly updated (or lying), LOT=false nodes may be un-upgraded (or however you want to interpret it). *# 80% on LOT=false, 20% LOT=True* - Case 1: Activates ahead of time anyways No issues. - Case 2: Fails to Activate before timeout... 20% *may* fork off with LOT=true. Bitcoin hashrate reduced, chance of multi block reorgs at time of fork relatively high, especially if network does not partition. Implication is that activation % being 90%, then X% fewer than 70% of miners are signaling for Taproot at this time. If X% is small the increased orphan rate caused by the LOT=true miners will cause it to activate anyways. If X% is larger, then there will be a consensus split. *# 80% on LOT=true, 20% LOT=False* - Case 1: Activates ahead of time Anyways No issues. - Case 2: Fails to Activate before timeout... A% + B% + C% = 20% A% (upgraded, signal activate) remain on majority chain with LOT=false, blocks mined universally valid. B% (upgraded, not signaling) succeeds in activating and maintaining consensus, blocks are temporarily lost during the final period, but consensus re-emerges. C% (not upgraded/not signalling) both fail to activate (not upgraded) and blocks are rejected (not signaling) during mandatory signalling. Essentially becomes an SPV miner, should still not select transactions improperly given mempool policy, but may mine a bad tip. (I argue that group B is irrational entirely, as in this case the majority has upgraded, inevitably winning, and is orphaning their blocks so B should effectively be 0% or can be combined with group C as being somehow not upgraded if they are unable to switch once it becomes clear after say the first 100 blocks in the period that LOT > 50%. The only difference in lumping B with C is that group C SPV mines after the fork and B should, in theory, have full validation.). Apologies if my base analysis is off -- happy to take corrections. My overall summary is thus: 1) People care what Core releases because we assume the majority will likely run it. If core were a minority project, we wouldn't really care what core released. 2) People are upset with LOT=true being suggested as release parameters because of the *narrative* that it puts devs in control. 3) LOT=true having a sizeable minority running it presents major issues to majority LOT=false in terms of lost blocks during the final period and in terms of a longer term fork. 4) Majority LOT=true has no long term instability on consensus (majority LOT=true means the final period always activates, any instability is short lived + irrational). 5) On the balance, the safer parameter to release *seems* to be LOT=true. But because devs are sensitive to control narrative, LOT=false is preferred by devs. 6) Almost paradoxically, choosing a *less safe* option for a narrative reason is more of a show of dev control than choosing a more safe option despite appearances. 7) This all comes down to if we think that a reasonable number of important nodes will run LOT=true. 8) This all doesn't matter *that much* because taproot will have many opportunities to activate before the brinksmanship period. As a plan of action, I think that means that either: A) Core should release LOT=true, as a less disruptive option given stated community intentions to do LOT=true B) Core community should vehemently anti-advocate running LOT=true to ensure the % is as small as possible C) Do nothing D) Core community should release LOT=false and vehemently advocate manually changing to LOT=true to ensure the % is supermajority, but leaving it as a user choice. Overall, I worry that plan B has a mild Streissand effect and would result in boosting LOT=true (which could be OK, so long as LOT=true + LOT=false+signal yes becomes the large majority, but would be not fun for anyone if LOT=true + LOT=false+signal yes are a small majority). Plan C most likely ends up with some % doing LOT=true anyways. D feels a little silly, but maybe a good tradeoff. If I had to summarize the emotional dynamic among developers around LOT=true, I think devs wish it didn't exist because it is clear LOT=true *creates* the issues here. LOT=false would be fine if the LOT=true strategy didn't exist at all. But unfortunately the cat is out of the bag and cannot be put back in. To validate the emotions, I think it is fine to be angry about LOT=true and not like it, but we should either accept that it is most likely to create consensus OR we should find a new game theoretic activation strategy with better pro-social equilibriums. Personally, I think with either plan the ultimate risk of forking is low given probability to activate before timeout, so we should just pick something and move on, accepting that we aren't setting a precedent by which all future forks should abide. Given my understanding of the tradeoffs, I believe that the safest choice is LOT=true, but I wouldn't move to hold back a plan of LOT=false (but would probably take mitigative steps on community advocacy if it looks like there is non majority but non negligible LOT=true uptake). Cheers, Jeremy [-- Attachment #2: Type: text/html, Size: 13525 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-23 2:10 ` Jeremy @ 2021-02-23 19:33 ` Keagan McClelland 2021-02-23 23:14 ` Ben Woosley 2021-02-24 22:37 ` Ariel Luaces 2021-02-24 7:18 ` Anthony Towns 1 sibling, 2 replies; 42+ messages in thread From: Keagan McClelland @ 2021-02-23 19:33 UTC (permalink / raw) To: Jeremy, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 10012 bytes --] I wanted to follow up on what Jeremy and others are saying regards finding consensus on LOT. I've seen a few other opinions saying that finding consensus on the LOT value is far more important than what the LOT value actually is. This makes sense because if 100% of economic activity is running the same rule set, there is no divergence, regardless of which value is picked. It is my understanding that those who oppose LOT=true are mostly opposed on the grounds of it *appearing* "unnecessarily coercive" and that this lack of consensus can precipitate a chain split at the "brinksmanship period" as Jeremy refers to it. I don't think that we can say that LOT=true is coercive at all unless there is some opposition to Taproot itself. Opposition on the grounds that it *may* be opposed by others and Core does not want to assert control over the protocol is a conservative view but ultimately contingent upon opposition to Taproot for more fundamental reasons. If no one opposes it, then by definition you have consensus, and in that case I also don't think that the LOT=true (or false) in that regard sets meaningful precedent, as I would expect precedents to only be meaningful if they were established during a contentious scenario. As it stands we have precedents for both MASF's and UASF's to execute soft forks in Bitcoin. Of course it seems intractable to ascertain the views of ~100% of the Bitcoin constituency, and therefore it gives credibility to the argument that by coming to consensus on LOT=false among those who *are* speaking up is safer with the embedded assumptions that modifying consensus beyond what core ships is an active choice, presumably by those who know what they are doing. However, the simple act of Core choosing to ship an unconfigurable LOT=false value does not *prevent* the forking and creation of a UASF client. As Jeremy points out, the LOT=true possibility always exists here, and we have multiple high profile people saying they will be running that regardless of how things turn out. It seems to me that in this scenario, LOT=false does less to prevent a chain split. In regards to precedent, there may be good reasons to force that minority to fork themselves off the network, as would be the case if a hypothetical soft fork was a consensus action to blacklist some UTXO's or something else that weaponizes consensus against some subset of Bitcoin's user base, but I haven't heard a single person who advocates for LOT=false on the grounds that they *themselves* oppose the consensus change that is being proposed here. So if the goal is to prevent a chain split, and the soft fork is benign and essentially "annexing unoccupied territory" with respect to script versions, and no one actually has opposed Taproot itself, then I fail to see how LOT=false is safer in the presence of a grenade defense by the LOT=true crowd. I personally *prefer* LOT=true for these reasons, but I am NOT going to be joining the ranks of the intolerant minority if Core ultimately ships LOT=false. I think it is more important to stay in consensus, and as a result I am able to be convinced that false is the right answer. My question to everyone else (true AND false advocates) is this: what would you have to observe, in order to change your mind or is it immutably made up? If we have a significant portion of the community that is immutably made up to go false, and another portion that is going to go true, the asymmetry of the fork almost *requires* that those of us whose opinions are malleable to break for true. If social consensus is what drives technical consensus and not the other way around it seems as if there cannot exist a valid (rational?) reason to oppose Taproot itself, and then by extension with the arguments laid out above, LOT=true seems to be the logical conclusion of all of this, even if Core ships LOT=false at the outset. Where am I wrong here? Keagan On Mon, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Not responding to anyone in particular, but it strikes me that one can > think about the case where a small minority (let's say H = 20%?) of nodes > select the opposite of what Core releases (LOT=false, LOT=true). I'm > ignoring the case where a critical bug is discovered in Taproot for reasons > I could expand on if anyone is interested (I don't think LOT=true/false has > much of a diff in that regard). > > You'll note an asymmetry with LOT=true / false analysis. LOT=true nodes > are clearly updated (or lying), LOT=false nodes may be un-upgraded (or > however you want to interpret it). > > > *# 80% on LOT=false, 20% LOT=True* > > - Case 1: Activates ahead of time anyways > > No issues. > > - Case 2: Fails to Activate before timeout... > > 20% *may* fork off with LOT=true. Bitcoin hashrate reduced, chance of > multi block reorgs at time of fork relatively high, especially if network > does not partition. > > Implication is that activation % being 90%, then X% fewer than 70% of > miners are signaling for Taproot at this time. If X% is small the > increased orphan rate caused by the LOT=true miners will cause it to > activate anyways. If X% is larger, then there will be a consensus split. > > > > *# 80% on LOT=true, 20% LOT=False* > - Case 1: Activates ahead of time Anyways > > No issues. > > - Case 2: Fails to Activate before timeout... > > A% + B% + C% = 20% > > A% (upgraded, signal activate) remain on majority chain with LOT=false, > blocks mined universally valid. > > B% (upgraded, not signaling) succeeds in activating and maintaining > consensus, blocks are temporarily lost during the final period, but > consensus re-emerges. > > C% (not upgraded/not signalling) both fail to activate (not upgraded) and > blocks are rejected (not signaling) during mandatory signalling. > Essentially becomes an SPV miner, should still not select transactions > improperly given mempool policy, but may mine a bad tip. > > (I argue that group B is irrational entirely, as in this case the majority > has upgraded, inevitably winning, and is orphaning their blocks so B should > effectively be 0% or can be combined with group C as being somehow not > upgraded if they are unable to switch once it becomes clear after say the > first 100 blocks in the period that LOT > 50%. The only difference in > lumping B with C is that group C SPV mines after the fork and B should, in > theory, have full validation.). > > > > Apologies if my base analysis is off -- happy to take corrections. > > > My overall summary is thus: > > 1) People care what Core releases because we assume the majority will > likely run it. If core were a minority project, we wouldn't really care > what core released. > 2) People are upset with LOT=true being suggested as release parameters > because of the *narrative* that it puts devs in control. > 3) LOT=true having a sizeable minority running it presents major issues to > majority LOT=false in terms of lost blocks during the final period and in > terms of a longer term fork. > 4) Majority LOT=true has no long term instability on consensus (majority > LOT=true means the final period always activates, any instability is short > lived + irrational). > 5) On the balance, the safer parameter to release *seems* to be LOT=true. > But because devs are sensitive to control narrative, LOT=false is preferred > by devs. > 6) Almost paradoxically, choosing a *less safe* option for a narrative > reason is more of a show of dev control than choosing a more safe option > despite appearances. > 7) This all comes down to if we think that a reasonable number of > important nodes will run LOT=true. > 8) This all doesn't matter *that much* because taproot will have many > opportunities to activate before the brinksmanship period. > > As a plan of action, I think that means that either: > > A) Core should release LOT=true, as a less disruptive option given stated > community intentions to do LOT=true > B) Core community should vehemently anti-advocate running LOT=true to > ensure the % is as small as possible > C) Do nothing > D) Core community should release LOT=false and vehemently advocate > manually changing to LOT=true to ensure the % is supermajority, but leaving > it as a user choice. > > > Overall, I worry that plan B has a mild Streissand effect and would result > in boosting LOT=true (which could be OK, so long as LOT=true + > LOT=false+signal yes becomes the large majority, but would be not fun for > anyone if LOT=true + LOT=false+signal yes are a small majority). Plan C > most likely ends up with some % doing LOT=true anyways. D feels a little > silly, but maybe a good tradeoff. > > If I had to summarize the emotional dynamic among developers around > LOT=true, I think devs wish it didn't exist because it is clear LOT=true > *creates* the issues here. LOT=false would be fine if the LOT=true strategy > didn't exist at all. But unfortunately the cat is out of the bag and cannot > be put back in. To validate the emotions, I think it is fine to be angry > about LOT=true and not like it, but we should either accept that it is most > likely to create consensus OR we should find a new game theoretic > activation strategy with better pro-social equilibriums. > > Personally, I think with either plan the ultimate risk of forking is low > given probability to activate before timeout, so we should just pick > something and move on, accepting that we aren't setting a precedent by > which all future forks should abide. Given my understanding of the > tradeoffs, I believe that the safest choice is LOT=true, but I wouldn't > move to hold back a plan of LOT=false (but would probably take mitigative > steps on community advocacy if it looks like there is non majority but non > negligible LOT=true uptake). > > Cheers, > > Jeremy > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 17051 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-23 19:33 ` Keagan McClelland @ 2021-02-23 23:14 ` Ben Woosley 2021-02-24 22:37 ` Ariel Luaces 1 sibling, 0 replies; 42+ messages in thread From: Ben Woosley @ 2021-02-23 23:14 UTC (permalink / raw) To: Keagan McClelland, Jeremy; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 12574 bytes --] Relative to your arguments, Keagan and Jeremy, and speaking in favor of LOT=false, from my limited perspective: > As Jeremy points out, the LOT=true possibility always exists here, and we have multiple high profile people saying they will be running that regardless of how things turn out. It seems to me that in this scenario, LOT=false does less to prevent a chain split. > So if the goal is to prevent a chain split, and the soft fork is benign and essentially "annexing unoccupied territory" with respect to script versions, and no one actually has opposed Taproot itself, then I fail to see how LOT=false is safer in the presence of a grenade defense by the LOT=true crowd. I don't believe the goal is to avoid a chain split, nor to activate Taproot. Over the long term it will not have been important when exactly Taproot activated, or whether a minority forked off, but what culture and norms we adopted in putting forward this change. A culture of deference to the network makes Core worthy of remaining the reference implementation of Bitcoin. Given Core's special position in the client ecosystem, I see these outcomes are asymmetric: a) If an intolerant minority signals LOT=true in contradiction to core, they are splitting consensus / forking off consensus, which is their right to do in our open ecosystem. b) If Core ships LOT=true, we are in fact imposing a change on the network. This may be justified in the end, but it should be used with discretion. If LOT=false fails to activate, then the failure will have revealed information about sentiments and elements of the network, and we will have an opportunity then to address that information before proceeding with LOT=true. To adopt b) as a pre-emptive defense against a) is to express will without evidence of necessity or opportunity for justification. Finally, as others have said, I think this option is likely to be moot - let's not act defensively out of SEGWIT trauma, but with trust in the network. Best, Ben On Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > I wanted to follow up on what Jeremy and others are saying regards finding > consensus on LOT. I've seen a few other opinions saying that finding > consensus on the LOT value is far more important than what the LOT value > actually is. This makes sense because if 100% of economic activity is > running the same rule set, there is no divergence, regardless of which > value is picked. > > It is my understanding that those who oppose LOT=true are mostly opposed > on the grounds of it *appearing* "unnecessarily coercive" and that this > lack of consensus can precipitate a chain split at the > "brinksmanship period" as Jeremy refers to it. I don't think that we can > say that LOT=true is coercive at all unless there is some opposition to > Taproot itself. Opposition on the grounds that it *may* be opposed by > others and Core does not want to assert control over the protocol is a > conservative view but ultimately contingent upon opposition to Taproot for > more fundamental reasons. If no one opposes it, then by definition you have > consensus, and in that case I also don't think that the LOT=true (or false) > in that regard sets meaningful precedent, as I would expect precedents to > only be meaningful if they were established during a contentious scenario. > As it stands we have precedents for both MASF's and UASF's to execute soft > forks in Bitcoin. > > Of course it seems intractable to ascertain the views of ~100% of the > Bitcoin constituency, and therefore it gives credibility to the argument > that by coming to consensus on LOT=false among those who *are* speaking > up is safer with the embedded assumptions that modifying consensus beyond > what core ships is an active choice, presumably by those who know what they > are doing. However, the simple act of Core choosing to ship an > unconfigurable LOT=false value does not *prevent* the forking and > creation of a UASF client. As Jeremy points out, the LOT=true possibility > always exists here, and we have multiple high profile people saying they > will be running that regardless of how things turn out. It seems to me that > in this scenario, LOT=false does less to prevent a chain split. > > In regards to precedent, there may be good reasons to force that minority > to fork themselves off the network, as would be the case if a hypothetical > soft fork was a consensus action to blacklist some UTXO's or something else > that weaponizes consensus against some subset of Bitcoin's user base, but I > haven't heard a single person who advocates for LOT=false on the grounds > that they *themselves* oppose the consensus change that is being proposed > here. So if the goal is to prevent a chain split, and the soft fork is > benign and essentially "annexing unoccupied territory" with respect to > script versions, and no one actually has opposed Taproot itself, then I > fail to see how LOT=false is safer in the presence of a grenade defense by > the LOT=true crowd. > > I personally *prefer* LOT=true for these reasons, but I am NOT going to > be joining the ranks of the intolerant minority if Core ultimately ships > LOT=false. I think it is more important to stay in consensus, and as a > result I am able to be convinced that false is the right answer. My > question to everyone else (true AND false advocates) is this: what would > you have to observe, in order to change your mind or is it immutably made > up? If we have a significant portion of the community that is immutably > made up to go false, and another portion that is going to go true, the > asymmetry of the fork almost *requires* that those of us whose opinions > are malleable to break for true. > > If social consensus is what drives technical consensus and not the other > way around it seems as if there cannot exist a valid (rational?) reason to > oppose Taproot itself, and then by extension with the arguments laid out > above, LOT=true seems to be the logical conclusion of all of this, even if > Core ships LOT=false at the outset. > > Where am I wrong here? > > Keagan > > On Mon, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >> Not responding to anyone in particular, but it strikes me that one can >> think about the case where a small minority (let's say H = 20%?) of nodes >> select the opposite of what Core releases (LOT=false, LOT=true). I'm >> ignoring the case where a critical bug is discovered in Taproot for reasons >> I could expand on if anyone is interested (I don't think LOT=true/false has >> much of a diff in that regard). >> >> You'll note an asymmetry with LOT=true / false analysis. LOT=true nodes >> are clearly updated (or lying), LOT=false nodes may be un-upgraded (or >> however you want to interpret it). >> >> >> *# 80% on LOT=false, 20% LOT=True* >> >> - Case 1: Activates ahead of time anyways >> >> No issues. >> >> - Case 2: Fails to Activate before timeout... >> >> 20% *may* fork off with LOT=true. Bitcoin hashrate reduced, chance of >> multi block reorgs at time of fork relatively high, especially if network >> does not partition. >> >> Implication is that activation % being 90%, then X% fewer than 70% of >> miners are signaling for Taproot at this time. If X% is small the >> increased orphan rate caused by the LOT=true miners will cause it to >> activate anyways. If X% is larger, then there will be a consensus split. >> >> >> >> *# 80% on LOT=true, 20% LOT=False* >> - Case 1: Activates ahead of time Anyways >> >> No issues. >> >> - Case 2: Fails to Activate before timeout... >> >> A% + B% + C% = 20% >> >> A% (upgraded, signal activate) remain on majority chain with LOT=false, >> blocks mined universally valid. >> >> B% (upgraded, not signaling) succeeds in activating and maintaining >> consensus, blocks are temporarily lost during the final period, but >> consensus re-emerges. >> >> C% (not upgraded/not signalling) both fail to activate (not upgraded) and >> blocks are rejected (not signaling) during mandatory signalling. >> Essentially becomes an SPV miner, should still not select transactions >> improperly given mempool policy, but may mine a bad tip. >> >> (I argue that group B is irrational entirely, as in this case the >> majority has upgraded, inevitably winning, and is orphaning their blocks so >> B should effectively be 0% or can be combined with group C as being somehow >> not upgraded if they are unable to switch once it becomes clear after say >> the first 100 blocks in the period that LOT > 50%. The only difference in >> lumping B with C is that group C SPV mines after the fork and B should, in >> theory, have full validation.). >> >> >> >> Apologies if my base analysis is off -- happy to take corrections. >> >> >> My overall summary is thus: >> >> 1) People care what Core releases because we assume the majority will >> likely run it. If core were a minority project, we wouldn't really care >> what core released. >> 2) People are upset with LOT=true being suggested as release parameters >> because of the *narrative* that it puts devs in control. >> 3) LOT=true having a sizeable minority running it presents major issues >> to majority LOT=false in terms of lost blocks during the final period and >> in terms of a longer term fork. >> 4) Majority LOT=true has no long term instability on consensus (majority >> LOT=true means the final period always activates, any instability is short >> lived + irrational). >> 5) On the balance, the safer parameter to release *seems* to be LOT=true. >> But because devs are sensitive to control narrative, LOT=false is preferred >> by devs. >> 6) Almost paradoxically, choosing a *less safe* option for a narrative >> reason is more of a show of dev control than choosing a more safe option >> despite appearances. >> 7) This all comes down to if we think that a reasonable number of >> important nodes will run LOT=true. >> 8) This all doesn't matter *that much* because taproot will have many >> opportunities to activate before the brinksmanship period. >> >> As a plan of action, I think that means that either: >> >> A) Core should release LOT=true, as a less disruptive option given stated >> community intentions to do LOT=true >> B) Core community should vehemently anti-advocate running LOT=true to >> ensure the % is as small as possible >> C) Do nothing >> D) Core community should release LOT=false and vehemently advocate >> manually changing to LOT=true to ensure the % is supermajority, but leaving >> it as a user choice. >> >> >> Overall, I worry that plan B has a mild Streissand effect and would >> result in boosting LOT=true (which could be OK, so long as LOT=true + >> LOT=false+signal yes becomes the large majority, but would be not fun for >> anyone if LOT=true + LOT=false+signal yes are a small majority). Plan C >> most likely ends up with some % doing LOT=true anyways. D feels a little >> silly, but maybe a good tradeoff. >> >> If I had to summarize the emotional dynamic among developers around >> LOT=true, I think devs wish it didn't exist because it is clear LOT=true >> *creates* the issues here. LOT=false would be fine if the LOT=true strategy >> didn't exist at all. But unfortunately the cat is out of the bag and cannot >> be put back in. To validate the emotions, I think it is fine to be angry >> about LOT=true and not like it, but we should either accept that it is most >> likely to create consensus OR we should find a new game theoretic >> activation strategy with better pro-social equilibriums. >> >> Personally, I think with either plan the ultimate risk of forking is low >> given probability to activate before timeout, so we should just pick >> something and move on, accepting that we aren't setting a precedent by >> which all future forks should abide. Given my understanding of the >> tradeoffs, I believe that the safest choice is LOT=true, but I wouldn't >> move to hold back a plan of LOT=false (but would probably take mitigative >> steps on community advocacy if it looks like there is non majority but non >> negligible LOT=true uptake). >> >> Cheers, >> >> Jeremy >> >> >> _______________________________________________ >> 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 > [-- Attachment #2: Type: text/html, Size: 20078 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-23 19:33 ` Keagan McClelland 2021-02-23 23:14 ` Ben Woosley @ 2021-02-24 22:37 ` Ariel Luaces 2021-03-01 13:54 ` Erik Aronesty 1 sibling, 1 reply; 42+ messages in thread From: Ariel Luaces @ 2021-02-24 22:37 UTC (permalink / raw) To: Keagan McClelland, Bitcoin Protocol Discussion On Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > If social consensus is what drives technical consensus and not the other way around it seems as if there cannot exist a valid (rational?) reason to oppose Taproot itself, and then by extension with the arguments laid out above, LOT=true seems to be the logical conclusion of all of this, even if Core ships LOT=false at the outset. > > Where am I wrong here? > > Keagan > > On Mon, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >> >> Personally, I think with either plan the ultimate risk of forking is low given probability to activate before timeout, so we should just pick something and move on, accepting that we aren't setting a precedent by which all future forks should abide. Given my understanding of the tradeoffs, I believe that the safest choice is LOT=true, but I wouldn't move to hold back a plan of LOT=false (but would probably take mitigative steps on community advocacy if it looks like there is non majority but non negligible LOT=true uptake). >> >> Cheers, >> >> Jeremy >> >> >> _______________________________________________ >> 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 To favor LOT=true because it seems like the inevitable result is like playing the prisoner's dilemma and never cooperating instead of using the most optimal strategy which is tit-for-tat (cooperating at first and then cheating once for every time your counterparty cheats). During segwit users started by cooperating (BIP9, or "LOT=false"), then a minority of miners didn't cooperate (small veto but remember the majority of miners cooperated), then users stopped cooperating in response (UASF), then miners reverted to cooperating (MASF while intolerant miners forked off). Today users should start cooperating again to continue using the optimal strategy. Cheers Ariel Lorenzo-Luaces ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-24 22:37 ` Ariel Luaces @ 2021-03-01 13:54 ` Erik Aronesty 2021-03-02 18:32 ` Ariel Lorenzo-Luaces 0 siblings, 1 reply; 42+ messages in thread From: Erik Aronesty @ 2021-03-01 13:54 UTC (permalink / raw) To: Ariel Luaces, Bitcoin Protocol Discussion > Today users should start cooperating again to continue using the > optimal strategy. the "gradual" method of reducing the % of miners required for lock-in as time goes on seems to encode this optimal strategy. On Thu, Feb 25, 2021 at 6:43 AM Ariel Luaces via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > On Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: > > > > If social consensus is what drives technical consensus and not the other way around it seems as if there cannot exist a valid (rational?) reason to oppose Taproot itself, and then by extension with the arguments laid out above, LOT=true seems to be the logical conclusion of all of this, even if Core ships LOT=false at the outset. > > > > Where am I wrong here? > > > > Keagan > > > > On Mon, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > >> > >> Personally, I think with either plan the ultimate risk of forking is low given probability to activate before timeout, so we should just pick something and move on, accepting that we aren't setting a precedent by which all future forks should abide. Given my understanding of the tradeoffs, I believe that the safest choice is LOT=true, but I wouldn't move to hold back a plan of LOT=false (but would probably take mitigative steps on community advocacy if it looks like there is non majority but non negligible LOT=true uptake). > >> > >> Cheers, > >> > >> Jeremy > >> > >> > >> _______________________________________________ > >> 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 > > To favor LOT=true because it seems like the inevitable result is like > playing the prisoner's dilemma and never cooperating instead of using > the most optimal strategy which is tit-for-tat (cooperating at first > and then cheating once for every time your counterparty cheats). > > During segwit users started by cooperating (BIP9, or "LOT=false"), > then a minority of > miners didn't cooperate (small veto but remember the majority of > miners cooperated), then users stopped cooperating in response (UASF), > then miners > reverted to cooperating (MASF while intolerant miners forked off). > Today users should start cooperating again to continue using the > optimal strategy. > > Cheers > Ariel Lorenzo-Luaces > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-03-01 13:54 ` Erik Aronesty @ 2021-03-02 18:32 ` Ariel Lorenzo-Luaces 0 siblings, 0 replies; 42+ messages in thread From: Ariel Lorenzo-Luaces @ 2021-03-02 18:32 UTC (permalink / raw) To: Erik Aronesty; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3560 bytes --] I agree. Thank you Erik for proposing it. It's a pretty good idea. P.S. I wouldn't want a chain split of a low percentage of users though. The minority will be at the mercy of massive PoW swings and the chain will lose friends so it's not good for anyone. I recommend changing the final percentage to %50 because that's the hurdle where non-upgraded users *must* activate to avoid the risk of being reorged. The number of running users will quickly jump to 90%+ if it ever gets near 50%. Cheers Ariel Lorenzo-Luaces On Mar 1, 2021, 5:54 AM, at 5:54 AM, Erik Aronesty <erik@q32•com> wrote: >> Today users should start cooperating again to continue using the >> optimal strategy. > >the "gradual" method of reducing the % of miners required for lock-in >as time goes on seems to encode this optimal strategy. > >On Thu, Feb 25, 2021 at 6:43 AM Ariel Luaces via bitcoin-dev ><bitcoin-dev@lists•linuxfoundation.org> wrote: >> >> On Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev >> <bitcoin-dev@lists•linuxfoundation.org> wrote: >> > >> > If social consensus is what drives technical consensus and not the >other way around it seems as if there cannot exist a valid (rational?) >reason to oppose Taproot itself, and then by extension with the >arguments laid out above, LOT=true seems to be the logical conclusion >of all of this, even if Core ships LOT=false at the outset. >> > >> > Where am I wrong here? >> > >> > Keagan >> > >> > On Mon, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev ><bitcoin-dev@lists•linuxfoundation.org> wrote: >> >> >> >> Personally, I think with either plan the ultimate risk of forking >is low given probability to activate before timeout, so we should just >pick something and move on, accepting that we aren't setting a >precedent by which all future forks should abide. Given my >understanding of the tradeoffs, I believe that the safest choice is >LOT=true, but I wouldn't move to hold back a plan of LOT=false (but >would probably take mitigative steps on community advocacy if it looks >like there is non majority but non negligible LOT=true uptake). >> >> >> >> Cheers, >> >> >> >> Jeremy >> >> >> >> >> >> _______________________________________________ >> >> 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 >> >> To favor LOT=true because it seems like the inevitable result is like >> playing the prisoner's dilemma and never cooperating instead of using >> the most optimal strategy which is tit-for-tat (cooperating at first >> and then cheating once for every time your counterparty cheats). >> >> During segwit users started by cooperating (BIP9, or "LOT=false"), >> then a minority of >> miners didn't cooperate (small veto but remember the majority of >> miners cooperated), then users stopped cooperating in response >(UASF), >> then miners >> reverted to cooperating (MASF while intolerant miners forked off). >> Today users should start cooperating again to continue using the >> optimal strategy. >> >> Cheers >> Ariel Lorenzo-Luaces >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 4537 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-23 2:10 ` Jeremy 2021-02-23 19:33 ` Keagan McClelland @ 2021-02-24 7:18 ` Anthony Towns 1 sibling, 0 replies; 42+ messages in thread From: Anthony Towns @ 2021-02-24 7:18 UTC (permalink / raw) To: Jeremy, Bitcoin Protocol Discussion On Mon, Feb 22, 2021 at 06:10:34PM -0800, Jeremy via bitcoin-dev wrote: > Not responding to anyone in particular, but it strikes me that one can think > about the case where a small minority (let's say H = 20%?) of nodes I don't think that's a good way to try to look at things -- number of nodes has some impacts, but they're relatively minor (pun deflected). I think the things to look at are (from most to least important): (1) what the price indicates / what people buying/selling BTC want (2) what hashpower does (3) what nodes do Here's a concrete example to help justify that ordering. Suppose that for whatever reason nobody is particularly interested in running lockinontimeout=true -- only 0.1% of nodes are doing it and they're not the "economic majority" in any way. In addition, 15% of hashpower have spent almost the entire signalling period not bothering to upgrade and thus haven't been signalling and have been blocking activation. Suppose further that there are futures/prediction markets setup so that people can bet on taproot activation (eg the bitfinex chain split tokens, or some sort of DeFi contracts), and the result is that there's some decent profits to be made if it does activate, enough to tempt >55% of hashpower into running with lockinontimeout=true. That way those miners can be confident it will activate, take up contracts in the futures/predictions markets, and be confident they'll win and get a big payday. (Note that this means the people on the other side of those contracts are betting that taproot *doesn't* activate) Once a majority of hashpower is running lockinontimeout=true, it then makes sense for the remaining hashpower to both signal for activation and also run lockinontimeout=true -- otherwise they risk their blocks being orphaned if too many blocks don't signal, and they build on top of one. Figuring out that a majority of hashpower is/will be running lockinontimeout=true can be done either by a coinbase message or by bip91-style signalling. In that scenario, you end up with >90% of hashpower running with lockinontimeout=true, even if only a token number of nodes in the wild are doing the same. It's possible to do estimates of what happens if a majority of miners are using lockinontimeout=true, and the numbers end up pretty wild. With 90% of miners signalling and running lockinontimeout=true, if the remaining 10% don't signal, they can expect to lose around 3% of revenue ($2M) due to blocks getting orphaned. If the numbers are 85% running lockinontimeout=true, and 15% not signalling, the non-signallers can expect to lose about 37% of revenue ($38M) during the retarget period prior to timeout. If 60% of miners are doing spy-mining for up to 90s, they would expect to lose 0.9% of their spy-mining revenue ($2.5M). If 60% of hashpower is running lockinontimeout=true, while 40% don't signal, the non-signallers will forego ~83% of revenue ($320M) due to their blocks being orphaned, and if 60% of miners spy-mine for 90s, they should expect to lose 5% of revenue ($10M) over the same period. Dollar figures based on 6.25BTC/block at $50k per BTC. https://gist.github.com/ajtowns/fbcf30ed9d0e1708fdc98a876a04ff69#file-forced_signalling_chaos_cost_sim-py Note that if miners simply accept those losses and don't take any action to prevent it, very long reorgs are to be expected -- in the 15% non-signalling scenario, you'd expect to see a 5-block reorg; in the 40% non-signalling scenario, you'd get reorgs of 60+ blocks. (Only people not running lockinontimeout=true would see the blocks being reorged out, of course) So I think focussing on how many nodes have a particular lockinontimeout setting can be pretty misleading. > # 80% on LOT=false, 20% LOT=True > - Case 1: Activates ahead of time anyways That's the case where >90% of hashpower is signalling, and everything works fine. > - Case 2: Fails to Activate before timeout... > 20% *may* fork off with LOT=true. Anyone running with lockinontimeout=true will refuse to follow a chain where lockin hasn't been reached by the timeout height; so if the most work chain meets that condition, lockinontimeout=true nodes will refuse to follow it; either getting stuck with no confirmations at all, or following a lower work chain that does (or can) reach lockin by timeout height. > Bitcoin hashrate reduced, chance of multi > block reorgs at time of fork relatively high, especially if network does not > partition. If the most-work chain fails to activate, and only a minority of hashrate is running lockinontimeout=true, the chance of multiblock reorgs is actually pretty low. The way it would play out in detail, with say 20% of hashpower not signalling and 40% of hashpower running lockinontimeout=true: * the chain reaches the last retarget period; lockinontimeout=false nodes stay in STARTED, lockinontimeout=true nodes switch to MUST_SIGNAL * for the first ~1009 blocks, everyone stays in sync, but block ~1010 becomes the 202nd non-signalling block, meaning that the 60% of hashpower on lockinontimeout=false is now one block ahead of the 40% of hashpower on lockinontimeout=true * it's possible that the 40% have a lucky run and get ahead of the 60% chain causing a reorg. But in that case the within about 5 blocks, another non-signalling block will be mined and the 60% will be ahead again. So the 40% of lockinontimeout=true hashpower has to keep with with miners that have 150% of their hashrate for ~1000 blocks in order for everyone to end up on a locked in chain, which is vanishingly unlike. Even if you set the percentage not signalling to 11% and the percent of hashpower running lockinontimeout=true to 48%, by my count you only get about a 27% chance of ending up reaching lockin on the most work chain. With the 40%/20% figures above it's a flat 0.0%. https://gist.github.com/ajtowns/fbcf30ed9d0e1708fdc98a876a04ff69#file-test_disaster-py It's possible that the 60% will take some action to prevent their blocks being reorged out if the 40% do get lucky. One option would be for them to set lockinontimeout=true -- then we quickly get back to the "almost all hashpower ends up running lockinontimeout=true" and activation is certain. But they could just as easily decide that one getblockchaininfo reports a softfork isn't possible, they won't reorg to a chain where it is possible unless it's 2 or 4 or 6 or whatever blocks longer. > # 80% on LOT=true, 20% LOT=False > - Case 1: Activates ahead of time Anyways > No issues. This is same case where there's plenty of signalling and it's irrelevant what the setting for lockinontimeout is... > - Case 2: Fails to Activate before timeout... I'm not sure what you mean by "before timeout" here -- if you mean it reaches the MUST_SIGNAL phase, with 80% of hashpower running lockinontimeout=true, then things work out okay: even assuming that all 20% that are not running lockinontimeout=true are also not signalling, then the miners who don't signal will lose up to 56% of their revenue for the MUST_SIGNAL period (~$80M) , and if some of the lockinontimeout=true miners do spy-mining and build on top of non-signalling blocks, they may lose something like 1.7% of their revenue as well. In addition we might see reorgs of up to ~10 blocks as this resolves itself. That's a significant loss for the miners who are out of consensus, and the liklihood of large reorgs will make doing business with bitcoin harder, but that at least is all able to be coped with. But if you mean the most work chain reaches the timeout height without achieving locked in state, because the majority of miners aren't running lockinontimeout=true, then the 80% of nodes running lockinontimeout=true will be stalled, and unable to process transactions, until they downgrade. If that ever occurred, it would be an astounding disaster, and I hope the first thing people would do is decide never to run any software by whoever proposed, ACKed or merged the PR that resulted in 80% of nodes running with lockinontimeout=true. *Because* it would be such a disaster to effectively run a denial-of-service attack on 80% of nodes, it's plausible that price signals would indicate to miners that it will be much more profitable to run lockinontimeout=true, preventing that from occuring. But people can make profits out of disasters too -- it might be that people will figure "oh, the price will crash if this happens, so it'll be a chance to get some cheap bitcoins, and maybe put competing miners out of business so I can buy their ASICs off them for cheap too!" > My overall summary is thus: > 1) People care what Core releases because we assume the majority will likely > run it. If core were a minority project, we wouldn't really care what core > released. That seems very backwards to me. I'd put it as: people run core because it makes good, conservative decisions on what features to add. If "choose your own consensus rules" were what the market wanted, then Bitcoin Unlimited or similar would be what everyone was running. If core were to change that policy and push risky changes, I'd hope that users would be able to recognise this, and would switch to an implementation that continues to emphasise safe, conservative policies. > 2) People are upset with LOT=true being suggested as release parameters because > of the narrative that it puts devs in control. If users will just run whatever core devs release, even if it involves contentious changes to consensus rules, then the core devs are in control. > 3) LOT=true having a sizeable minority running it presents major issues to > majority LOT=false in terms of lost blocks during the final period and in terms > of a longer term fork. As above, I think this scenario is easy to avoid if it were to eventuate. > 4) Majority LOT=true has no long term instability on consensus (majority LOT= > true means the final period always activates, any instability is short lived + > irrational). The instability occurs if the lockinontimeout=true chain stalls or is overtaken by a more-work non-activating chain, then users running nodes with that parameter set will stop their nodes, and reinstall/reconfigure it to set lockinontimeout=false. > 5) On the balance, the safer parameter to release *seems* to be LOT=true. But > because devs are sensitive to control narrative, LOT=false is preferred by > devs. I think that conclusion is based on a few shakey assumptions; particularly that people won't downgrade/reinstall back to lockinontimeout=false and that miners will be be pretty naive about allowing their blocks to be orphaned. > 6) Almost paradoxically, choosing a less safe option for a narrative reason is > more of a show of dev control than choosing a more safe option despite > appearances. Going all-in on a bluff can be a good bet 9 times out of 10, while still being a net negative because of the 1 time out of 10 when you lose. In the examples above, the "80% of nodes running the default client can no longer follow the blockchain without manual intervention" is the "lose it all scenario", even if "taproot" is probably one of the 9/10 cases, not the 1/10 case. > 7) This all comes down to if we think that a reasonable number of important > nodes will run LOT=true. What nodes run (as compared to hashpower, or as compared to what people want to buy/sell) is the least important factor in working out what's going to happen. > As a plan of action, I think that means that either: > A) Core should release LOT=true, as a less disruptive option given stated > community intentions to do LOT=true > B) Core community should vehemently anti-advocate running LOT=true to ensure > the % is as small as possible > C) Do nothing > D) Core community should release LOT=false and vehemently advocate manually > changing to LOT=true to ensure the % is supermajority, but leaving it as a user > choice. I think these are all a bit terrible as plans of action -- "core should release X, then advocate Y" is really not playing to core's strengths. Far better for devs to focus on writing/debugging code, analysing the way things work, making tests, and adding mitigations for risks. Better for bloggers and podcasters and the twitterati to do the advocacy, and core to stick to working on code and saying "no, there are significant technical risks to doing that that we don't yet have mitigations for" when people advocate for risky things. My view is more along the lines of: - the setting for lockinontimeout will not matter until around July 2022, (though maybe as early as May 2022 if blocks come really fast) either technically or even as a game theory incentive - lockinontimeout=true has consensus implications, and depending on the response by miners can cause network interruptions like long chains of reorgs. At best, it hasn't had the same level of review as taproot, and some experienced developers aren't comfortable with it as it stands. Those seem like pretty good reasons not to deploy it immediately, IMO. - the lockinontimeout=true code we've got doesn't do (at least) two things that the bip148 client did that help avoid bad cases: - ensure preferential connections to other nodes setting lockinontimeout=true to prevent network splits if the non-activating chain is longer during/after the MUST_SIGNAL phase - cope with rewinding the chain to the best lockinontimeout=true valid block, in the event a node is upgraded to lockinontimeout=true from either lockinontimeout=false or a version of bitcoind that doesn't have activation parameters set at all I think it makes more sense to: 1) release lockinontimeout=false code with a view to reconsidering it at about ~6 months (so prior to the 23.0 release) 2) do more review of lockinontimeout=true code to ensure everyone understands what behaviours are likely 3) add support for the features from the bip148 client, along with any other mitigations we think of, assuming we can do so in a way that's safe and sane 4) work with miners and mining pools to ensure that if lockinontimeout=true does get used they know how to minimise disruption and losses due to orphaning, etc. That gives us about 6 months work on (2) and (3), and probably 9-12 months to work on (4), and it's all technical rather than advocacy and popularity contests. Six, nine or twelve months should be plenty of time to get pretty clear indications of what both the market in general thinks about things, and what miners are thinking. I think if lockinontimeout=true weren't new code, and devs, miners and users widely understood its potential behaviours and risks, and we didn't have safety features that were still on the todo list, then there'd be a good argument for doing lockinontimeout=true from day 1. I could see that being the case for the next soft-fork, assuming it gets a similar amount of review prior to deployment as taproot has had, eg. But, to me, taking a more cautious approach seems more sensible today. > If I had to summarize the emotional dynamic among developers [...] (Fortunately, you don't have to do that...) Cheers, aj ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-18 11:52 ` ZmnSCPxj 2021-02-18 12:20 ` Michael Folkson @ 2021-02-18 13:59 ` Matt Corallo 1 sibling, 0 replies; 42+ messages in thread From: Matt Corallo @ 2021-02-18 13:59 UTC (permalink / raw) To: ZmnSCPxj, Bitcoin Protocol Discussion; +Cc: Michael Folkson Bitcoin is a consensus system. Please let’s not jump to (or even consider) options that discourage consensus. We all laughed at (and later academics researched showed severe deficiencies in) Bitcoin XT’s “emergent consensus” nonsense, why should we start doing things along that line in Bitcoin? (Resent from the correct email) Matt > On Feb 18, 2021, at 06:52, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> 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 <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> 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 > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-17 12:51 [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) Michael Folkson 2021-02-18 5:43 ` Ariel Lorenzo-Luaces @ 2021-02-21 16:21 ` Erik Aronesty 1 sibling, 0 replies; 42+ messages in thread From: Erik Aronesty @ 2021-02-21 16:21 UTC (permalink / raw) To: Michael Folkson, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 5523 bytes --] I think the most important thing is that the configuration setting is advertised if somebody were to query the node for its capabilities. Is this the case? That way the default value isn't really the important thing. There are longstanding and well-known nodes, for example. Community support and visibility for a UASF is the most important aspect. I looked over the threads and I don't think I saw the broadcast nature of this setting clearly discussed. On Wed, Feb 17, 2021, 10:10 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: 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 > [-- Attachment #2: Type: text/html, Size: 7427 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
@ 2021-02-19 22:12 Matt Hill
2021-02-19 23:30 ` Matt Corallo
0 siblings, 1 reply; 42+ messages in thread
From: Matt Hill @ 2021-02-19 22:12 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2119 bytes --]
Good day all, this is my first post to this mailing list. Per Adam's
comment below:
> given there are clearly people of both views, or for now don't care
but might later, it would minimally be friendly and useful if
bitcoin-core has a LOT=true option - and that IMO goes some way to
avoid the assumptive control via defaults.
Both here and elsewhere, the debate taking place is around the manner of
Taproot activation, not whether or not Taproot should be activated. The
latter seems to have widespread support. Given this favorable environment,
it seems to me this is an incredible opportunity for the developer
contingency to "take the high road" while also minimizing time to Taproot
activation using political incentives. By offering power on the left hand
to miners and and power on the right to users, neither of whom is
expressing disapproval of activation, but both of whom are able to activate
without the consent of the other, both are incentivized to signal
activation as quickly as possible to emerge as the "group that did it". All
that must be done is to include a LOT=true option to Bitcoin Core that
carries a default of LOT=false. Miners can activate at any time, users can
signal their intent to activate should miners renege, and developers emerge
as politically neutral in the eyes of both.
Extrapolating a bit, I contend this expanded agency of full node
operatorship may result in more users running a full node, which is good
and healthy. From a miner's point of view, more full nodes only increases
the likelihood of future UASFs, and so they are even further incentivized
to expedite Taproot activation. Perhaps this is a stretch, perhaps not.
To summarize: (1) this positions developers as neutral facilitators who
deferred power to the other contingencies; (2) we may see a rise in the
popularity of running a full node and the number of full node operators;
(3) miners are incentivized to activate quickly to avoid being perceived as
the "bad guys" and to avoid the spread of full nodes; and (4) even if
miners do not activate, users can organize a UASF in a grass-roots way.
Matt Hill
[-- Attachment #2: Type: text/html, Size: 2896 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-19 22:12 Matt Hill @ 2021-02-19 23:30 ` Matt Corallo 2021-02-19 23:42 ` Bryan Bishop 0 siblings, 1 reply; 42+ messages in thread From: Matt Corallo @ 2021-02-19 23:30 UTC (permalink / raw) To: Matt Hill via bitcoin-dev (off-list) Your email client didn't thread correctly, so I'm not sure if you saw my responses to Adam's email, but note that there is no such thing as "All that must be done" here - supporting multiple, different, consensus rules for a given chain is a nontrivial undertaking in Bitcoin Core from a software perspective. The only practical way is to, just treat it as a different chain, which, in practice, it could be. One group running LOT=true and one running LOT=false results in two Bitcoins, and the software would need to be able to handle that (and, presumably, allow users to switch between chains). Matt On 2/19/21 17:12, Matt Hill via bitcoin-dev wrote: > Good day all, this is my first post to this mailing list. Per Adam's comment below: > > > given there are clearly people of both views, or for now don't care > but might later, it would minimally be friendly and useful if > bitcoin-core has a LOT=true option - and that IMO goes some way to > avoid the assumptive control via defaults. > > Both here and elsewhere, the debate taking place is around the manner of Taproot activation, not whether or not Taproot > should be activated. The latter seems to have widespread support. Given this favorable environment, it seems to me this > is an incredible opportunity for the developer contingency to "take the high road" while also minimizing time to Taproot > activation using political incentives. By offering power on the left hand to miners and and power on the right to users, > neither of whom is expressing disapproval of activation, but both of whom are able to activate without the consent of > the other, both are incentivized to signal activation as quickly as possible to emerge as the "group that did it". All > that must be done is to include a LOT=true option to Bitcoin Core that carries a default of LOT=false. Miners can > activate at any time, users can signal their intent to activate should miners renege, and developers emerge as > politically neutral in the eyes of both. > > Extrapolating a bit, I contend this expanded agency of full node operatorship may result in more users running a full > node, which is good and healthy. From a miner's point of view, more full nodes only increases the likelihood of future > UASFs, and so they are even further incentivized to expedite Taproot activation. Perhaps this is a stretch, perhaps not. > > To summarize: (1) this positions developers as neutral facilitators who deferred power to the other contingencies; (2) > we may see a rise in the popularity of running a full node and the number of full node operators; (3) miners are > incentivized to activate quickly to avoid being perceived as the "bad guys" and to avoid the spread of full nodes; and > (4) even if miners do not activate, users can organize a UASF in a grass-roots way. > > Matt Hill > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 2021-02-19 23:30 ` Matt Corallo @ 2021-02-19 23:42 ` Bryan Bishop 0 siblings, 0 replies; 42+ messages in thread From: Bryan Bishop @ 2021-02-19 23:42 UTC (permalink / raw) To: Matt Corallo, Matt Hill, Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 585 bytes --] On Fri, Feb 19, 2021 at 5:31 PM Matt Corallo via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > (off-list) > > Your email client didn't thread correctly, so I'm not sure if you saw my > responses to Adam's email, but note that there That was not off-list; by the way, as a reminder, some users are digest subscribed (or not subscribed at all) and they can only reply by making a new email thread unless they want to forge the email headers to match the thread (which is a lost art that not many people are familiar with anymore). - Bryan https://twitter.com/kanzure [-- Attachment #2: Type: text/html, Size: 1019 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
@ 2021-02-21 10:10 Prayank
0 siblings, 0 replies; 42+ messages in thread
From: Prayank @ 2021-02-21 10:10 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1929 bytes --]
Hello Everyone,
The below comment by Matt about different implementations and their opinion on `lockinontimeout` is from 18 Feb 2021 communication: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018433.html
> 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.
I don't agree to the part that 'we should stop and not activate taproot'. Instead it will be helpful if we can educate most of the people about trade-offs involved in both options with some tables, charts etc.
I think its time to use Bitcoin Knots for more projects and also maintain multiple forks of Bitcoin Core. This is not just limited to `LOT=True or False` but few other things and in general its good for decentralization of Bitcoin. Bitcoin Core is used by most of the nodes according to this pie chart: https://luke.dashjr.org/programs/bitcoin/files/charts/software.html however having multiple forks of Bitcoin Core with real usage, more maintainers in different parts of the world (some even anon), few different features, more reviewers, better communication channels etc. will help everyone involved in Bitcoin.
I am working on a project right now which involves multisig, discreet log contracts, liquid etc. Using bitcoin-s for it because I need DLC but still depending on Bitcoin Core in it. Would try Bitcoin Knots and other implementations soon and also have been looking for developers good with C++ and Python, living in India who are interested to maintain a fork of Bitcoin Core with few changes. I had shared about in replies to Amir Taaki's tweet few days back.
--
Prayank
[-- Attachment #2: Type: text/html, Size: 5156 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in threadend of thread, other threads:[~2021-03-02 18:32 UTC | newest] Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-02-17 12:51 [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) Michael Folkson 2021-02-18 5:43 ` Ariel Lorenzo-Luaces 2021-02-18 11:01 ` Michael Folkson 2021-02-18 11:11 ` Samson Mow 2021-02-18 11:52 ` ZmnSCPxj 2021-02-18 12:20 ` Michael Folkson 2021-02-18 14:01 ` Matt Corallo 2021-02-18 14:26 ` Michael Folkson 2021-02-18 14:42 ` Matt Corallo 2021-02-18 14:51 ` Michael Folkson 2021-02-18 14:53 ` Matt Corallo 2021-02-18 15:01 ` Matt Corallo 2021-02-18 15:04 ` Keagan McClelland 2021-02-18 15:18 ` Matt Corallo 2021-02-19 2:20 ` Ariel Luaces 2021-02-19 11:30 ` ZmnSCPxj 2021-02-19 12:05 ` Adam Back 2021-02-19 14:13 ` Matt Corallo 2021-02-19 17:48 ` Matt Corallo 2021-02-20 2:55 ` ZmnSCPxj 2021-02-20 17:20 ` Ariel Lorenzo-Luaces 2021-02-21 14:30 ` Matt Corallo 2021-02-22 5:16 ` Anthony Towns 2021-02-22 6:44 ` Matt Corallo 2021-02-22 10:16 ` Anthony Towns 2021-02-22 14:00 ` Matt Corallo 2021-02-22 16:27 ` Anthony Towns 2021-02-22 16:31 ` Jorge Timón 2021-02-22 16:48 ` Jorge Timón 2021-02-23 2:10 ` Jeremy 2021-02-23 19:33 ` Keagan McClelland 2021-02-23 23:14 ` Ben Woosley 2021-02-24 22:37 ` Ariel Luaces 2021-03-01 13:54 ` Erik Aronesty 2021-03-02 18:32 ` Ariel Lorenzo-Luaces 2021-02-24 7:18 ` Anthony Towns 2021-02-18 13:59 ` Matt Corallo 2021-02-21 16:21 ` Erik Aronesty 2021-02-19 22:12 Matt Hill 2021-02-19 23:30 ` Matt Corallo 2021-02-19 23:42 ` Bryan Bishop 2021-02-21 10:10 Prayank
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox