[bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Michael Folkson]

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

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Ariel Lorenzo-Luaces]

[-- 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 --]

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Michael Folkson]

[-- 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 --]

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Samson Mow]

[-- 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 --]

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[ZmnSCPxj]

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

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Michael Folkson]

[-- 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 --]

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Matt Corallo]

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

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Matt Corallo]

[-- 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 --]

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Michael Folkson]

[-- 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 --]

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Matt Corallo]

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

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Michael Folkson]

[-- 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 --]

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Matt Corallo]

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

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Matt Corallo]

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

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Keagan McClelland]

[-- 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 --]

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Matt Corallo]

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>
> 

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Ariel Luaces]

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

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[ZmnSCPxj]

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

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Adam Back]

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

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Matt Corallo]

(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".

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Matt Corallo]

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
> 

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[ZmnSCPxj]

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

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Ariel Lorenzo-Luaces]

[-- 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 --]

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Matt Corallo]

[-- 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 --]

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Erik Aronesty]

[-- 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 --]

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Anthony Towns]

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

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Matt Corallo]

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
> 

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Anthony Towns]

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

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Matt Corallo]

[-- 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 --]

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Anthony Towns]

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...

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Jorge Timón]

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

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Jorge Timón]

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

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Jeremy]

[-- 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 --]

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Keagan McClelland]

[-- 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 --]

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Ben Woosley]

[-- 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 --]

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Anthony Towns]

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

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Ariel Luaces]

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

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Erik Aronesty]

> 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

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Ariel Lorenzo-Luaces]

[-- 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 --]

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Prayank]

[-- 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 --]

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Bryan Bishop]

[-- 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 --]

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Matt Corallo]

(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
> 

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Matt Hill]

[-- 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 --]