Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2021-02-18 📝 Original message:You say "short term PR", I ...
📅 Original date posted:2021-02-18
📝 Original message: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 at mattcorallo.com <mailto:lf-lists at 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 at mattcorallo.com <mailto:lf-lists at mattcorallo.com>
> <mailto:lf-lists at mattcorallo.com <mailto:lf-lists at 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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> >> <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at 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 at protonmail.com <mailto:ZmnSCPxj at protonmail.com>
> <mailto:ZmnSCPxj at protonmail.com <mailto:ZmnSCPxj at 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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> >> <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at 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 at gmail.com
> <mailto:arielluaces at gmail.com>
> >> <mailto:arielluaces at gmail.com <mailto:arielluaces at 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 at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> >> <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at 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 at gmail.com <mailto:michaelfolkson at gmail.com> <mailto:michaelfolkson at gmail.com
> <mailto:michaelfolkson at gmail.com>>
> >> > > Keybase: michaelfolkson
> >> > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> >> > > _______________________________________________
> >> > > bitcoin-dev mailing list
> >> > > bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at 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 at gmail.com <mailto:michaelfolkson at gmail.com> <mailto:michaelfolkson at gmail.com
> <mailto:michaelfolkson at gmail.com>>
> >> Keybase: michaelfolkson
> >> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at 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 at gmail.com <mailto:michaelfolkson at gmail.com> <mailto:michaelfolkson at gmail.com
> <mailto:michaelfolkson at gmail.com>>
> > Keybase: michaelfolkson
> > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
>
>
> --
> Michael Folkson
> Email: michaelfolkson at gmail.com <mailto:michaelfolkson at gmail.com>
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
📝 Original message: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 at mattcorallo.com <mailto:lf-lists at 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 at mattcorallo.com <mailto:lf-lists at mattcorallo.com>
> <mailto:lf-lists at mattcorallo.com <mailto:lf-lists at 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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> >> <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at 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 at protonmail.com <mailto:ZmnSCPxj at protonmail.com>
> <mailto:ZmnSCPxj at protonmail.com <mailto:ZmnSCPxj at 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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> >> <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at 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 at gmail.com
> <mailto:arielluaces at gmail.com>
> >> <mailto:arielluaces at gmail.com <mailto:arielluaces at 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 at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> >> <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at 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 at gmail.com <mailto:michaelfolkson at gmail.com> <mailto:michaelfolkson at gmail.com
> <mailto:michaelfolkson at gmail.com>>
> >> > > Keybase: michaelfolkson
> >> > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> >> > > _______________________________________________
> >> > > bitcoin-dev mailing list
> >> > > bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at 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 at gmail.com <mailto:michaelfolkson at gmail.com> <mailto:michaelfolkson at gmail.com
> <mailto:michaelfolkson at gmail.com>>
> >> Keybase: michaelfolkson
> >> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at 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 at gmail.com <mailto:michaelfolkson at gmail.com> <mailto:michaelfolkson at gmail.com
> <mailto:michaelfolkson at gmail.com>>
> > Keybase: michaelfolkson
> > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
>
>
> --
> Michael Folkson
> Email: michaelfolkson at gmail.com <mailto:michaelfolkson at gmail.com>
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3