public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
@ 2021-02-21 10:10 Prayank
  0 siblings, 0 replies; 42+ messages in thread
From: Prayank @ 2021-02-21 10:10 UTC (permalink / raw)
  To: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1929 bytes --]

Hello Everyone,

The below comment by Matt about different implementations and their opinion on `lockinontimeout` is from 18 Feb 2021 communication: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018433.html

> If the eventual outcome is that different implementations (that have material *transaction processing* userbases, and I’m not sure to what extent that’s true with Knots) ship different consensus rules, we should stop here and not activate Taproot. Seriously. Bitcoin is a consensus system. The absolute worst outcome at all possible is to have it fall out of consensus.

I don't agree to the part that 'we should stop and not activate taproot'. Instead it will be helpful if we can educate most of the people about trade-offs involved in both options with some tables, charts etc.

I think its time to use Bitcoin Knots for more projects and also maintain multiple forks of Bitcoin Core. This is not just limited to `LOT=True or False` but few other things and in general its good for decentralization of Bitcoin. Bitcoin Core is used by most of the nodes according to this pie chart: https://luke.dashjr.org/programs/bitcoin/files/charts/software.html however having multiple forks of Bitcoin Core with real usage, more maintainers in different parts of the world (some even anon), few different features, more reviewers, better communication channels etc. will help everyone involved in Bitcoin.

I am working on a project right now which involves multisig, discreet log contracts, liquid etc. Using bitcoin-s for it because I need DLC but still depending on Bitcoin Core in it. Would try Bitcoin Knots and other implementations soon and also have been looking for developers good with C++ and Python, living in India who are interested to maintain a fork of Bitcoin Core with few changes. I had shared about in replies to Amir Taaki's tweet few days back.

--
Prayank


[-- Attachment #2: Type: text/html, Size: 5156 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
@ 2021-02-19 22:12 Matt Hill
  2021-02-19 23:30 ` Matt Corallo
  0 siblings, 1 reply; 42+ messages in thread
From: Matt Hill @ 2021-02-19 22:12 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 2119 bytes --]

Good day all, this is my first post to this mailing list. Per Adam's
comment below:

> given there are clearly people of both views, or for now don't care
but might later, it would minimally be friendly and useful if
bitcoin-core has a LOT=true option - and that IMO goes some way to
avoid the assumptive control via defaults.

Both here and elsewhere, the debate taking place is around the manner of
Taproot activation, not whether or not Taproot should be activated. The
latter seems to have widespread support. Given this favorable environment,
it seems to me this is an incredible opportunity for the developer
contingency to "take the high road" while also minimizing time to Taproot
activation using political incentives. By offering power on the left hand
to miners and and power on the right to users, neither of whom is
expressing disapproval of activation, but both of whom are able to activate
without the consent of the other, both are incentivized to signal
activation as quickly as possible to emerge as the "group that did it". All
that must be done is to include a LOT=true option to Bitcoin Core that
carries a default of LOT=false. Miners can activate at any time, users can
signal their intent to activate should miners renege, and developers emerge
as politically neutral in the eyes of both.

Extrapolating a bit, I contend this expanded agency of full node
operatorship may result in more users running a full node, which is good
and healthy. From a miner's point of view, more full nodes only increases
the likelihood of future UASFs, and so they are even further incentivized
to expedite Taproot activation. Perhaps this is a stretch, perhaps not.

To summarize: (1) this positions developers as neutral facilitators who
deferred power to the other contingencies; (2) we may see a rise in the
popularity of running a full node and the number of full node operators;
(3) miners are incentivized to activate quickly to avoid being perceived as
the "bad guys" and to avoid the spread of full nodes; and (4) even if
miners do not activate, users can organize a UASF in a grass-roots way.

Matt Hill

[-- Attachment #2: Type: text/html, Size: 2896 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread

• * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
    2021-02-19 22:12 Matt Hill
  @ 2021-02-19 23:30 ` Matt Corallo
    2021-02-19 23:42   ` Bryan Bishop
    0 siblings, 1 reply; 42+ messages in thread
  From: Matt Corallo @ 2021-02-19 23:30 UTC (permalink / raw)
    To: Matt Hill via bitcoin-dev
  
  (off-list)
  
  Your email client didn't thread correctly, so I'm not sure if you saw my responses to Adam's email, but note that there 
  is no such thing as "All that must be done" here - supporting multiple, different, consensus rules for a given chain is 
  a nontrivial undertaking in Bitcoin Core from a software perspective. The only practical way is to, just treat it as a 
  different chain, which, in practice, it could be.
  
  One group running LOT=true and one running LOT=false results in two Bitcoins, and the software would need to be able to 
  handle that (and, presumably, allow users to switch between chains).
  
  Matt
  
  On 2/19/21 17:12, Matt Hill via bitcoin-dev wrote:
  > Good day all, this is my first post to this mailing list. Per Adam's comment below:
  > 
  >  > given there are clearly people of both views, or for now don't care
  > but might later, it would minimally be friendly and useful if
  > bitcoin-core has a LOT=true option - and that IMO goes some way to
  > avoid the assumptive control via defaults.
  > 
  > Both here and elsewhere, the debate taking place is around the manner of Taproot activation, not whether or not Taproot 
  > should be activated. The latter seems to have widespread support. Given this favorable environment, it seems to me this 
  > is an incredible opportunity for the developer contingency to "take the high road" while also minimizing time to Taproot 
  > activation using political incentives. By offering power on the left hand to miners and and power on the right to users, 
  > neither of whom is expressing disapproval of activation, but both of whom are able to activate without the consent of 
  > the other, both are incentivized to signal activation as quickly as possible to emerge as the "group that did it". All 
  > that must be done is to include a LOT=true option to Bitcoin Core that carries a default of LOT=false. Miners can 
  > activate at any time, users can signal their intent to activate should miners renege, and developers emerge as 
  > politically neutral in the eyes of both.
  > 
  > Extrapolating a bit, I contend this expanded agency of full node operatorship may result in more users running a full 
  > node, which is good and healthy. From a miner's point of view, more full nodes only increases the likelihood of future 
  > UASFs, and so they are even further incentivized to expedite Taproot activation. Perhaps this is a stretch, perhaps not.
  > 
  > To summarize: (1) this positions developers as neutral facilitators who deferred power to the other contingencies; (2) 
  > we may see a rise in the popularity of running a full node and the number of full node operators; (3) miners are 
  > incentivized to activate quickly to avoid being perceived as the "bad guys" and to avoid the spread of full nodes; and 
  > (4) even if miners do not activate, users can organize a UASF in a grass-roots way.
  > 
  > Matt Hill
  > 
  > _______________________________________________
  > bitcoin-dev mailing list
  > bitcoin-dev@lists•linuxfoundation.org
  > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
  > 
  
  
  ^ permalink raw reply	[flat|nested] 42+ messages in thread

• • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
      2021-02-19 23:30 ` Matt Corallo
    @ 2021-02-19 23:42   ` Bryan Bishop
      0 siblings, 0 replies; 42+ messages in thread
    From: Bryan Bishop @ 2021-02-19 23:42 UTC (permalink / raw)
      To: Matt Corallo, Matt Hill, Bitcoin Dev
    
    [-- Attachment #1: Type: text/plain, Size: 585 bytes --]
    
    On Fri, Feb 19, 2021 at 5:31 PM Matt Corallo via bitcoin-dev <
    bitcoin-dev@lists•linuxfoundation.org> wrote:
    
    > (off-list)
    >
    > Your email client didn't thread correctly, so I'm not sure if you saw my
    > responses to Adam's email, but note that there
    
    
    That was not off-list; by the way, as a reminder, some users are digest
    subscribed (or not subscribed at all) and they can only reply by making a
    new email thread unless they want to forge the email headers to match the
    thread (which is a lost art that not many people are familiar with anymore).
    
    - Bryan
    https://twitter.com/kanzure
    
    [-- Attachment #2: Type: text/html, Size: 1019 bytes --]
    
    ^ permalink raw reply	[flat|nested] 42+ messages in thread

* [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
@ 2021-02-17 12:51 Michael Folkson
  2021-02-18  5:43 ` Ariel Lorenzo-Luaces
  2021-02-21 16:21 ` Erik Aronesty
  0 siblings, 2 replies; 42+ messages in thread
From: Michael Folkson @ 2021-02-17 12:51 UTC (permalink / raw)
  To: bitcoin-dev

Yesterday (February 16th) we held a second meeting on Taproot
activation on IRC which again was open to all. Despite what appeared
to be majority support for LOT=false over LOT=true in the first
meeting I (and others) thought the arguments had not been explored in
depth and that we should have a follow up meeting almost entirely
focused on whether LOT (lockinontimeout) should be set to true or
false.

The meeting was announced here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html

In that mailing list post I outlined the arguments for LOT=true (T1 to
T6) and arguments for LOT=false (F1 to F6) in their strongest form I
could. David Harding responded with an additional argument for
LOT=false (F7) here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html

These meetings are very challenging given they are open to all, you
don’t know who will attend and you don’t know most people’s views in
advance. I tried to give time for both the LOT=true arguments and the
LOT=false arguments to be discussed as I knew there was support for
both. We only tried evaluating which had more support and which had
more strong opposition towards the end of the meeting.

The conversation log is here:
http://gnusha.org/taproot-activation/2021-02-16.log

(If you are so inclined you can watch a video of the meeting here.
Thanks to the YouTube account “Bitcoin” for setting up the livestream:
https://www.youtube.com/watch?v=vpl5q1ovMLM)

A summary of the meeting was provided by Luke Dashjr on Mastodon here:
https://bitcoinhackers.org/@lukedashjr/105742918779234566

Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we
did manage to come to consensus on everything but LockinOnTimeout.

Activation height range: 693504-745920

MASF threshold: 1815/2016 blocks (90%)

Keep in mind only ~100 people showed for the meetings, hardly
representative of the entire community.

So, these details remain JUST a proposal for now.

It seems inevitable that there won't be consensus on LOT.

Everyone will have to choose for himself. :/

Personally I agree with most of this. I agree that there wasn’t
overwhelming consensus for either LOT=true or LOT=false. However, from
my perspective there was clearly more strong opposition (what would
usually be deemed a NACK in Bitcoin Core review terminology) from
Bitcoin Core contributors, Lightning developers and other community
members against LOT=true than there was for LOT=false. Andrew Chow
tried to summarize views from the meeting in this analysis:
https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c

I am also aware of other current and previous Bitcoin Core
contributors and Lightning developers who didn’t attend the meeting in
person who are opposed to LOT=true. I don’t want to put them in the
spotlight for no reason but if you go through the conversation logs of
not only the meeting but the weeks of discussion prior to this meeting
you will see their views evaluated on the ##taproot-activation
channel. In addition, on taprootactivation.com some mining pools
expressed a preference for lot=false though I don’t know how strong
that preference was.

I am only one voice but it is my current assessment that if we are to
attempt to finalize Taproot activation parameters and propose them to
the community at this time our only option is to propose LOT=false.
Any further delay appears to me counterproductive in our collective
aim to get the Taproot soft fork activated as early as possible.

Obviously others are free to disagree with that assessment and
continue discussions but personally I will be attempting to avoid
those discussions unless prominent new information comes to light or
various specific individuals change their minds.

Next week we are planning a code review of the Bitcoin Core PR #19573
which was initially delayed because of this LOT discussion. As I’ve
said previously that will be loosely following the format of the
Bitcoin Core PR review club and will be lower level and more
technical. That is planned for Tuesday February 23rd at 19:00 UTC on
the IRC channel ##taproot-activation.

Thanks to the meeting participants (and those who joined the
discussion on the channel prior and post the meeting) for engaging
productively and in good faith.

-- 
Michael Folkson
Email: michaelfolkson@gmail•com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3


^ permalink raw reply	[flat|nested] 42+ messages in thread

• * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
    2021-02-17 12:51 Michael Folkson
  @ 2021-02-18  5:43 ` Ariel Lorenzo-Luaces
    2021-02-18 11:01   ` Michael Folkson
    2021-02-21 16:21 ` Erik Aronesty
    1 sibling, 1 reply; 42+ messages in thread
  From: Ariel Lorenzo-Luaces @ 2021-02-18  5:43 UTC (permalink / raw)
    To: Michael Folkson, Bitcoin Protocol Discussion
  
  [-- Attachment #1: Type: text/plain, Size: 8040 bytes --]
  
  Something what strikes me about the conversation is the emotion surrounding the letters UASF.
  
  It appears as if people discuss UASF as if it's a massive tidal wave of support that is inevitable, like we saw during segwit activation. But the actual definition is "any activation that is not a MASF".
  
  A UASF can consist of a single node, ten nodes, a thousand, half of all nodes, all business' nodes, or even all the non mining nodes. On another dimension it can have zero mining support, 51% support, 49% support, or any support right up against a miner activation threshold.
  
  Hell a UASF doesn't even need code or even a single node running as long as it exists as a possibility in people's minds.
  
  The only thing a UASF doesn't have is miner support above an agreed activation threshold (some number above %51).
  
  I say this because it strikes me when people say that they are for LOT=true with the logic that since a UASF is guaranteed to happen then it's better to just make it default from the beginning. Words like coordination and safety are sometimes sprinkled into the argument.
  
  The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted into code. But in fact this isn't true and some voices in this discussion need to be more humble about what users must or must not run.
  
  Does no one realize that it is a very possible outcome that if LOT=true is released there may be only a handful of people that begin running it while everyone else delays their upgrade (with the very good reason of not getting involved in politics) and a year later those handful of people just become stuck at the moment of MUST_SIGNAL, unable to mine new blocks? Or attracting a minority of miners, activating, and forking off into a minority fork. Then a lot=false could be started that ends up activating the feature now that the stubborn option has ran its course.
  The result: a wasted year of waiting and a minority of people who didn't want to be lenient with miners by default. The chains could be called BitcoinLenient and BitcoinStubborn.
  How is that strictly safer or more coordinated?
  
  I may be in the minority, or maybe a silent majority, or maybe a majority that just hasn't considered this as a choice but honestly if there is contention about whether we're going to be stubborn or lenient with miners for Taproot and in the future then I prefer to just not activate anything at all. I'm fine for calling bitcoin ossified, accepting that segwit is Bitcoin's last network upgrade. Taproot is amazing but no new feature is worth a network split down the middle.
  
  Maybe in 10 or 20 years, when other blockchains implement features like Taproot and many more, we will become envious enough to put aside our differences on how to behave towards miners and finally activate Taproot.
  
  An activation mechanism is a consensus change like any other change, can be contentious like any other change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
  
  Cheers
  Ariel Lorenzo-Luaces
  
  
  On Feb 17, 2021, 7:05 AM, at 7:05 AM, Michael Folkson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
  >Yesterday (February 16th) we held a second meeting on Taproot
  >activation on IRC which again was open to all. Despite what appeared
  >to be majority support for LOT=false over LOT=true in the first
  >meeting I (and others) thought the arguments had not been explored in
  >depth and that we should have a follow up meeting almost entirely
  >focused on whether LOT (lockinontimeout) should be set to true or
  >false.
  >
  >The meeting was announced here:
  >https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
  >
  >In that mailing list post I outlined the arguments for LOT=true (T1 to
  >T6) and arguments for LOT=false (F1 to F6) in their strongest form I
  >could. David Harding responded with an additional argument for
  >LOT=false (F7) here:
  >https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
  >
  >These meetings are very challenging given they are open to all, you
  >don’t know who will attend and you don’t know most people’s views in
  >advance. I tried to give time for both the LOT=true arguments and the
  >LOT=false arguments to be discussed as I knew there was support for
  >both. We only tried evaluating which had more support and which had
  >more strong opposition towards the end of the meeting.
  >
  >The conversation log is here:
  >http://gnusha.org/taproot-activation/2021-02-16.log
  >
  >(If you are so inclined you can watch a video of the meeting here.
  >Thanks to the YouTube account “Bitcoin” for setting up the livestream:
  >https://www.youtube.com/watch?v=vpl5q1ovMLM)
  >
  >A summary of the meeting was provided by Luke Dashjr on Mastodon here:
  >https://bitcoinhackers.org/@lukedashjr/105742918779234566
  >
  >Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we
  >did manage to come to consensus on everything but LockinOnTimeout.
  >
  >Activation height range: 693504-745920
  >
  >MASF threshold: 1815/2016 blocks (90%)
  >
  >Keep in mind only ~100 people showed for the meetings, hardly
  >representative of the entire community.
  >
  >So, these details remain JUST a proposal for now.
  >
  >It seems inevitable that there won't be consensus on LOT.
  >
  >Everyone will have to choose for himself. :/
  >
  >Personally I agree with most of this. I agree that there wasn’t
  >overwhelming consensus for either LOT=true or LOT=false. However, from
  >my perspective there was clearly more strong opposition (what would
  >usually be deemed a NACK in Bitcoin Core review terminology) from
  >Bitcoin Core contributors, Lightning developers and other community
  >members against LOT=true than there was for LOT=false. Andrew Chow
  >tried to summarize views from the meeting in this analysis:
  >https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
  >
  >I am also aware of other current and previous Bitcoin Core
  >contributors and Lightning developers who didn’t attend the meeting in
  >person who are opposed to LOT=true. I don’t want to put them in the
  >spotlight for no reason but if you go through the conversation logs of
  >not only the meeting but the weeks of discussion prior to this meeting
  >you will see their views evaluated on the ##taproot-activation
  >channel. In addition, on taprootactivation.com some mining pools
  >expressed a preference for lot=false though I don’t know how strong
  >that preference was.
  >
  >I am only one voice but it is my current assessment that if we are to
  >attempt to finalize Taproot activation parameters and propose them to
  >the community at this time our only option is to propose LOT=false.
  >Any further delay appears to me counterproductive in our collective
  >aim to get the Taproot soft fork activated as early as possible.
  >
  >Obviously others are free to disagree with that assessment and
  >continue discussions but personally I will be attempting to avoid
  >those discussions unless prominent new information comes to light or
  >various specific individuals change their minds.
  >
  >Next week we are planning a code review of the Bitcoin Core PR #19573
  >which was initially delayed because of this LOT discussion. As I’ve
  >said previously that will be loosely following the format of the
  >Bitcoin Core PR review club and will be lower level and more
  >technical. That is planned for Tuesday February 23rd at 19:00 UTC on
  >the IRC channel ##taproot-activation.
  >
  >Thanks to the meeting participants (and those who joined the
  >discussion on the channel prior and post the meeting) for engaging
  >productively and in good faith.
  >
  >--
  >Michael Folkson
  >Email: michaelfolkson@gmail•com
  >Keybase: michaelfolkson
  >PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
  >_______________________________________________
  >bitcoin-dev mailing list
  >bitcoin-dev@lists•linuxfoundation.org
  >https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
  
  [-- Attachment #2: Type: text/html, Size: 9033 bytes --]
  
  ^ permalink raw reply	[flat|nested] 42+ messages in thread

• • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
      2021-02-18  5:43 ` Ariel Lorenzo-Luaces
    @ 2021-02-18 11:01   ` Michael Folkson
      2021-02-18 11:11     ` Samson Mow
      0 siblings, 1 reply; 42+ messages in thread
    From: Michael Folkson @ 2021-02-18 11:01 UTC (permalink / raw)
      To: Ariel Lorenzo-Luaces; +Cc: Bitcoin Protocol Discussion
    
    [-- Attachment #1: Type: text/plain, Size: 11712 bytes --]
    
    Thanks for your response Ariel. It would be useful if you responded to
    specific points I have made in the mailing list post or at least quote
    these ephemeral "people" you speak of. I don't know if you're responding to
    conversation on the IRC channel or on social media etc.
    
    > The argument comes from a naive assumption that users MUST upgrade to the
    choice that is submitted into code. But in fact this isn't true and some
    voices in this discussion need to be more humble about what users must or
    must not run.
    
    I personally have never made this assumption. Of course users aren't forced
    to run any particular software version, quite the opposite. Defaults set in
    software versions matter though as many users won't change them.
    
    > Does no one realize that it is a very possible outcome that if LOT=true
    is released there may be only a handful of people that begin running it
    while everyone else delays their upgrade (with the very good reason of not
    getting involved in politics) and a year later those handful of people just
    become stuck at the moment of MUST_SIGNAL, unable to mine new blocks?
    
    It is a possible outcome but the likely outcome is that miners activate
    Taproot before LOT is even relevant. I think it is prudent to prepare for
    the unlikely but possible outcome that miners fail to activate and hence
    have this discussion now rather than be unprepared for that eventuality. If
    LOT is set to false in a software release there is the possibility (T2 in
    https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html)
    of individuals or a proportion of the community changing LOT to true. In
    that sense setting LOT=false in a software release appears to be no more
    safe than LOT=true.
    
    > The result: a wasted year of waiting and a minority of people who didn't
    want to be lenient with miners by default.
    
    There is the (unlikely but possible) possibility of a wasted year if LOT is
    set to false and miners fail to activate. I'm not convinced by this
    perception that LOT=true is antagonistic to miners. I actually think it
    offers them clarity on what will happen over a year time period and removes
    the need for coordinated or uncoordinated community UASF efforts on top of
    LOT=false.
    
    > An activation mechanism is a consensus change like any other change, can
    be contentious like any other change, and we must resolve it like any other
    change. Otherwise we risk arriving at the darkest timeline.
    
    I don't know what you are recommending here to avoid "this darkest
    timeline". Open discussions have occurred and are continuing and in my
    mailing list post that you responded to **I recommended we propose
    LOT=false be set in protocol implementations such as Bitcoin Core**. I do
    think this apocalyptic language isn't particularly helpful. In an open
    consensus system discussion is healthy, we should prepare for bad or worst
    case scenarios in advance and doing so is not antagonistic or destructive.
    Mining pools have pledged support for Taproot but we don't build secure
    systems based on pledges of support, we build them to minimize trust in any
    human actors. We can be grateful that people like Alejandro have worked
    hard on taprootactivation.com (and this effort has informed the discussion)
    without taking pledges of support as cast iron guarantees.
    
    TL;DR It sounds like you agree with my recommendation to set LOT=false in
    protocol implementations in my email :)
    
    
    
    
    On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <arielluaces@gmail•com>
    wrote:
    
    > Something what strikes me about the conversation is the emotion
    > surrounding the letters UASF.
    >
    > It appears as if people discuss UASF as if it's a massive tidal wave of
    > support that is inevitable, like we saw during segwit activation. But the
    > actual definition is "any activation that is not a MASF".
    >
    > A UASF can consist of a single node, ten nodes, a thousand, half of all
    > nodes, all business' nodes, or even all the non mining nodes. On another
    > dimension it can have zero mining support, 51% support, 49% support, or any
    > support right up against a miner activation threshold.
    >
    > Hell a UASF doesn't even need code or even a single node running as long
    > as it exists as a possibility in people's minds.
    >
    > The only thing a UASF doesn't have is miner support above an agreed
    > activation threshold (some number above %51).
    >
    > I say this because it strikes me when people say that they are for
    > LOT=true with the logic that since a UASF is guaranteed to happen then it's
    > better to just make it default from the beginning. Words like coordination
    > and safety are sometimes sprinkled into the argument.
    >
    > The argument comes from a naive assumption that users MUST upgrade to the
    > choice that is submitted into code. But in fact this isn't true and some
    > voices in this discussion need to be more humble about what users must or
    > must not run.
    >
    > Does no one realize that it is a very possible outcome that if LOT=true is
    > released there may be only a handful of people that begin running it while
    > everyone else delays their upgrade (with the very good reason of not
    > getting involved in politics) and a year later those handful of people just
    > become stuck at the moment of MUST_SIGNAL, unable to mine new blocks? Or
    > attracting a minority of miners, activating, and forking off into a
    > minority fork. Then a lot=false could be started that ends up activating
    > the feature now that the stubborn option has ran its course.
    > The result: a wasted year of waiting and a minority of people who didn't
    > want to be lenient with miners by default. The chains could be called
    > BitcoinLenient and BitcoinStubborn.
    > How is that strictly safer or more coordinated?
    >
    > I may be in the minority, or maybe a silent majority, or maybe a majority
    > that just hasn't considered this as a choice but honestly if there is
    > contention about whether we're going to be stubborn or lenient with miners
    > for Taproot and in the future then I prefer to just not activate anything
    > at all. I'm fine for calling bitcoin ossified, accepting that segwit is
    > Bitcoin's last network upgrade. Taproot is amazing but no new feature is
    > worth a network split down the middle.
    >
    > Maybe in 10 or 20 years, when other blockchains implement features like
    > Taproot and many more, we will become envious enough to put aside our
    > differences on how to behave towards miners and finally activate Taproot.
    >
    > An activation mechanism is a consensus change like any other change, can
    > be contentious like any other change, and we must resolve it like any other
    > change. Otherwise we risk arriving at the darkest timeline.
    >
    > Cheers
    > Ariel Lorenzo-Luaces
    > On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev <
    > bitcoin-dev@lists•linuxfoundation.org> wrote:
    >>
    >> Yesterday (February 16th) we held a second meeting on Taproot
    >> activation on IRC which again was open to all. Despite what appeared
    >> to be majority support for LOT=false over LOT=true in the first
    >> meeting I (and others) thought the arguments had not been explored in
    >> depth and that we should have a follow up meeting almost entirely
    >> focused on whether LOT (lockinontimeout) should be set to true or
    >> false.
    >>
    >> The meeting was announced here:
    >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
    >>
    >> In that mailing list post I outlined the arguments for LOT=true (T1 to
    >> T6) and arguments for LOT=false (F1 to F6) in their strongest form I
    >> could. David Harding responded with an additional argument for
    >> LOT=false (F7) here:
    >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
    >>
    >> These meetings are very challenging given they are open to all, you
    >> don’t know who will attend and you don’t know most people’s views in
    >> advance. I tried to give time for both the LOT=true arguments and the
    >> LOT=false arguments to be discussed as I knew there was support for
    >> both. We only tried evaluating which had more support and which had
    >> more strong opposition towards the end of the meeting.
    >>
    >> The conversation log is here:
    >> http://gnusha.org/taproot-activation/2021-02-16.log
    >>
    >> (If you are so inclined you can watch a video of the meeting here.
    >> Thanks to the YouTube account “Bitcoin” for setting up the livestream:
    >> https://www.youtube.com/watch?v=vpl5q1ovMLM)
    >>
    >> A summary of the meeting was provided by Luke Dashjr on Mastodon here:
    >> https://bitcoinhackers.org/@lukedashjr/105742918779234566
    >>
    >> Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we
    >> did manage to come to consensus on everything but LockinOnTimeout.
    >>
    >> Activation height range: 693504-745920
    >>
    >> MASF threshold: 1815/2016 blocks (90%)
    >>
    >> Keep in mind only ~100 people showed for the meetings, hardly
    >> representative of the entire community.
    >>
    >> So, these details remain JUST a proposal for now.
    >>
    >> It seems inevitable that there won't be consensus on LOT.
    >>
    >> Everyone will have to choose for himself. :/
    >>
    >> Personally I agree with most of this. I agree that there wasn’t
    >> overwhelming consensus for either LOT=true or LOT=false. However, from
    >> my perspective there was clearly more strong opposition (what would
    >> usually be deemed a NACK in Bitcoin Core review terminology) from
    >> Bitcoin Core contributors, Lightning developers and other community
    >> members against LOT=true than there was for LOT=false. Andrew Chow
    >> tried to summarize views from the meeting in this analysis:
    >> https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
    >>
    >> I am also aware of other current and previous Bitcoin Core
    >> contributors and Lightning developers who didn’t attend the meeting in
    >> person who are opposed to LOT=true. I don’t want to put them in the
    >> spotlight for no reason but if you go through the conversation logs of
    >> not only the meeting but the weeks of discussion prior to this meeting
    >> you will see their views evaluated on the ##taproot-activation
    >> channel. In addition, on taprootactivation.com some mining pools
    >> expressed a preference for lot=false though I don’t know how strong
    >> that preference was.
    >>
    >> I am only one voice but it is my current assessment that if we are to
    >> attempt to finalize Taproot activation parameters and propose them to
    >> the community at this time our only option is to propose LOT=false.
    >> Any further delay appears to me counterproductive in our collective
    >> aim to get the Taproot soft fork activated as early as possible.
    >>
    >> Obviously others are free to disagree with that assessment and
    >> continue discussions but personally I will be attempting to avoid
    >> those discussions unless prominent new information comes to light or
    >> various specific individuals change their minds.
    >>
    >> Next week we are planning a code review of the Bitcoin Core PR #19573
    >> which was initially delayed because of this LOT discussion. As I’ve
    >> said previously that will be loosely following the format of the
    >> Bitcoin Core PR review club and will be lower level and more
    >> technical. That is planned for Tuesday February 23rd at 19:00 UTC on
    >> the IRC channel ##taproot-activation.
    >>
    >> Thanks to the meeting participants (and those who joined the
    >> discussion on the channel prior and post the meeting) for engaging
    >> productively and in good faith.
    >>
    >>
    
    -- 
    Michael Folkson
    Email: michaelfolkson@gmail•com
    Keybase: michaelfolkson
    PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
    
    [-- Attachment #2: Type: text/html, Size: 14120 bytes --]
    
    ^ permalink raw reply	[flat|nested] 42+ messages in thread

  • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
        2021-02-18 11:01   ` Michael Folkson
      @ 2021-02-18 11:11     ` Samson Mow
        2021-02-18 11:52       ` ZmnSCPxj
        0 siblings, 1 reply; 42+ messages in thread
      From: Samson Mow @ 2021-02-18 11:11 UTC (permalink / raw)
        To: Michael Folkson, Bitcoin Protocol Discussion
      
      [-- Attachment #1: Type: text/plain, Size: 12581 bytes --]
      
       "An activation mechanism is a consensus change like any other change, can
      be contentious like any other change, and we must resolve it like any other
      change. Otherwise we risk arriving at the darkest timeline."
      
      Who's we here?
      
      Release both and let the network decide.
      
      
      On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <
      bitcoin-dev@lists•linuxfoundation.org> wrote:
      
      > Thanks for your response Ariel. It would be useful if you responded to
      > specific points I have made in the mailing list post or at least quote
      > these ephemeral "people" you speak of. I don't know if you're responding to
      > conversation on the IRC channel or on social media etc.
      >
      > > The argument comes from a naive assumption that users MUST upgrade to
      > the choice that is submitted into code. But in fact this isn't true and
      > some voices in this discussion need to be more humble about what users must
      > or must not run.
      >
      > I personally have never made this assumption. Of course users aren't
      > forced to run any particular software version, quite the opposite. Defaults
      > set in software versions matter though as many users won't change them.
      >
      > > Does no one realize that it is a very possible outcome that if LOT=true
      > is released there may be only a handful of people that begin running it
      > while everyone else delays their upgrade (with the very good reason of not
      > getting involved in politics) and a year later those handful of people just
      > become stuck at the moment of MUST_SIGNAL, unable to mine new blocks?
      >
      > It is a possible outcome but the likely outcome is that miners activate
      > Taproot before LOT is even relevant. I think it is prudent to prepare for
      > the unlikely but possible outcome that miners fail to activate and hence
      > have this discussion now rather than be unprepared for that eventuality. If
      > LOT is set to false in a software release there is the possibility (T2 in
      > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html)
      > of individuals or a proportion of the community changing LOT to true. In
      > that sense setting LOT=false in a software release appears to be no more
      > safe than LOT=true.
      >
      > > The result: a wasted year of waiting and a minority of people who didn't
      > want to be lenient with miners by default.
      >
      > There is the (unlikely but possible) possibility of a wasted year if LOT
      > is set to false and miners fail to activate. I'm not convinced by this
      > perception that LOT=true is antagonistic to miners. I actually think it
      > offers them clarity on what will happen over a year time period and removes
      > the need for coordinated or uncoordinated community UASF efforts on top of
      > LOT=false.
      >
      > > An activation mechanism is a consensus change like any other change, can
      > be contentious like any other change, and we must resolve it like any other
      > change. Otherwise we risk arriving at the darkest timeline.
      >
      > I don't know what you are recommending here to avoid "this darkest
      > timeline". Open discussions have occurred and are continuing and in my
      > mailing list post that you responded to **I recommended we propose
      > LOT=false be set in protocol implementations such as Bitcoin Core**. I do
      > think this apocalyptic language isn't particularly helpful. In an open
      > consensus system discussion is healthy, we should prepare for bad or worst
      > case scenarios in advance and doing so is not antagonistic or destructive.
      > Mining pools have pledged support for Taproot but we don't build secure
      > systems based on pledges of support, we build them to minimize trust in any
      > human actors. We can be grateful that people like Alejandro have worked
      > hard on taprootactivation.com (and this effort has informed the
      > discussion) without taking pledges of support as cast iron guarantees.
      >
      > TL;DR It sounds like you agree with my recommendation to set LOT=false in
      > protocol implementations in my email :)
      >
      >
      >
      >
      > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <
      > arielluaces@gmail•com> wrote:
      >
      >> Something what strikes me about the conversation is the emotion
      >> surrounding the letters UASF.
      >>
      >> It appears as if people discuss UASF as if it's a massive tidal wave of
      >> support that is inevitable, like we saw during segwit activation. But the
      >> actual definition is "any activation that is not a MASF".
      >>
      >> A UASF can consist of a single node, ten nodes, a thousand, half of all
      >> nodes, all business' nodes, or even all the non mining nodes. On another
      >> dimension it can have zero mining support, 51% support, 49% support, or any
      >> support right up against a miner activation threshold.
      >>
      >> Hell a UASF doesn't even need code or even a single node running as long
      >> as it exists as a possibility in people's minds.
      >>
      >> The only thing a UASF doesn't have is miner support above an agreed
      >> activation threshold (some number above %51).
      >>
      >> I say this because it strikes me when people say that they are for
      >> LOT=true with the logic that since a UASF is guaranteed to happen then it's
      >> better to just make it default from the beginning. Words like coordination
      >> and safety are sometimes sprinkled into the argument.
      >>
      >> The argument comes from a naive assumption that users MUST upgrade to the
      >> choice that is submitted into code. But in fact this isn't true and some
      >> voices in this discussion need to be more humble about what users must or
      >> must not run.
      >>
      >> Does no one realize that it is a very possible outcome that if LOT=true
      >> is released there may be only a handful of people that begin running it
      >> while everyone else delays their upgrade (with the very good reason of not
      >> getting involved in politics) and a year later those handful of people just
      >> become stuck at the moment of MUST_SIGNAL, unable to mine new blocks? Or
      >> attracting a minority of miners, activating, and forking off into a
      >> minority fork. Then a lot=false could be started that ends up activating
      >> the feature now that the stubborn option has ran its course.
      >> The result: a wasted year of waiting and a minority of people who didn't
      >> want to be lenient with miners by default. The chains could be called
      >> BitcoinLenient and BitcoinStubborn.
      >> How is that strictly safer or more coordinated?
      >>
      >> I may be in the minority, or maybe a silent majority, or maybe a majority
      >> that just hasn't considered this as a choice but honestly if there is
      >> contention about whether we're going to be stubborn or lenient with miners
      >> for Taproot and in the future then I prefer to just not activate anything
      >> at all. I'm fine for calling bitcoin ossified, accepting that segwit is
      >> Bitcoin's last network upgrade. Taproot is amazing but no new feature is
      >> worth a network split down the middle.
      >>
      >> Maybe in 10 or 20 years, when other blockchains implement features like
      >> Taproot and many more, we will become envious enough to put aside our
      >> differences on how to behave towards miners and finally activate Taproot.
      >>
      >> An activation mechanism is a consensus change like any other change, can
      >> be contentious like any other change, and we must resolve it like any other
      >> change. Otherwise we risk arriving at the darkest timeline.
      >>
      >> Cheers
      >> Ariel Lorenzo-Luaces
      >> On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev <
      >> bitcoin-dev@lists•linuxfoundation.org> wrote:
      >>>
      >>> Yesterday (February 16th) we held a second meeting on Taproot
      >>> activation on IRC which again was open to all. Despite what appeared
      >>> to be majority support for LOT=false over LOT=true in the first
      >>> meeting I (and others) thought the arguments had not been explored in
      >>> depth and that we should have a follow up meeting almost entirely
      >>> focused on whether LOT (lockinontimeout) should be set to true or
      >>> false.
      >>>
      >>> The meeting was announced here:
      >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
      >>>
      >>> In that mailing list post I outlined the arguments for LOT=true (T1 to
      >>> T6) and arguments for LOT=false (F1 to F6) in their strongest form I
      >>> could. David Harding responded with an additional argument for
      >>> LOT=false (F7) here:
      >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
      >>>
      >>> These meetings are very challenging given they are open to all, you
      >>> don’t know who will attend and you don’t know most people’s views in
      >>> advance. I tried to give time for both the LOT=true arguments and the
      >>> LOT=false arguments to be discussed as I knew there was support for
      >>> both. We only tried evaluating which had more support and which had
      >>> more strong opposition towards the end of the meeting.
      >>>
      >>> The conversation log is here:
      >>> http://gnusha.org/taproot-activation/2021-02-16.log
      >>>
      >>> (If you are so inclined you can watch a video of the meeting here.
      >>> Thanks to the YouTube account “Bitcoin” for setting up the livestream:
      >>> https://www.youtube.com/watch?v=vpl5q1ovMLM)
      >>>
      >>> A summary of the meeting was provided by Luke Dashjr on Mastodon here:
      >>> https://bitcoinhackers.org/@lukedashjr/105742918779234566
      >>>
      >>> Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we
      >>> did manage to come to consensus on everything but LockinOnTimeout.
      >>>
      >>> Activation height range: 693504-745920
      >>>
      >>> MASF threshold: 1815/2016 blocks (90%)
      >>>
      >>> Keep in mind only ~100 people showed for the meetings, hardly
      >>> representative of the entire community.
      >>>
      >>> So, these details remain JUST a proposal for now.
      >>>
      >>> It seems inevitable that there won't be consensus on LOT.
      >>>
      >>> Everyone will have to choose for himself. :/
      >>>
      >>> Personally I agree with most of this. I agree that there wasn’t
      >>> overwhelming consensus for either LOT=true or LOT=false. However, from
      >>> my perspective there was clearly more strong opposition (what would
      >>> usually be deemed a NACK in Bitcoin Core review terminology) from
      >>> Bitcoin Core contributors, Lightning developers and other community
      >>> members against LOT=true than there was for LOT=false. Andrew Chow
      >>> tried to summarize views from the meeting in this analysis:
      >>> https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
      >>>
      >>> I am also aware of other current and previous Bitcoin Core
      >>> contributors and Lightning developers who didn’t attend the meeting in
      >>> person who are opposed to LOT=true. I don’t want to put them in the
      >>> spotlight for no reason but if you go through the conversation logs of
      >>> not only the meeting but the weeks of discussion prior to this meeting
      >>> you will see their views evaluated on the ##taproot-activation
      >>> channel. In addition, on taprootactivation.com some mining pools
      >>> expressed a preference for lot=false though I don’t know how strong
      >>> that preference was.
      >>>
      >>> I am only one voice but it is my current assessment that if we are to
      >>> attempt to finalize Taproot activation parameters and propose them to
      >>> the community at this time our only option is to propose LOT=false.
      >>> Any further delay appears to me counterproductive in our collective
      >>> aim to get the Taproot soft fork activated as early as possible.
      >>>
      >>> Obviously others are free to disagree with that assessment and
      >>> continue discussions but personally I will be attempting to avoid
      >>> those discussions unless prominent new information comes to light or
      >>> various specific individuals change their minds.
      >>>
      >>> Next week we are planning a code review of the Bitcoin Core PR #19573
      >>> which was initially delayed because of this LOT discussion. As I’ve
      >>> said previously that will be loosely following the format of the
      >>> Bitcoin Core PR review club and will be lower level and more
      >>> technical. That is planned for Tuesday February 23rd at 19:00 UTC on
      >>> the IRC channel ##taproot-activation.
      >>>
      >>> Thanks to the meeting participants (and those who joined the
      >>> discussion on the channel prior and post the meeting) for engaging
      >>> productively and in good faith.
      >>>
      >>>
      >
      > --
      > Michael Folkson
      > Email: michaelfolkson@gmail•com
      > Keybase: michaelfolkson
      > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
      > _______________________________________________
      > bitcoin-dev mailing list
      > bitcoin-dev@lists•linuxfoundation.org
      > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
      >
      
      [-- Attachment #2: Type: text/html, Size: 15284 bytes --]
      
      ^ permalink raw reply	[flat|nested] 42+ messages in thread

    • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
          2021-02-18 11:11     ` Samson Mow
        @ 2021-02-18 11:52       ` ZmnSCPxj
          2021-02-18 12:20         ` Michael Folkson
          2021-02-18 13:59         ` Matt Corallo
          0 siblings, 2 replies; 42+ messages in thread
        From: ZmnSCPxj @ 2021-02-18 11:52 UTC (permalink / raw)
          To: Samson Mow, Bitcoin Protocol Discussion; +Cc: Michael Folkson
        
        Good morning all,
        
        > "An activation mechanism is a consensus change like any other change, can be contentious like any other change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline."
        >
        > Who's we here?
        >
        > Release both and let the network decide.
        
        A thing that could be done, without mandating either LOT=true or LOT=false, would be to have a release that requires a `taprootlot=1` or `taprootlot=0` and refuses to start if the parameter is not set.
        
        This assures everyone that neither choice is being forced on users, and instead what is being forced on users, is for users to make that choice themselves.
        
        Regards,
        ZmnSCPxj
        
        >
        > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
        >
        > > Thanks for your response Ariel. It would be useful if you responded to specific points I have made in the mailing list post or at least quote these ephemeral "people" you speak of. I don't know if you're responding to conversation on the IRC channel or on social media etc.
        > >
        > > > The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted into code. But in fact this isn't true and some voices in this discussion need to be more humble about what users must or must not run.
        > >
        > > I personally have never made this assumption. Of course users aren't forced to run any particular software version, quite the opposite. Defaults set in software versions matter though as many users won't change them.
        > >
        > > > Does no one realize that it is a very possible outcome that if LOT=true is released there may be only a handful of people that begin running it while everyone else delays their upgrade (with the very good reason of not getting involved in politics) and a year later those handful of people just become stuck at the moment of MUST_SIGNAL, unable to mine new blocks?
        > >
        > > It is a possible outcome but the likely outcome is that miners activate Taproot before LOT is even relevant. I think it is prudent to prepare for the unlikely but possible outcome that miners fail to activate and hence have this discussion now rather than be unprepared for that eventuality. If LOT is set to false in a software release there is the possibility (T2 in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html) of individuals or a proportion of the community changing LOT to true. In that sense setting LOT=false in a software release appears to be no more safe than LOT=true.
        > >
        > > > The result: a wasted year of waiting and a minority of people who didn't want to be lenient with miners by default.
        > >
        > > There is the (unlikely but possible) possibility of a wasted year if LOT is set to false and miners fail to activate. I'm not convinced by this perception that LOT=true is antagonistic to miners. I actually think it offers them clarity on what will happen over a year time period and removes the need for coordinated or uncoordinated community UASF efforts on top of LOT=false.
        > >
        > > > An activation mechanism is a consensus change like any other change, can be contentious like any other change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
        > >
        > > I don't know what you are recommending here to avoid "this darkest timeline". Open discussions have occurred and are continuing and in my mailing list post that you responded to **I recommended we propose LOT=false be set in protocol implementations such as Bitcoin Core**. I do think this apocalyptic language isn't particularly helpful. In an open consensus system discussion is healthy, we should prepare for bad or worst case scenarios in advance and doing so is not antagonistic or destructive. Mining pools have pledged support for Taproot but we don't build secure systems based on pledges of support, we build them to minimize trust in any human actors. We can be grateful that people like Alejandro have worked hard on taprootactivation.com (and this effort has informed the discussion) without taking pledges of support as cast iron guarantees.
        > >
        > > TL;DR It sounds like you agree with my recommendation to set LOT=false in protocol implementations in my email :)
        > >
        > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <arielluaces@gmail•com> wrote:
        > >
        > > > Something what strikes me about the conversation is the emotion surrounding the letters UASF.
        > > > It appears as if people discuss UASF as if it's a massive tidal wave of support that is inevitable, like we saw during segwit activation. But the actual definition is "any activation that is not a MASF".
        > > > A UASF can consist of a single node, ten nodes, a thousand, half of all nodes, all business' nodes, or even all the non mining nodes. On another dimension it can have zero mining support, 51% support, 49% support, or any support right up against a miner activation threshold.
        > > > Hell a UASF doesn't even need code or even a single node running as long as it exists as a possibility in people's minds.
        > > > The only thing a UASF doesn't have is miner support above an agreed activation threshold (some number above %51).
        > > > I say this because it strikes me when people say that they are for LOT=true with the logic that since a UASF is guaranteed to happen then it's better to just make it default from the beginning. Words like coordination and safety are sometimes sprinkled into the argument.
        > > > The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted into code. But in fact this isn't true and some voices in this discussion need to be more humble about what users must or must not run.
        > > > Does no one realize that it is a very possible outcome that if LOT=true is released there may be only a handful of people that begin running it while everyone else delays their upgrade (with the very good reason of not getting involved in politics) and a year later those handful of people just become stuck at the moment of MUST_SIGNAL, unable to mine new blocks? Or attracting a minority of miners, activating, and forking off into a minority fork. Then a lot=false could be started that ends up activating the feature now that the stubborn option has ran its course.
        > > > The result: a wasted year of waiting and a minority of people who didn't want to be lenient with miners by default. The chains could be called BitcoinLenient and BitcoinStubborn.
        > > > How is that strictly safer or more coordinated?
        > > > I may be in the minority, or maybe a silent majority, or maybe a majority that just hasn't considered this as a choice but honestly if there is contention about whether we're going to be stubborn or lenient with miners for Taproot and in the future then I prefer to just not activate anything at all. I'm fine for calling bitcoin ossified, accepting that segwit is Bitcoin's last network upgrade. Taproot is amazing but no new feature is worth a network split down the middle.
        > > > Maybe in 10 or 20 years, when other blockchains implement features like Taproot and many more, we will become envious enough to put aside our differences on how to behave towards miners and finally activate Taproot.
        > > > An activation mechanism is a consensus change like any other change, can be contentious like any other change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
        > > > Cheers
        > > > Ariel Lorenzo-Luaces
        > > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
        > > >
        > > > > Yesterday (February 16th) we held a second meeting on Taproot
        > > > > activation on IRC which again was open to all. Despite what appeared
        > > > > to be majority support for LOT=false over LOT=true in the first
        > > > > meeting I (and others) thought the arguments had not been explored in
        > > > > depth and that we should have a follow up meeting almost entirely
        > > > > focused on whether LOT (lockinontimeout) should be set to true or
        > > > > false.
        > > > >
        > > > > The meeting was announced here:
        > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
        > > > >
        > > > > In that mailing list post I outlined the arguments for LOT=true (T1 to
        > > > > T6) and arguments for LOT=false (F1 to F6) in their strongest form I
        > > > > could. David Harding responded with an additional argument for
        > > > > LOT=false (F7) here:
        > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
        > > > >
        > > > > These meetings are very challenging given they are open to all, you
        > > > > don’t know who will attend and you don’t know most people’s views in
        > > > > advance. I tried to give time for both the LOT=true arguments and the
        > > > > LOT=false arguments to be discussed as I knew there was support for
        > > > > both. We only tried evaluating which had more support and which had
        > > > > more strong opposition towards the end of the meeting.
        > > > >
        > > > > The conversation log is here:
        > > > > http://gnusha.org/taproot-activation/2021-02-16.log
        > > > >
        > > > > (If you are so inclined you can watch a video of the meeting here.
        > > > > Thanks to the YouTube account “Bitcoin” for setting up the livestream:
        > > > > https://www.youtube.com/watch?v=vpl5q1ovMLM)
        > > > >
        > > > > A summary of the meeting was provided by Luke Dashjr on Mastodon here:
        > > > > https://bitcoinhackers.org/@lukedashjr/105742918779234566
        > > > >
        > > > > Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we
        > > > > did manage to come to consensus on everything but LockinOnTimeout.
        > > > >
        > > > > Activation height range: 693504-745920
        > > > >
        > > > > MASF threshold: 1815/2016 blocks (90%)
        > > > >
        > > > > Keep in mind only ~100 people showed for the meetings, hardly
        > > > > representative of the entire community.
        > > > >
        > > > > So, these details remain JUST a proposal for now.
        > > > >
        > > > > It seems inevitable that there won't be consensus on LOT.
        > > > >
        > > > > Everyone will have to choose for himself. :/
        > > > >
        > > > > Personally I agree with most of this. I agree that there wasn’t
        > > > > overwhelming consensus for either LOT=true or LOT=false. However, from
        > > > > my perspective there was clearly more strong opposition (what would
        > > > > usually be deemed a NACK in Bitcoin Core review terminology) from
        > > > > Bitcoin Core contributors, Lightning developers and other community
        > > > > members against LOT=true than there was for LOT=false. Andrew Chow
        > > > > tried to summarize views from the meeting in this analysis:
        > > > > https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
        > > > >
        > > > > I am also aware of other current and previous Bitcoin Core
        > > > > contributors and Lightning developers who didn’t attend the meeting in
        > > > > person who are opposed to LOT=true. I don’t want to put them in the
        > > > > spotlight for no reason but if you go through the conversation logs of
        > > > > not only the meeting but the weeks of discussion prior to this meeting
        > > > > you will see their views evaluated on the ##taproot-activation
        > > > > channel. In addition, on taprootactivation.com some mining pools
        > > > > expressed a preference for lot=false though I don’t know how strong
        > > > > that preference was.
        > > > >
        > > > > I am only one voice but it is my current assessment that if we are to
        > > > > attempt to finalize Taproot activation parameters and propose them to
        > > > > the community at this time our only option is to propose LOT=false.
        > > > > Any further delay appears to me counterproductive in our collective
        > > > > aim to get the Taproot soft fork activated as early as possible.
        > > > >
        > > > > Obviously others are free to disagree with that assessment and
        > > > > continue discussions but personally I will be attempting to avoid
        > > > > those discussions unless prominent new information comes to light or
        > > > > various specific individuals change their minds.
        > > > >
        > > > > Next week we are planning a code review of the Bitcoin Core PR #19573
        > > > > which was initially delayed because of this LOT discussion. As I’ve
        > > > > said previously that will be loosely following the format of the
        > > > > Bitcoin Core PR review club and will be lower level and more
        > > > > technical. That is planned for Tuesday February 23rd at 19:00 UTC on
        > > > > the IRC channel ##taproot-activation.
        > > > >
        > > > > Thanks to the meeting participants (and those who joined the
        > > > > discussion on the channel prior and post the meeting) for engaging
        > > > > productively and in good faith.
        > >
        > > --
        > > Michael Folkson
        > > Email: michaelfolkson@gmail•com
        > > Keybase: michaelfolkson
        > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
        > > _______________________________________________
        > > bitcoin-dev mailing list
        > > bitcoin-dev@lists•linuxfoundation.org
        > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
        
        
        
        
        ^ permalink raw reply	[flat|nested] 42+ messages in thread

      • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
            2021-02-18 11:52       ` ZmnSCPxj
          @ 2021-02-18 12:20         ` Michael Folkson
            2021-02-18 14:01           ` Matt Corallo
            2021-02-18 13:59         ` Matt Corallo
            1 sibling, 1 reply; 42+ messages in thread
          From: Michael Folkson @ 2021-02-18 12:20 UTC (permalink / raw)
            To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
          
          [-- Attachment #1: Type: text/plain, Size: 14534 bytes --]
          
          Right, that is one option. Personally I would prefer a Bitcoin Core release
          sets LOT=false (based on what I have heard from Bitcoin Core contributors)
          and a community effort releases a version with LOT=true. I don't think
          users should be forced to choose something they may have no context on
          before they are allowed to use Bitcoin Core.
          
          My current understanding is that roasbeef is planning to set LOT=false on
          btcd (an alternative protocol implementation to Bitcoin Core) and Luke
          Dashjr hasn't yet decided on Bitcoin Knots.
          
          
          
          On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
          
          > Good morning all,
          >
          > > "An activation mechanism is a consensus change like any other change,
          > can be contentious like any other change, and we must resolve it like any
          > other change. Otherwise we risk arriving at the darkest timeline."
          > >
          > > Who's we here?
          > >
          > > Release both and let the network decide.
          >
          > A thing that could be done, without mandating either LOT=true or
          > LOT=false, would be to have a release that requires a `taprootlot=1` or
          > `taprootlot=0` and refuses to start if the parameter is not set.
          >
          > This assures everyone that neither choice is being forced on users, and
          > instead what is being forced on users, is for users to make that choice
          > themselves.
          >
          > Regards,
          > ZmnSCPxj
          >
          > >
          > > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <
          > bitcoin-dev@lists•linuxfoundation.org> wrote:
          > >
          > > > Thanks for your response Ariel. It would be useful if you responded to
          > specific points I have made in the mailing list post or at least quote
          > these ephemeral "people" you speak of. I don't know if you're responding to
          > conversation on the IRC channel or on social media etc.
          > > >
          > > > > The argument comes from a naive assumption that users MUST upgrade
          > to the choice that is submitted into code. But in fact this isn't true and
          > some voices in this discussion need to be more humble about what users must
          > or must not run.
          > > >
          > > > I personally have never made this assumption. Of course users aren't
          > forced to run any particular software version, quite the opposite. Defaults
          > set in software versions matter though as many users won't change them.
          > > >
          > > > > Does no one realize that it is a very possible outcome that if
          > LOT=true is released there may be only a handful of people that begin
          > running it while everyone else delays their upgrade (with the very good
          > reason of not getting involved in politics) and a year later those handful
          > of people just become stuck at the moment of MUST_SIGNAL, unable to mine
          > new blocks?
          > > >
          > > > It is a possible outcome but the likely outcome is that miners
          > activate Taproot before LOT is even relevant. I think it is prudent to
          > prepare for the unlikely but possible outcome that miners fail to activate
          > and hence have this discussion now rather than be unprepared for that
          > eventuality. If LOT is set to false in a software release there is the
          > possibility (T2 in
          > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html)
          > of individuals or a proportion of the community changing LOT to true. In
          > that sense setting LOT=false in a software release appears to be no more
          > safe than LOT=true.
          > > >
          > > > > The result: a wasted year of waiting and a minority of people who
          > didn't want to be lenient with miners by default.
          > > >
          > > > There is the (unlikely but possible) possibility of a wasted year if
          > LOT is set to false and miners fail to activate. I'm not convinced by this
          > perception that LOT=true is antagonistic to miners. I actually think it
          > offers them clarity on what will happen over a year time period and removes
          > the need for coordinated or uncoordinated community UASF efforts on top of
          > LOT=false.
          > > >
          > > > > An activation mechanism is a consensus change like any other change,
          > can be contentious like any other change, and we must resolve it like any
          > other change. Otherwise we risk arriving at the darkest timeline.
          > > >
          > > > I don't know what you are recommending here to avoid "this darkest
          > timeline". Open discussions have occurred and are continuing and in my
          > mailing list post that you responded to **I recommended we propose
          > LOT=false be set in protocol implementations such as Bitcoin Core**. I do
          > think this apocalyptic language isn't particularly helpful. In an open
          > consensus system discussion is healthy, we should prepare for bad or worst
          > case scenarios in advance and doing so is not antagonistic or destructive.
          > Mining pools have pledged support for Taproot but we don't build secure
          > systems based on pledges of support, we build them to minimize trust in any
          > human actors. We can be grateful that people like Alejandro have worked
          > hard on taprootactivation.com (and this effort has informed the
          > discussion) without taking pledges of support as cast iron guarantees.
          > > >
          > > > TL;DR It sounds like you agree with my recommendation to set LOT=false
          > in protocol implementations in my email :)
          > > >
          > > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <
          > arielluaces@gmail•com> wrote:
          > > >
          > > > > Something what strikes me about the conversation is the emotion
          > surrounding the letters UASF.
          > > > > It appears as if people discuss UASF as if it's a massive tidal wave
          > of support that is inevitable, like we saw during segwit activation. But
          > the actual definition is "any activation that is not a MASF".
          > > > > A UASF can consist of a single node, ten nodes, a thousand, half of
          > all nodes, all business' nodes, or even all the non mining nodes. On
          > another dimension it can have zero mining support, 51% support, 49%
          > support, or any support right up against a miner activation threshold.
          > > > > Hell a UASF doesn't even need code or even a single node running as
          > long as it exists as a possibility in people's minds.
          > > > > The only thing a UASF doesn't have is miner support above an agreed
          > activation threshold (some number above %51).
          > > > > I say this because it strikes me when people say that they are for
          > LOT=true with the logic that since a UASF is guaranteed to happen then it's
          > better to just make it default from the beginning. Words like coordination
          > and safety are sometimes sprinkled into the argument.
          > > > > The argument comes from a naive assumption that users MUST upgrade
          > to the choice that is submitted into code. But in fact this isn't true and
          > some voices in this discussion need to be more humble about what users must
          > or must not run.
          > > > > Does no one realize that it is a very possible outcome that if
          > LOT=true is released there may be only a handful of people that begin
          > running it while everyone else delays their upgrade (with the very good
          > reason of not getting involved in politics) and a year later those handful
          > of people just become stuck at the moment of MUST_SIGNAL, unable to mine
          > new blocks? Or attracting a minority of miners, activating, and forking off
          > into a minority fork. Then a lot=false could be started that ends up
          > activating the feature now that the stubborn option has ran its course.
          > > > > The result: a wasted year of waiting and a minority of people who
          > didn't want to be lenient with miners by default. The chains could be
          > called BitcoinLenient and BitcoinStubborn.
          > > > > How is that strictly safer or more coordinated?
          > > > > I may be in the minority, or maybe a silent majority, or maybe a
          > majority that just hasn't considered this as a choice but honestly if there
          > is contention about whether we're going to be stubborn or lenient with
          > miners for Taproot and in the future then I prefer to just not activate
          > anything at all. I'm fine for calling bitcoin ossified, accepting that
          > segwit is Bitcoin's last network upgrade. Taproot is amazing but no new
          > feature is worth a network split down the middle.
          > > > > Maybe in 10 or 20 years, when other blockchains implement features
          > like Taproot and many more, we will become envious enough to put aside our
          > differences on how to behave towards miners and finally activate Taproot.
          > > > > An activation mechanism is a consensus change like any other change,
          > can be contentious like any other change, and we must resolve it like any
          > other change. Otherwise we risk arriving at the darkest timeline.
          > > > > Cheers
          > > > > Ariel Lorenzo-Luaces
          > > > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev <
          > bitcoin-dev@lists•linuxfoundation.org> wrote:
          > > > >
          > > > > > Yesterday (February 16th) we held a second meeting on Taproot
          > > > > > activation on IRC which again was open to all. Despite what
          > appeared
          > > > > > to be majority support for LOT=false over LOT=true in the first
          > > > > > meeting I (and others) thought the arguments had not been explored
          > in
          > > > > > depth and that we should have a follow up meeting almost entirely
          > > > > > focused on whether LOT (lockinontimeout) should be set to true or
          > > > > > false.
          > > > > >
          > > > > > The meeting was announced here:
          > > > > >
          > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
          > > > > >
          > > > > > In that mailing list post I outlined the arguments for LOT=true
          > (T1 to
          > > > > > T6) and arguments for LOT=false (F1 to F6) in their strongest form
          > I
          > > > > > could. David Harding responded with an additional argument for
          > > > > > LOT=false (F7) here:
          > > > > >
          > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
          > > > > >
          > > > > > These meetings are very challenging given they are open to all, you
          > > > > > don’t know who will attend and you don’t know most people’s views
          > in
          > > > > > advance. I tried to give time for both the LOT=true arguments and
          > the
          > > > > > LOT=false arguments to be discussed as I knew there was support for
          > > > > > both. We only tried evaluating which had more support and which had
          > > > > > more strong opposition towards the end of the meeting.
          > > > > >
          > > > > > The conversation log is here:
          > > > > > http://gnusha.org/taproot-activation/2021-02-16.log
          > > > > >
          > > > > > (If you are so inclined you can watch a video of the meeting here.
          > > > > > Thanks to the YouTube account “Bitcoin” for setting up the
          > livestream:
          > > > > > https://www.youtube.com/watch?v=vpl5q1ovMLM)
          > > > > >
          > > > > > A summary of the meeting was provided by Luke Dashjr on Mastodon
          > here:
          > > > > > https://bitcoinhackers.org/@lukedashjr/105742918779234566
          > > > > >
          > > > > > Today's #Bitcoin #Taproot meeting was IMO largely unproductive,
          > but we
          > > > > > did manage to come to consensus on everything but LockinOnTimeout.
          > > > > >
          > > > > > Activation height range: 693504-745920
          > > > > >
          > > > > > MASF threshold: 1815/2016 blocks (90%)
          > > > > >
          > > > > > Keep in mind only ~100 people showed for the meetings, hardly
          > > > > > representative of the entire community.
          > > > > >
          > > > > > So, these details remain JUST a proposal for now.
          > > > > >
          > > > > > It seems inevitable that there won't be consensus on LOT.
          > > > > >
          > > > > > Everyone will have to choose for himself. :/
          > > > > >
          > > > > > Personally I agree with most of this. I agree that there wasn’t
          > > > > > overwhelming consensus for either LOT=true or LOT=false. However,
          > from
          > > > > > my perspective there was clearly more strong opposition (what would
          > > > > > usually be deemed a NACK in Bitcoin Core review terminology) from
          > > > > > Bitcoin Core contributors, Lightning developers and other community
          > > > > > members against LOT=true than there was for LOT=false. Andrew Chow
          > > > > > tried to summarize views from the meeting in this analysis:
          > > > > > https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
          > > > > >
          > > > > > I am also aware of other current and previous Bitcoin Core
          > > > > > contributors and Lightning developers who didn’t attend the
          > meeting in
          > > > > > person who are opposed to LOT=true. I don’t want to put them in the
          > > > > > spotlight for no reason but if you go through the conversation
          > logs of
          > > > > > not only the meeting but the weeks of discussion prior to this
          > meeting
          > > > > > you will see their views evaluated on the ##taproot-activation
          > > > > > channel. In addition, on taprootactivation.com some mining pools
          > > > > > expressed a preference for lot=false though I don’t know how strong
          > > > > > that preference was.
          > > > > >
          > > > > > I am only one voice but it is my current assessment that if we are
          > to
          > > > > > attempt to finalize Taproot activation parameters and propose them
          > to
          > > > > > the community at this time our only option is to propose LOT=false.
          > > > > > Any further delay appears to me counterproductive in our collective
          > > > > > aim to get the Taproot soft fork activated as early as possible.
          > > > > >
          > > > > > Obviously others are free to disagree with that assessment and
          > > > > > continue discussions but personally I will be attempting to avoid
          > > > > > those discussions unless prominent new information comes to light
          > or
          > > > > > various specific individuals change their minds.
          > > > > >
          > > > > > Next week we are planning a code review of the Bitcoin Core PR
          > #19573
          > > > > > which was initially delayed because of this LOT discussion. As I’ve
          > > > > > said previously that will be loosely following the format of the
          > > > > > Bitcoin Core PR review club and will be lower level and more
          > > > > > technical. That is planned for Tuesday February 23rd at 19:00 UTC
          > on
          > > > > > the IRC channel ##taproot-activation.
          > > > > >
          > > > > > Thanks to the meeting participants (and those who joined the
          > > > > > discussion on the channel prior and post the meeting) for engaging
          > > > > > productively and in good faith.
          > > >
          > > > --
          > > > Michael Folkson
          > > > Email: michaelfolkson@gmail•com
          > > > Keybase: michaelfolkson
          > > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
          > > > _______________________________________________
          > > > bitcoin-dev mailing list
          > > > bitcoin-dev@lists•linuxfoundation.org
          > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
          >
          >
          >
          
          -- 
          Michael Folkson
          Email: michaelfolkson@gmail•com
          Keybase: michaelfolkson
          PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
          
          [-- Attachment #2: Type: text/html, Size: 18501 bytes --]
          
          ^ permalink raw reply	[flat|nested] 42+ messages in thread

        • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
              2021-02-18 12:20         ` Michael Folkson
            @ 2021-02-18 14:01           ` Matt Corallo
              2021-02-18 14:26             ` Michael Folkson
              0 siblings, 1 reply; 42+ messages in thread
            From: Matt Corallo @ 2021-02-18 14:01 UTC (permalink / raw)
              To: Michael Folkson, Bitcoin Protocol Discussion
            
            [-- Attachment #1: Type: text/plain, Size: 15100 bytes --]
            
            If the eventual outcome is that different implementations (that have material *transaction processing* userbases, and I’m not sure to what extent that’s true with Knots) ship different consensus rules, we should stop here and not activate Taproot. Seriously.
            
            Bitcoin is a consensus system. The absolute worst outcome at all possible is to have it fall out of consensus.
            
            Matt
            
            > On Feb 18, 2021, at 08:11, Michael Folkson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
            > 
            > 
            > Right, that is one option. Personally I would prefer a Bitcoin Core release sets LOT=false (based on what I have heard from Bitcoin Core contributors) and a community effort releases a version with LOT=true. I don't think users should be forced to choose something they may have no context on before they are allowed to use Bitcoin Core. 
            > 
            > My current understanding is that roasbeef is planning to set LOT=false on btcd (an alternative protocol implementation to Bitcoin Core) and Luke Dashjr hasn't yet decided on Bitcoin Knots.
            > 
            > 
            > 
            >> On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
            >> Good morning all,
            >> 
            >> > "An activation mechanism is a consensus change like any other change, can be contentious like any other change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline."
            >> >
            >> > Who's we here?
            >> >
            >> > Release both and let the network decide.
            >> 
            >> A thing that could be done, without mandating either LOT=true or LOT=false, would be to have a release that requires a `taprootlot=1` or `taprootlot=0` and refuses to start if the parameter is not set.
            >> 
            >> This assures everyone that neither choice is being forced on users, and instead what is being forced on users, is for users to make that choice themselves.
            >> 
            >> Regards,
            >> ZmnSCPxj
            >> 
            >> >
            >> > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
            >> >
            >> > > Thanks for your response Ariel. It would be useful if you responded to specific points I have made in the mailing list post or at least quote these ephemeral "people" you speak of. I don't know if you're responding to conversation on the IRC channel or on social media etc.
            >> > >
            >> > > > The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted into code. But in fact this isn't true and some voices in this discussion need to be more humble about what users must or must not run.
            >> > >
            >> > > I personally have never made this assumption. Of course users aren't forced to run any particular software version, quite the opposite. Defaults set in software versions matter though as many users won't change them.
            >> > >
            >> > > > Does no one realize that it is a very possible outcome that if LOT=true is released there may be only a handful of people that begin running it while everyone else delays their upgrade (with the very good reason of not getting involved in politics) and a year later those handful of people just become stuck at the moment of MUST_SIGNAL, unable to mine new blocks?
            >> > >
            >> > > It is a possible outcome but the likely outcome is that miners activate Taproot before LOT is even relevant. I think it is prudent to prepare for the unlikely but possible outcome that miners fail to activate and hence have this discussion now rather than be unprepared for that eventuality. If LOT is set to false in a software release there is the possibility (T2 in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html) of individuals or a proportion of the community changing LOT to true. In that sense setting LOT=false in a software release appears to be no more safe than LOT=true.
            >> > >
            >> > > > The result: a wasted year of waiting and a minority of people who didn't want to be lenient with miners by default.
            >> > >
            >> > > There is the (unlikely but possible) possibility of a wasted year if LOT is set to false and miners fail to activate. I'm not convinced by this perception that LOT=true is antagonistic to miners. I actually think it offers them clarity on what will happen over a year time period and removes the need for coordinated or uncoordinated community UASF efforts on top of LOT=false.
            >> > >
            >> > > > An activation mechanism is a consensus change like any other change, can be contentious like any other change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
            >> > >
            >> > > I don't know what you are recommending here to avoid "this darkest timeline". Open discussions have occurred and are continuing and in my mailing list post that you responded to **I recommended we propose LOT=false be set in protocol implementations such as Bitcoin Core**. I do think this apocalyptic language isn't particularly helpful. In an open consensus system discussion is healthy, we should prepare for bad or worst case scenarios in advance and doing so is not antagonistic or destructive. Mining pools have pledged support for Taproot but we don't build secure systems based on pledges of support, we build them to minimize trust in any human actors. We can be grateful that people like Alejandro have worked hard on taprootactivation.com (and this effort has informed the discussion) without taking pledges of support as cast iron guarantees.
            >> > >
            >> > > TL;DR It sounds like you agree with my recommendation to set LOT=false in protocol implementations in my email :)
            >> > >
            >> > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <arielluaces@gmail•com> wrote:
            >> > >
            >> > > > Something what strikes me about the conversation is the emotion surrounding the letters UASF.
            >> > > > It appears as if people discuss UASF as if it's a massive tidal wave of support that is inevitable, like we saw during segwit activation. But the actual definition is "any activation that is not a MASF".
            >> > > > A UASF can consist of a single node, ten nodes, a thousand, half of all nodes, all business' nodes, or even all the non mining nodes. On another dimension it can have zero mining support, 51% support, 49% support, or any support right up against a miner activation threshold.
            >> > > > Hell a UASF doesn't even need code or even a single node running as long as it exists as a possibility in people's minds.
            >> > > > The only thing a UASF doesn't have is miner support above an agreed activation threshold (some number above %51).
            >> > > > I say this because it strikes me when people say that they are for LOT=true with the logic that since a UASF is guaranteed to happen then it's better to just make it default from the beginning. Words like coordination and safety are sometimes sprinkled into the argument.
            >> > > > The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted into code. But in fact this isn't true and some voices in this discussion need to be more humble about what users must or must not run.
            >> > > > Does no one realize that it is a very possible outcome that if LOT=true is released there may be only a handful of people that begin running it while everyone else delays their upgrade (with the very good reason of not getting involved in politics) and a year later those handful of people just become stuck at the moment of MUST_SIGNAL, unable to mine new blocks? Or attracting a minority of miners, activating, and forking off into a minority fork. Then a lot=false could be started that ends up activating the feature now that the stubborn option has ran its course.
            >> > > > The result: a wasted year of waiting and a minority of people who didn't want to be lenient with miners by default. The chains could be called BitcoinLenient and BitcoinStubborn.
            >> > > > How is that strictly safer or more coordinated?
            >> > > > I may be in the minority, or maybe a silent majority, or maybe a majority that just hasn't considered this as a choice but honestly if there is contention about whether we're going to be stubborn or lenient with miners for Taproot and in the future then I prefer to just not activate anything at all. I'm fine for calling bitcoin ossified, accepting that segwit is Bitcoin's last network upgrade. Taproot is amazing but no new feature is worth a network split down the middle.
            >> > > > Maybe in 10 or 20 years, when other blockchains implement features like Taproot and many more, we will become envious enough to put aside our differences on how to behave towards miners and finally activate Taproot.
            >> > > > An activation mechanism is a consensus change like any other change, can be contentious like any other change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
            >> > > > Cheers
            >> > > > Ariel Lorenzo-Luaces
            >> > > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
            >> > > >
            >> > > > > Yesterday (February 16th) we held a second meeting on Taproot
            >> > > > > activation on IRC which again was open to all. Despite what appeared
            >> > > > > to be majority support for LOT=false over LOT=true in the first
            >> > > > > meeting I (and others) thought the arguments had not been explored in
            >> > > > > depth and that we should have a follow up meeting almost entirely
            >> > > > > focused on whether LOT (lockinontimeout) should be set to true or
            >> > > > > false.
            >> > > > >
            >> > > > > The meeting was announced here:
            >> > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
            >> > > > >
            >> > > > > In that mailing list post I outlined the arguments for LOT=true (T1 to
            >> > > > > T6) and arguments for LOT=false (F1 to F6) in their strongest form I
            >> > > > > could. David Harding responded with an additional argument for
            >> > > > > LOT=false (F7) here:
            >> > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
            >> > > > >
            >> > > > > These meetings are very challenging given they are open to all, you
            >> > > > > don’t know who will attend and you don’t know most people’s views in
            >> > > > > advance. I tried to give time for both the LOT=true arguments and the
            >> > > > > LOT=false arguments to be discussed as I knew there was support for
            >> > > > > both. We only tried evaluating which had more support and which had
            >> > > > > more strong opposition towards the end of the meeting.
            >> > > > >
            >> > > > > The conversation log is here:
            >> > > > > http://gnusha.org/taproot-activation/2021-02-16.log
            >> > > > >
            >> > > > > (If you are so inclined you can watch a video of the meeting here.
            >> > > > > Thanks to the YouTube account “Bitcoin” for setting up the livestream:
            >> > > > > https://www.youtube.com/watch?v=vpl5q1ovMLM)
            >> > > > >
            >> > > > > A summary of the meeting was provided by Luke Dashjr on Mastodon here:
            >> > > > > https://bitcoinhackers.org/@lukedashjr/105742918779234566
            >> > > > >
            >> > > > > Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we
            >> > > > > did manage to come to consensus on everything but LockinOnTimeout.
            >> > > > >
            >> > > > > Activation height range: 693504-745920
            >> > > > >
            >> > > > > MASF threshold: 1815/2016 blocks (90%)
            >> > > > >
            >> > > > > Keep in mind only ~100 people showed for the meetings, hardly
            >> > > > > representative of the entire community.
            >> > > > >
            >> > > > > So, these details remain JUST a proposal for now.
            >> > > > >
            >> > > > > It seems inevitable that there won't be consensus on LOT.
            >> > > > >
            >> > > > > Everyone will have to choose for himself. :/
            >> > > > >
            >> > > > > Personally I agree with most of this. I agree that there wasn’t
            >> > > > > overwhelming consensus for either LOT=true or LOT=false. However, from
            >> > > > > my perspective there was clearly more strong opposition (what would
            >> > > > > usually be deemed a NACK in Bitcoin Core review terminology) from
            >> > > > > Bitcoin Core contributors, Lightning developers and other community
            >> > > > > members against LOT=true than there was for LOT=false. Andrew Chow
            >> > > > > tried to summarize views from the meeting in this analysis:
            >> > > > > https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
            >> > > > >
            >> > > > > I am also aware of other current and previous Bitcoin Core
            >> > > > > contributors and Lightning developers who didn’t attend the meeting in
            >> > > > > person who are opposed to LOT=true. I don’t want to put them in the
            >> > > > > spotlight for no reason but if you go through the conversation logs of
            >> > > > > not only the meeting but the weeks of discussion prior to this meeting
            >> > > > > you will see their views evaluated on the ##taproot-activation
            >> > > > > channel. In addition, on taprootactivation.com some mining pools
            >> > > > > expressed a preference for lot=false though I don’t know how strong
            >> > > > > that preference was.
            >> > > > >
            >> > > > > I am only one voice but it is my current assessment that if we are to
            >> > > > > attempt to finalize Taproot activation parameters and propose them to
            >> > > > > the community at this time our only option is to propose LOT=false.
            >> > > > > Any further delay appears to me counterproductive in our collective
            >> > > > > aim to get the Taproot soft fork activated as early as possible.
            >> > > > >
            >> > > > > Obviously others are free to disagree with that assessment and
            >> > > > > continue discussions but personally I will be attempting to avoid
            >> > > > > those discussions unless prominent new information comes to light or
            >> > > > > various specific individuals change their minds.
            >> > > > >
            >> > > > > Next week we are planning a code review of the Bitcoin Core PR #19573
            >> > > > > which was initially delayed because of this LOT discussion. As I’ve
            >> > > > > said previously that will be loosely following the format of the
            >> > > > > Bitcoin Core PR review club and will be lower level and more
            >> > > > > technical. That is planned for Tuesday February 23rd at 19:00 UTC on
            >> > > > > the IRC channel ##taproot-activation.
            >> > > > >
            >> > > > > Thanks to the meeting participants (and those who joined the
            >> > > > > discussion on the channel prior and post the meeting) for engaging
            >> > > > > productively and in good faith.
            >> > >
            >> > > --
            >> > > Michael Folkson
            >> > > Email: michaelfolkson@gmail•com
            >> > > Keybase: michaelfolkson
            >> > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
            >> > > _______________________________________________
            >> > > bitcoin-dev mailing list
            >> > > bitcoin-dev@lists•linuxfoundation.org
            >> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
            >> 
            >> 
            > 
            > 
            > -- 
            > Michael Folkson
            > Email: michaelfolkson@gmail•com
            > Keybase: michaelfolkson
            > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
            > _______________________________________________
            > bitcoin-dev mailing list
            > bitcoin-dev@lists•linuxfoundation.org
            > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
            
            [-- Attachment #2: Type: text/html, Size: 19459 bytes --]
            
            ^ permalink raw reply	[flat|nested] 42+ messages in thread

          • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                2021-02-18 14:01           ` Matt Corallo
              @ 2021-02-18 14:26             ` Michael Folkson
                2021-02-18 14:42               ` Matt Corallo
                0 siblings, 1 reply; 42+ messages in thread
              From: Michael Folkson @ 2021-02-18 14:26 UTC (permalink / raw)
                To: Matt Corallo; +Cc: Bitcoin Protocol Discussion
              
              [-- Attachment #1: Type: text/plain, Size: 17102 bytes --]
              
              Thanks for your response Matt. It is a fair challenge. There is always
              going to be an element of risk with soft forks, all we can do is attempt to
              minimize that risk. I would argue that risk has been minimized for Taproot.
              
              You know (better than I do in fact) that Bitcoin (and layers built on top
              of it) greatly benefit from upgrades such as Taproot. To say we shouldn't
              do Taproot or any future soft forks because there is a small but real risk
              of chain splits I think is shortsighted. Indeed I think even if we
              collectively decided not to do any future soft fork upgrades ever again on
              this mailing list that wouldn't stop soft fork attempts from other people
              in future.
              
              I don't think there is anything else we can do to minimize that risk for
              the Taproot soft fork at this point though I'm open to ideas. To reiterate
              that risk will never be zero. I don't think I see Bitcoin as fragile as you
              seem to (though admittedly you have a much better understanding than me of
              what happened in 2017).
              
              The likely scenario for the Taproot soft fork is LOT turns out to be
              entirely irrelevant and miners activate Taproot before it becomes relevant.
              And even the unlikely worst case scenario would only cause short term
              disruption and wouldn't kill Bitcoin long term.
              
              On Thu, Feb 18, 2021 at 2:01 PM Matt Corallo <lf-lists@mattcorallo•com>
              wrote:
              
              > If the eventual outcome is that different implementations (that have
              > material *transaction processing* userbases, and I’m not sure to what
              > extent that’s true with Knots) ship different consensus rules, we should
              > stop here and not activate Taproot. Seriously.
              >
              > Bitcoin is a consensus system. The absolute worst outcome at all possible
              > is to have it fall out of consensus.
              >
              > Matt
              >
              > On Feb 18, 2021, at 08:11, Michael Folkson via bitcoin-dev <
              > bitcoin-dev@lists•linuxfoundation.org> wrote:
              >
              > 
              > Right, that is one option. Personally I would prefer a Bitcoin Core
              > release sets LOT=false (based on what I have heard from Bitcoin Core
              > contributors) and a community effort releases a version with LOT=true. I
              > don't think users should be forced to choose something they may have no
              > context on before they are allowed to use Bitcoin Core.
              >
              > My current understanding is that roasbeef is planning to set LOT=false on
              > btcd (an alternative protocol implementation to Bitcoin Core) and Luke
              > Dashjr hasn't yet decided on Bitcoin Knots.
              >
              >
              >
              > On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
              >
              >> Good morning all,
              >>
              >> > "An activation mechanism is a consensus change like any other change,
              >> can be contentious like any other change, and we must resolve it like any
              >> other change. Otherwise we risk arriving at the darkest timeline."
              >> >
              >> > Who's we here?
              >> >
              >> > Release both and let the network decide.
              >>
              >> A thing that could be done, without mandating either LOT=true or
              >> LOT=false, would be to have a release that requires a `taprootlot=1` or
              >> `taprootlot=0` and refuses to start if the parameter is not set.
              >>
              >> This assures everyone that neither choice is being forced on users, and
              >> instead what is being forced on users, is for users to make that choice
              >> themselves.
              >>
              >> Regards,
              >> ZmnSCPxj
              >>
              >> >
              >> > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <
              >> bitcoin-dev@lists•linuxfoundation.org> wrote:
              >> >
              >> > > Thanks for your response Ariel. It would be useful if you responded
              >> to specific points I have made in the mailing list post or at least quote
              >> these ephemeral "people" you speak of. I don't know if you're responding to
              >> conversation on the IRC channel or on social media etc.
              >> > >
              >> > > > The argument comes from a naive assumption that users MUST upgrade
              >> to the choice that is submitted into code. But in fact this isn't true and
              >> some voices in this discussion need to be more humble about what users must
              >> or must not run.
              >> > >
              >> > > I personally have never made this assumption. Of course users aren't
              >> forced to run any particular software version, quite the opposite. Defaults
              >> set in software versions matter though as many users won't change them.
              >> > >
              >> > > > Does no one realize that it is a very possible outcome that if
              >> LOT=true is released there may be only a handful of people that begin
              >> running it while everyone else delays their upgrade (with the very good
              >> reason of not getting involved in politics) and a year later those handful
              >> of people just become stuck at the moment of MUST_SIGNAL, unable to mine
              >> new blocks?
              >> > >
              >> > > It is a possible outcome but the likely outcome is that miners
              >> activate Taproot before LOT is even relevant. I think it is prudent to
              >> prepare for the unlikely but possible outcome that miners fail to activate
              >> and hence have this discussion now rather than be unprepared for that
              >> eventuality. If LOT is set to false in a software release there is the
              >> possibility (T2 in
              >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html)
              >> of individuals or a proportion of the community changing LOT to true. In
              >> that sense setting LOT=false in a software release appears to be no more
              >> safe than LOT=true.
              >> > >
              >> > > > The result: a wasted year of waiting and a minority of people who
              >> didn't want to be lenient with miners by default.
              >> > >
              >> > > There is the (unlikely but possible) possibility of a wasted year if
              >> LOT is set to false and miners fail to activate. I'm not convinced by this
              >> perception that LOT=true is antagonistic to miners. I actually think it
              >> offers them clarity on what will happen over a year time period and removes
              >> the need for coordinated or uncoordinated community UASF efforts on top of
              >> LOT=false.
              >> > >
              >> > > > An activation mechanism is a consensus change like any other
              >> change, can be contentious like any other change, and we must resolve it
              >> like any other change. Otherwise we risk arriving at the darkest timeline.
              >> > >
              >> > > I don't know what you are recommending here to avoid "this darkest
              >> timeline". Open discussions have occurred and are continuing and in my
              >> mailing list post that you responded to **I recommended we propose
              >> LOT=false be set in protocol implementations such as Bitcoin Core**. I do
              >> think this apocalyptic language isn't particularly helpful. In an open
              >> consensus system discussion is healthy, we should prepare for bad or worst
              >> case scenarios in advance and doing so is not antagonistic or destructive.
              >> Mining pools have pledged support for Taproot but we don't build secure
              >> systems based on pledges of support, we build them to minimize trust in any
              >> human actors. We can be grateful that people like Alejandro have worked
              >> hard on taprootactivation.com (and this effort has informed the
              >> discussion) without taking pledges of support as cast iron guarantees.
              >> > >
              >> > > TL;DR It sounds like you agree with my recommendation to set
              >> LOT=false in protocol implementations in my email :)
              >> > >
              >> > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <
              >> arielluaces@gmail•com> wrote:
              >> > >
              >> > > > Something what strikes me about the conversation is the emotion
              >> surrounding the letters UASF.
              >> > > > It appears as if people discuss UASF as if it's a massive tidal
              >> wave of support that is inevitable, like we saw during segwit activation.
              >> But the actual definition is "any activation that is not a MASF".
              >> > > > A UASF can consist of a single node, ten nodes, a thousand, half of
              >> all nodes, all business' nodes, or even all the non mining nodes. On
              >> another dimension it can have zero mining support, 51% support, 49%
              >> support, or any support right up against a miner activation threshold.
              >> > > > Hell a UASF doesn't even need code or even a single node running as
              >> long as it exists as a possibility in people's minds.
              >> > > > The only thing a UASF doesn't have is miner support above an agreed
              >> activation threshold (some number above %51).
              >> > > > I say this because it strikes me when people say that they are for
              >> LOT=true with the logic that since a UASF is guaranteed to happen then it's
              >> better to just make it default from the beginning. Words like coordination
              >> and safety are sometimes sprinkled into the argument.
              >> > > > The argument comes from a naive assumption that users MUST upgrade
              >> to the choice that is submitted into code. But in fact this isn't true and
              >> some voices in this discussion need to be more humble about what users must
              >> or must not run.
              >> > > > Does no one realize that it is a very possible outcome that if
              >> LOT=true is released there may be only a handful of people that begin
              >> running it while everyone else delays their upgrade (with the very good
              >> reason of not getting involved in politics) and a year later those handful
              >> of people just become stuck at the moment of MUST_SIGNAL, unable to mine
              >> new blocks? Or attracting a minority of miners, activating, and forking off
              >> into a minority fork. Then a lot=false could be started that ends up
              >> activating the feature now that the stubborn option has ran its course.
              >> > > > The result: a wasted year of waiting and a minority of people who
              >> didn't want to be lenient with miners by default. The chains could be
              >> called BitcoinLenient and BitcoinStubborn.
              >> > > > How is that strictly safer or more coordinated?
              >> > > > I may be in the minority, or maybe a silent majority, or maybe a
              >> majority that just hasn't considered this as a choice but honestly if there
              >> is contention about whether we're going to be stubborn or lenient with
              >> miners for Taproot and in the future then I prefer to just not activate
              >> anything at all. I'm fine for calling bitcoin ossified, accepting that
              >> segwit is Bitcoin's last network upgrade. Taproot is amazing but no new
              >> feature is worth a network split down the middle.
              >> > > > Maybe in 10 or 20 years, when other blockchains implement features
              >> like Taproot and many more, we will become envious enough to put aside our
              >> differences on how to behave towards miners and finally activate Taproot.
              >> > > > An activation mechanism is a consensus change like any other
              >> change, can be contentious like any other change, and we must resolve it
              >> like any other change. Otherwise we risk arriving at the darkest timeline.
              >> > > > Cheers
              >> > > > Ariel Lorenzo-Luaces
              >> > > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev <
              >> bitcoin-dev@lists•linuxfoundation.org> wrote:
              >> > > >
              >> > > > > Yesterday (February 16th) we held a second meeting on Taproot
              >> > > > > activation on IRC which again was open to all. Despite what
              >> appeared
              >> > > > > to be majority support for LOT=false over LOT=true in the first
              >> > > > > meeting I (and others) thought the arguments had not been
              >> explored in
              >> > > > > depth and that we should have a follow up meeting almost entirely
              >> > > > > focused on whether LOT (lockinontimeout) should be set to true or
              >> > > > > false.
              >> > > > >
              >> > > > > The meeting was announced here:
              >> > > > >
              >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
              >> > > > >
              >> > > > > In that mailing list post I outlined the arguments for LOT=true
              >> (T1 to
              >> > > > > T6) and arguments for LOT=false (F1 to F6) in their strongest
              >> form I
              >> > > > > could. David Harding responded with an additional argument for
              >> > > > > LOT=false (F7) here:
              >> > > > >
              >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
              >> > > > >
              >> > > > > These meetings are very challenging given they are open to all,
              >> you
              >> > > > > don’t know who will attend and you don’t know most people’s views
              >> in
              >> > > > > advance. I tried to give time for both the LOT=true arguments and
              >> the
              >> > > > > LOT=false arguments to be discussed as I knew there was support
              >> for
              >> > > > > both. We only tried evaluating which had more support and which
              >> had
              >> > > > > more strong opposition towards the end of the meeting.
              >> > > > >
              >> > > > > The conversation log is here:
              >> > > > > http://gnusha.org/taproot-activation/2021-02-16.log
              >> > > > >
              >> > > > > (If you are so inclined you can watch a video of the meeting here.
              >> > > > > Thanks to the YouTube account “Bitcoin” for setting up the
              >> livestream:
              >> > > > > https://www.youtube.com/watch?v=vpl5q1ovMLM)
              >> > > > >
              >> > > > > A summary of the meeting was provided by Luke Dashjr on Mastodon
              >> here:
              >> > > > > https://bitcoinhackers.org/@lukedashjr/105742918779234566
              >> > > > >
              >> > > > > Today's #Bitcoin #Taproot meeting was IMO largely unproductive,
              >> but we
              >> > > > > did manage to come to consensus on everything but LockinOnTimeout.
              >> > > > >
              >> > > > > Activation height range: 693504-745920
              >> > > > >
              >> > > > > MASF threshold: 1815/2016 blocks (90%)
              >> > > > >
              >> > > > > Keep in mind only ~100 people showed for the meetings, hardly
              >> > > > > representative of the entire community.
              >> > > > >
              >> > > > > So, these details remain JUST a proposal for now.
              >> > > > >
              >> > > > > It seems inevitable that there won't be consensus on LOT.
              >> > > > >
              >> > > > > Everyone will have to choose for himself. :/
              >> > > > >
              >> > > > > Personally I agree with most of this. I agree that there wasn’t
              >> > > > > overwhelming consensus for either LOT=true or LOT=false. However,
              >> from
              >> > > > > my perspective there was clearly more strong opposition (what
              >> would
              >> > > > > usually be deemed a NACK in Bitcoin Core review terminology) from
              >> > > > > Bitcoin Core contributors, Lightning developers and other
              >> community
              >> > > > > members against LOT=true than there was for LOT=false. Andrew Chow
              >> > > > > tried to summarize views from the meeting in this analysis:
              >> > > > > https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
              >> > > > >
              >> > > > > I am also aware of other current and previous Bitcoin Core
              >> > > > > contributors and Lightning developers who didn’t attend the
              >> meeting in
              >> > > > > person who are opposed to LOT=true. I don’t want to put them in
              >> the
              >> > > > > spotlight for no reason but if you go through the conversation
              >> logs of
              >> > > > > not only the meeting but the weeks of discussion prior to this
              >> meeting
              >> > > > > you will see their views evaluated on the ##taproot-activation
              >> > > > > channel. In addition, on taprootactivation.com some mining pools
              >> > > > > expressed a preference for lot=false though I don’t know how
              >> strong
              >> > > > > that preference was.
              >> > > > >
              >> > > > > I am only one voice but it is my current assessment that if we
              >> are to
              >> > > > > attempt to finalize Taproot activation parameters and propose
              >> them to
              >> > > > > the community at this time our only option is to propose
              >> LOT=false.
              >> > > > > Any further delay appears to me counterproductive in our
              >> collective
              >> > > > > aim to get the Taproot soft fork activated as early as possible.
              >> > > > >
              >> > > > > Obviously others are free to disagree with that assessment and
              >> > > > > continue discussions but personally I will be attempting to avoid
              >> > > > > those discussions unless prominent new information comes to light
              >> or
              >> > > > > various specific individuals change their minds.
              >> > > > >
              >> > > > > Next week we are planning a code review of the Bitcoin Core PR
              >> #19573
              >> > > > > which was initially delayed because of this LOT discussion. As
              >> I’ve
              >> > > > > said previously that will be loosely following the format of the
              >> > > > > Bitcoin Core PR review club and will be lower level and more
              >> > > > > technical. That is planned for Tuesday February 23rd at 19:00 UTC
              >> on
              >> > > > > the IRC channel ##taproot-activation.
              >> > > > >
              >> > > > > Thanks to the meeting participants (and those who joined the
              >> > > > > discussion on the channel prior and post the meeting) for engaging
              >> > > > > productively and in good faith.
              >> > >
              >> > > --
              >> > > Michael Folkson
              >> > > Email: michaelfolkson@gmail•com
              >> > > Keybase: michaelfolkson
              >> > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
              >> > > _______________________________________________
              >> > > bitcoin-dev mailing list
              >> > > bitcoin-dev@lists•linuxfoundation.org
              >> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
              >>
              >>
              >>
              >
              > --
              > Michael Folkson
              > Email: michaelfolkson@gmail•com
              > Keybase: michaelfolkson
              > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
              > _______________________________________________
              > bitcoin-dev mailing list
              > bitcoin-dev@lists•linuxfoundation.org
              > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
              >
              >
              
              -- 
              Michael Folkson
              Email: michaelfolkson@gmail•com
              Keybase: michaelfolkson
              PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
              
              [-- Attachment #2: Type: text/html, Size: 22184 bytes --]
              
              ^ permalink raw reply	[flat|nested] 42+ messages in thread

            • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                  2021-02-18 14:26             ` Michael Folkson
                @ 2021-02-18 14:42               ` Matt Corallo
                  2021-02-18 14:51                 ` Michael Folkson
                  2021-02-18 15:04                 ` Keagan McClelland
                  0 siblings, 2 replies; 42+ messages in thread
                From: Matt Corallo @ 2021-02-18 14:42 UTC (permalink / raw)
                  To: Michael Folkson; +Cc: Bitcoin Protocol Discussion
                
                We've had several softforks in Bitcoin which, through the course of their activation, had a several-block reorg. That 
                should be indication enough that we need to very carefully consider activation to ensure we reduce the risk of that as 
                much as absolutely possible. Again, while I think Taproot is a huge improvement and am looking forward to being able to 
                use it, getting unlucky and hitting a 4-block reorg that happens to include a double-spend and some PR around an 
                exchange losing millions would be worse than having Taproot is good.
                
                Matt
                
                On 2/18/21 09:26, Michael Folkson wrote:
                > Thanks for your response Matt. It is a fair challenge. There is always going to be an element of risk with soft forks, 
                > all we can do is attempt to minimize that risk. I would argue that risk has been minimized for Taproot.
                > 
                > You know (better than I do in fact) that Bitcoin (and layers built on top of it) greatly benefit from upgrades such as 
                > Taproot. To say we shouldn't do Taproot or any future soft forks because there is a small but real risk of chain splits 
                > I think is shortsighted. Indeed I think even if we collectively decided not to do any future soft fork upgrades ever 
                > again on this mailing list that wouldn't stop soft fork attempts from other people in future.
                > 
                > I don't think there is anything else we can do to minimize that risk for the Taproot soft fork at this point though I'm 
                > open to ideas. To reiterate that risk will never be zero. I don't think I see Bitcoin as fragile as you seem to (though 
                > admittedly you have a much better understanding than me of what happened in 2017).
                > 
                > The likely scenario for the Taproot soft fork is LOT turns out to be entirely irrelevant and miners activate Taproot 
                > before it becomes relevant. And even the unlikely worst case scenario would only cause short term disruption and 
                > wouldn't kill Bitcoin long term.
                > 
                > On Thu, Feb 18, 2021 at 2:01 PM Matt Corallo <lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo•com>> wrote:
                > 
                >     If the eventual outcome is that different implementations (that have material *transaction processing* userbases,
                >     and I’m not sure to what extent that’s true with Knots) ship different consensus rules, we should stop here and not
                >     activate Taproot. Seriously.
                > 
                >     Bitcoin is a consensus system. The absolute worst outcome at all possible is to have it fall out of consensus.
                > 
                >     Matt
                > 
                >>     On Feb 18, 2021, at 08:11, Michael Folkson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org
                >>     <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
                >>
                >>     
                >>     Right, that is one option. Personally I would prefer a Bitcoin Core release sets LOT=false (based on what I have
                >>     heard from Bitcoin Core contributors) and a community effort releases a version with LOT=true. I don't think users
                >>     should be forced to choose something they may have no context on before they are allowed to use Bitcoin Core.
                >>
                >>     My current understanding is that roasbeef is planning to set LOT=false on btcd (an alternative protocol
                >>     implementation to Bitcoin Core) and Luke Dashjr hasn't yet decided on Bitcoin Knots.
                >>
                >>
                >>
                >>     On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <ZmnSCPxj@protonmail•com <mailto:ZmnSCPxj@protonmail•com>> wrote:
                >>
                >>         Good morning all,
                >>
                >>         > "An activation mechanism is a consensus change like any other change, can be contentious like any other
                >>         change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline."
                >>         >
                >>         > Who's we here?
                >>         >
                >>         > Release both and let the network decide.
                >>
                >>         A thing that could be done, without mandating either LOT=true or LOT=false, would be to have a release that
                >>         requires a `taprootlot=1` or `taprootlot=0` and refuses to start if the parameter is not set.
                >>
                >>         This assures everyone that neither choice is being forced on users, and instead what is being forced on users,
                >>         is for users to make that choice themselves.
                >>
                >>         Regards,
                >>         ZmnSCPxj
                >>
                >>         >
                >>         > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org
                >>         <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
                >>         >
                >>         > > Thanks for your response Ariel. It would be useful if you responded to specific points I have made in the
                >>         mailing list post or at least quote these ephemeral "people" you speak of. I don't know if you're responding
                >>         to conversation on the IRC channel or on social media etc.
                >>         > >
                >>         > > > The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted into
                >>         code. But in fact this isn't true and some voices in this discussion need to be more humble about what users
                >>         must or must not run.
                >>         > >
                >>         > > I personally have never made this assumption. Of course users aren't forced to run any particular software
                >>         version, quite the opposite. Defaults set in software versions matter though as many users won't change them.
                >>         > >
                >>         > > > Does no one realize that it is a very possible outcome that if LOT=true is released there may be only a
                >>         handful of people that begin running it while everyone else delays their upgrade (with the very good reason of
                >>         not getting involved in politics) and a year later those handful of people just become stuck at the moment of
                >>         MUST_SIGNAL, unable to mine new blocks?
                >>         > >
                >>         > > It is a possible outcome but the likely outcome is that miners activate Taproot before LOT is even
                >>         relevant. I think it is prudent to prepare for the unlikely but possible outcome that miners fail to activate
                >>         and hence have this discussion now rather than be unprepared for that eventuality. If LOT is set to false in a
                >>         software release there is the possibility (T2 in
                >>         https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>) of individuals or a
                >>         proportion of the community changing LOT to true. In that sense setting LOT=false in a software release
                >>         appears to be no more safe than LOT=true.
                >>         > >
                >>         > > > The result: a wasted year of waiting and a minority of people who didn't want to be lenient with miners
                >>         by default.
                >>         > >
                >>         > > There is the (unlikely but possible) possibility of a wasted year if LOT is set to false and miners fail
                >>         to activate. I'm not convinced by this perception that LOT=true is antagonistic to miners. I actually think it
                >>         offers them clarity on what will happen over a year time period and removes the need for coordinated or
                >>         uncoordinated community UASF efforts on top of LOT=false.
                >>         > >
                >>         > > > An activation mechanism is a consensus change like any other change, can be contentious like any other
                >>         change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
                >>         > >
                >>         > > I don't know what you are recommending here to avoid "this darkest timeline". Open discussions have
                >>         occurred and are continuing and in my mailing list post that you responded to **I recommended we propose
                >>         LOT=false be set in protocol implementations such as Bitcoin Core**. I do think this apocalyptic language
                >>         isn't particularly helpful. In an open consensus system discussion is healthy, we should prepare for bad or
                >>         worst case scenarios in advance and doing so is not antagonistic or destructive. Mining pools have pledged
                >>         support for Taproot but we don't build secure systems based on pledges of support, we build them to minimize
                >>         trust in any human actors. We can be grateful that people like Alejandro have worked hard on
                >>         taprootactivation.com <http://taprootactivation.com> (and this effort has informed the discussion) without
                >>         taking pledges of support as cast iron guarantees.
                >>         > >
                >>         > > TL;DR It sounds like you agree with my recommendation to set LOT=false in protocol implementations in my
                >>         email :)
                >>         > >
                >>         > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <arielluaces@gmail•com
                >>         <mailto:arielluaces@gmail•com>> wrote:
                >>         > >
                >>         > > > Something what strikes me about the conversation is the emotion surrounding the letters UASF.
                >>         > > > It appears as if people discuss UASF as if it's a massive tidal wave of support that is inevitable, like
                >>         we saw during segwit activation. But the actual definition is "any activation that is not a MASF".
                >>         > > > A UASF can consist of a single node, ten nodes, a thousand, half of all nodes, all business' nodes, or
                >>         even all the non mining nodes. On another dimension it can have zero mining support, 51% support, 49% support,
                >>         or any support right up against a miner activation threshold.
                >>         > > > Hell a UASF doesn't even need code or even a single node running as long as it exists as a possibility
                >>         in people's minds.
                >>         > > > The only thing a UASF doesn't have is miner support above an agreed activation threshold (some number
                >>         above %51).
                >>         > > > I say this because it strikes me when people say that they are for LOT=true with the logic that since a
                >>         UASF is guaranteed to happen then it's better to just make it default from the beginning. Words like
                >>         coordination and safety are sometimes sprinkled into the argument.
                >>         > > > The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted into
                >>         code. But in fact this isn't true and some voices in this discussion need to be more humble about what users
                >>         must or must not run.
                >>         > > > Does no one realize that it is a very possible outcome that if LOT=true is released there may be only a
                >>         handful of people that begin running it while everyone else delays their upgrade (with the very good reason of
                >>         not getting involved in politics) and a year later those handful of people just become stuck at the moment of
                >>         MUST_SIGNAL, unable to mine new blocks? Or attracting a minority of miners, activating, and forking off into a
                >>         minority fork. Then a lot=false could be started that ends up activating the feature now that the stubborn
                >>         option has ran its course.
                >>         > > > The result: a wasted year of waiting and a minority of people who didn't want to be lenient with miners
                >>         by default. The chains could be called BitcoinLenient and BitcoinStubborn.
                >>         > > > How is that strictly safer or more coordinated?
                >>         > > > I may be in the minority, or maybe a silent majority, or maybe a majority that just hasn't considered
                >>         this as a choice but honestly if there is contention about whether we're going to be stubborn or lenient with
                >>         miners for Taproot and in the future then I prefer to just not activate anything at all. I'm fine for calling
                >>         bitcoin ossified, accepting that segwit is Bitcoin's last network upgrade. Taproot is amazing but no new
                >>         feature is worth a network split down the middle.
                >>         > > > Maybe in 10 or 20 years, when other blockchains implement features like Taproot and many more, we will
                >>         become envious enough to put aside our differences on how to behave towards miners and finally activate Taproot.
                >>         > > > An activation mechanism is a consensus change like any other change, can be contentious like any other
                >>         change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
                >>         > > > Cheers
                >>         > > > Ariel Lorenzo-Luaces
                >>         > > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org
                >>         <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
                >>         > > >
                >>         > > > > Yesterday (February 16th) we held a second meeting on Taproot
                >>         > > > > activation on IRC which again was open to all. Despite what appeared
                >>         > > > > to be majority support for LOT=false over LOT=true in the first
                >>         > > > > meeting I (and others) thought the arguments had not been explored in
                >>         > > > > depth and that we should have a follow up meeting almost entirely
                >>         > > > > focused on whether LOT (lockinontimeout) should be set to true or
                >>         > > > > false.
                >>         > > > >
                >>         > > > > The meeting was announced here:
                >>         > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>
                >>         > > > >
                >>         > > > > In that mailing list post I outlined the arguments for LOT=true (T1 to
                >>         > > > > T6) and arguments for LOT=false (F1 to F6) in their strongest form I
                >>         > > > > could. David Harding responded with an additional argument for
                >>         > > > > LOT=false (F7) here:
                >>         > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
                >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html>
                >>         > > > >
                >>         > > > > These meetings are very challenging given they are open to all, you
                >>         > > > > don’t know who will attend and you don’t know most people’s views in
                >>         > > > > advance. I tried to give time for both the LOT=true arguments and the
                >>         > > > > LOT=false arguments to be discussed as I knew there was support for
                >>         > > > > both. We only tried evaluating which had more support and which had
                >>         > > > > more strong opposition towards the end of the meeting.
                >>         > > > >
                >>         > > > > The conversation log is here:
                >>         > > > > http://gnusha.org/taproot-activation/2021-02-16.log <http://gnusha.org/taproot-activation/2021-02-16.log>
                >>         > > > >
                >>         > > > > (If you are so inclined you can watch a video of the meeting here.
                >>         > > > > Thanks to the YouTube account “Bitcoin” for setting up the livestream:
                >>         > > > > https://www.youtube.com/watch?v=vpl5q1ovMLM <https://www.youtube.com/watch?v=vpl5q1ovMLM>)
                >>         > > > >
                >>         > > > > A summary of the meeting was provided by Luke Dashjr on Mastodon here:
                >>         > > > > https://bitcoinhackers.org/@lukedashjr/105742918779234566
                >>         <https://bitcoinhackers.org/@lukedashjr/105742918779234566>
                >>         > > > >
                >>         > > > > Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we
                >>         > > > > did manage to come to consensus on everything but LockinOnTimeout.
                >>         > > > >
                >>         > > > > Activation height range: 693504-745920
                >>         > > > >
                >>         > > > > MASF threshold: 1815/2016 blocks (90%)
                >>         > > > >
                >>         > > > > Keep in mind only ~100 people showed for the meetings, hardly
                >>         > > > > representative of the entire community.
                >>         > > > >
                >>         > > > > So, these details remain JUST a proposal for now.
                >>         > > > >
                >>         > > > > It seems inevitable that there won't be consensus on LOT.
                >>         > > > >
                >>         > > > > Everyone will have to choose for himself. :/
                >>         > > > >
                >>         > > > > Personally I agree with most of this. I agree that there wasn’t
                >>         > > > > overwhelming consensus for either LOT=true or LOT=false. However, from
                >>         > > > > my perspective there was clearly more strong opposition (what would
                >>         > > > > usually be deemed a NACK in Bitcoin Core review terminology) from
                >>         > > > > Bitcoin Core contributors, Lightning developers and other community
                >>         > > > > members against LOT=true than there was for LOT=false. Andrew Chow
                >>         > > > > tried to summarize views from the meeting in this analysis:
                >>         > > > > https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
                >>         <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>
                >>         > > > >
                >>         > > > > I am also aware of other current and previous Bitcoin Core
                >>         > > > > contributors and Lightning developers who didn’t attend the meeting in
                >>         > > > > person who are opposed to LOT=true. I don’t want to put them in the
                >>         > > > > spotlight for no reason but if you go through the conversation logs of
                >>         > > > > not only the meeting but the weeks of discussion prior to this meeting
                >>         > > > > you will see their views evaluated on the ##taproot-activation
                >>         > > > > channel. In addition, on taprootactivation.com <http://taprootactivation.com> some mining pools
                >>         > > > > expressed a preference for lot=false though I don’t know how strong
                >>         > > > > that preference was.
                >>         > > > >
                >>         > > > > I am only one voice but it is my current assessment that if we are to
                >>         > > > > attempt to finalize Taproot activation parameters and propose them to
                >>         > > > > the community at this time our only option is to propose LOT=false.
                >>         > > > > Any further delay appears to me counterproductive in our collective
                >>         > > > > aim to get the Taproot soft fork activated as early as possible.
                >>         > > > >
                >>         > > > > Obviously others are free to disagree with that assessment and
                >>         > > > > continue discussions but personally I will be attempting to avoid
                >>         > > > > those discussions unless prominent new information comes to light or
                >>         > > > > various specific individuals change their minds.
                >>         > > > >
                >>         > > > > Next week we are planning a code review of the Bitcoin Core PR #19573
                >>         > > > > which was initially delayed because of this LOT discussion. As I’ve
                >>         > > > > said previously that will be loosely following the format of the
                >>         > > > > Bitcoin Core PR review club and will be lower level and more
                >>         > > > > technical. That is planned for Tuesday February 23rd at 19:00 UTC on
                >>         > > > > the IRC channel ##taproot-activation.
                >>         > > > >
                >>         > > > > Thanks to the meeting participants (and those who joined the
                >>         > > > > discussion on the channel prior and post the meeting) for engaging
                >>         > > > > productively and in good faith.
                >>         > >
                >>         > > --
                >>         > > Michael Folkson
                >>         > > Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com>
                >>         > > Keybase: michaelfolkson
                >>         > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                >>         > > _______________________________________________
                >>         > > bitcoin-dev mailing list
                >>         > > bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
                >>         > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                >>         <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
                >>
                >>
                >>
                >>
                >>     -- 
                >>     Michael Folkson
                >>     Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com>
                >>     Keybase: michaelfolkson
                >>     PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                >>     _______________________________________________
                >>     bitcoin-dev mailing list
                >>     bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
                >>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                >>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
                > 
                > 
                > 
                > -- 
                > Michael Folkson
                > Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com>
                > Keybase: michaelfolkson
                > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                
                
                ^ permalink raw reply	[flat|nested] 42+ messages in thread

              • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                    2021-02-18 14:42               ` Matt Corallo
                  @ 2021-02-18 14:51                 ` Michael Folkson
                    2021-02-18 14:53                   ` Matt Corallo
                    2021-02-18 15:04                 ` Keagan McClelland
                    1 sibling, 1 reply; 42+ messages in thread
                  From: Michael Folkson @ 2021-02-18 14:51 UTC (permalink / raw)
                    To: Matt Corallo; +Cc: Bitcoin Protocol Discussion
                  
                  [-- Attachment #1: Type: text/plain, Size: 22240 bytes --]
                  
                  > getting unlucky and hitting a 4-block reorg that happens to include a
                  double-spend and some PR around an exchange losing millions would be worse
                  than having Taproot is good.
                  
                  We are at the point where an upgrade that confers significant long term
                  benefits for the whole ecosystem is not as important as bad short term PR?
                  That is a depressing outlook if that is what you believe.
                  
                  Even in that worst case scenario exchanges should not lose money if they
                  are competent and are able to manage that risk.
                  
                  On Thu, Feb 18, 2021 at 2:42 PM Matt Corallo <lf-lists@mattcorallo•com>
                  wrote:
                  
                  > We've had several softforks in Bitcoin which, through the course of their
                  > activation, had a several-block reorg. That
                  > should be indication enough that we need to very carefully consider
                  > activation to ensure we reduce the risk of that as
                  > much as absolutely possible. Again, while I think Taproot is a huge
                  > improvement and am looking forward to being able to
                  > use it, getting unlucky and hitting a 4-block reorg that happens to
                  > include a double-spend and some PR around an
                  > exchange losing millions would be worse than having Taproot is good.
                  >
                  > Matt
                  >
                  > On 2/18/21 09:26, Michael Folkson wrote:
                  > > Thanks for your response Matt. It is a fair challenge. There is always
                  > going to be an element of risk with soft forks,
                  > > all we can do is attempt to minimize that risk. I would argue that risk
                  > has been minimized for Taproot.
                  > >
                  > > You know (better than I do in fact) that Bitcoin (and layers built on
                  > top of it) greatly benefit from upgrades such as
                  > > Taproot. To say we shouldn't do Taproot or any future soft forks because
                  > there is a small but real risk of chain splits
                  > > I think is shortsighted. Indeed I think even if we collectively decided
                  > not to do any future soft fork upgrades ever
                  > > again on this mailing list that wouldn't stop soft fork attempts from
                  > other people in future.
                  > >
                  > > I don't think there is anything else we can do to minimize that risk for
                  > the Taproot soft fork at this point though I'm
                  > > open to ideas. To reiterate that risk will never be zero. I don't think
                  > I see Bitcoin as fragile as you seem to (though
                  > > admittedly you have a much better understanding than me of what happened
                  > in 2017).
                  > >
                  > > The likely scenario for the Taproot soft fork is LOT turns out to be
                  > entirely irrelevant and miners activate Taproot
                  > > before it becomes relevant. And even the unlikely worst case scenario
                  > would only cause short term disruption and
                  > > wouldn't kill Bitcoin long term.
                  > >
                  > > On Thu, Feb 18, 2021 at 2:01 PM Matt Corallo <lf-lists@mattcorallo•com
                  > <mailto:lf-lists@mattcorallo•com>> wrote:
                  > >
                  > >     If the eventual outcome is that different implementations (that have
                  > material *transaction processing* userbases,
                  > >     and I’m not sure to what extent that’s true with Knots) ship
                  > different consensus rules, we should stop here and not
                  > >     activate Taproot. Seriously.
                  > >
                  > >     Bitcoin is a consensus system. The absolute worst outcome at all
                  > possible is to have it fall out of consensus.
                  > >
                  > >     Matt
                  > >
                  > >>     On Feb 18, 2021, at 08:11, Michael Folkson via bitcoin-dev <
                  > bitcoin-dev@lists•linuxfoundation.org
                  > >>     <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
                  > >>
                  > >>     
                  > >>     Right, that is one option. Personally I would prefer a Bitcoin Core
                  > release sets LOT=false (based on what I have
                  > >>     heard from Bitcoin Core contributors) and a community effort
                  > releases a version with LOT=true. I don't think users
                  > >>     should be forced to choose something they may have no context on
                  > before they are allowed to use Bitcoin Core.
                  > >>
                  > >>     My current understanding is that roasbeef is planning to set
                  > LOT=false on btcd (an alternative protocol
                  > >>     implementation to Bitcoin Core) and Luke Dashjr hasn't yet decided
                  > on Bitcoin Knots.
                  > >>
                  > >>
                  > >>
                  > >>     On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <ZmnSCPxj@protonmail•com
                  > <mailto:ZmnSCPxj@protonmail•com>> wrote:
                  > >>
                  > >>         Good morning all,
                  > >>
                  > >>         > "An activation mechanism is a consensus change like any other
                  > change, can be contentious like any other
                  > >>         change, and we must resolve it like any other change. Otherwise
                  > we risk arriving at the darkest timeline."
                  > >>         >
                  > >>         > Who's we here?
                  > >>         >
                  > >>         > Release both and let the network decide.
                  > >>
                  > >>         A thing that could be done, without mandating either LOT=true
                  > or LOT=false, would be to have a release that
                  > >>         requires a `taprootlot=1` or `taprootlot=0` and refuses to
                  > start if the parameter is not set.
                  > >>
                  > >>         This assures everyone that neither choice is being forced on
                  > users, and instead what is being forced on users,
                  > >>         is for users to make that choice themselves.
                  > >>
                  > >>         Regards,
                  > >>         ZmnSCPxj
                  > >>
                  > >>         >
                  > >>         > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via
                  > bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org
                  > >>         <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
                  > >>         >
                  > >>         > > Thanks for your response Ariel. It would be useful if you
                  > responded to specific points I have made in the
                  > >>         mailing list post or at least quote these ephemeral "people"
                  > you speak of. I don't know if you're responding
                  > >>         to conversation on the IRC channel or on social media etc.
                  > >>         > >
                  > >>         > > > The argument comes from a naive assumption that users
                  > MUST upgrade to the choice that is submitted into
                  > >>         code. But in fact this isn't true and some voices in this
                  > discussion need to be more humble about what users
                  > >>         must or must not run.
                  > >>         > >
                  > >>         > > I personally have never made this assumption. Of course
                  > users aren't forced to run any particular software
                  > >>         version, quite the opposite. Defaults set in software versions
                  > matter though as many users won't change them.
                  > >>         > >
                  > >>         > > > Does no one realize that it is a very possible outcome
                  > that if LOT=true is released there may be only a
                  > >>         handful of people that begin running it while everyone else
                  > delays their upgrade (with the very good reason of
                  > >>         not getting involved in politics) and a year later those
                  > handful of people just become stuck at the moment of
                  > >>         MUST_SIGNAL, unable to mine new blocks?
                  > >>         > >
                  > >>         > > It is a possible outcome but the likely outcome is that
                  > miners activate Taproot before LOT is even
                  > >>         relevant. I think it is prudent to prepare for the unlikely but
                  > possible outcome that miners fail to activate
                  > >>         and hence have this discussion now rather than be unprepared
                  > for that eventuality. If LOT is set to false in a
                  > >>         software release there is the possibility (T2 in
                  > >>
                  > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                  > >>         <
                  > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>)
                  > of individuals or a
                  > >>         proportion of the community changing LOT to true. In that sense
                  > setting LOT=false in a software release
                  > >>         appears to be no more safe than LOT=true.
                  > >>         > >
                  > >>         > > > The result: a wasted year of waiting and a minority of
                  > people who didn't want to be lenient with miners
                  > >>         by default.
                  > >>         > >
                  > >>         > > There is the (unlikely but possible) possibility of a
                  > wasted year if LOT is set to false and miners fail
                  > >>         to activate. I'm not convinced by this perception that LOT=true
                  > is antagonistic to miners. I actually think it
                  > >>         offers them clarity on what will happen over a year time period
                  > and removes the need for coordinated or
                  > >>         uncoordinated community UASF efforts on top of LOT=false.
                  > >>         > >
                  > >>         > > > An activation mechanism is a consensus change like any
                  > other change, can be contentious like any other
                  > >>         change, and we must resolve it like any other change. Otherwise
                  > we risk arriving at the darkest timeline.
                  > >>         > >
                  > >>         > > I don't know what you are recommending here to avoid "this
                  > darkest timeline". Open discussions have
                  > >>         occurred and are continuing and in my mailing list post that
                  > you responded to **I recommended we propose
                  > >>         LOT=false be set in protocol implementations such as Bitcoin
                  > Core**. I do think this apocalyptic language
                  > >>         isn't particularly helpful. In an open consensus system
                  > discussion is healthy, we should prepare for bad or
                  > >>         worst case scenarios in advance and doing so is not
                  > antagonistic or destructive. Mining pools have pledged
                  > >>         support for Taproot but we don't build secure systems based on
                  > pledges of support, we build them to minimize
                  > >>         trust in any human actors. We can be grateful that people like
                  > Alejandro have worked hard on
                  > >>         taprootactivation.com <http://taprootactivation.com> (and this
                  > effort has informed the discussion) without
                  > >>         taking pledges of support as cast iron guarantees.
                  > >>         > >
                  > >>         > > TL;DR It sounds like you agree with my recommendation to
                  > set LOT=false in protocol implementations in my
                  > >>         email :)
                  > >>         > >
                  > >>         > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <
                  > arielluaces@gmail•com
                  > >>         <mailto:arielluaces@gmail•com>> wrote:
                  > >>         > >
                  > >>         > > > Something what strikes me about the conversation is the
                  > emotion surrounding the letters UASF.
                  > >>         > > > It appears as if people discuss UASF as if it's a massive
                  > tidal wave of support that is inevitable, like
                  > >>         we saw during segwit activation. But the actual definition is
                  > "any activation that is not a MASF".
                  > >>         > > > A UASF can consist of a single node, ten nodes, a
                  > thousand, half of all nodes, all business' nodes, or
                  > >>         even all the non mining nodes. On another dimension it can have
                  > zero mining support, 51% support, 49% support,
                  > >>         or any support right up against a miner activation threshold.
                  > >>         > > > Hell a UASF doesn't even need code or even a single node
                  > running as long as it exists as a possibility
                  > >>         in people's minds.
                  > >>         > > > The only thing a UASF doesn't have is miner support above
                  > an agreed activation threshold (some number
                  > >>         above %51).
                  > >>         > > > I say this because it strikes me when people say that
                  > they are for LOT=true with the logic that since a
                  > >>         UASF is guaranteed to happen then it's better to just make it
                  > default from the beginning. Words like
                  > >>         coordination and safety are sometimes sprinkled into the
                  > argument.
                  > >>         > > > The argument comes from a naive assumption that users
                  > MUST upgrade to the choice that is submitted into
                  > >>         code. But in fact this isn't true and some voices in this
                  > discussion need to be more humble about what users
                  > >>         must or must not run.
                  > >>         > > > Does no one realize that it is a very possible outcome
                  > that if LOT=true is released there may be only a
                  > >>         handful of people that begin running it while everyone else
                  > delays their upgrade (with the very good reason of
                  > >>         not getting involved in politics) and a year later those
                  > handful of people just become stuck at the moment of
                  > >>         MUST_SIGNAL, unable to mine new blocks? Or attracting a
                  > minority of miners, activating, and forking off into a
                  > >>         minority fork. Then a lot=false could be started that ends up
                  > activating the feature now that the stubborn
                  > >>         option has ran its course.
                  > >>         > > > The result: a wasted year of waiting and a minority of
                  > people who didn't want to be lenient with miners
                  > >>         by default. The chains could be called BitcoinLenient and
                  > BitcoinStubborn.
                  > >>         > > > How is that strictly safer or more coordinated?
                  > >>         > > > I may be in the minority, or maybe a silent majority, or
                  > maybe a majority that just hasn't considered
                  > >>         this as a choice but honestly if there is contention about
                  > whether we're going to be stubborn or lenient with
                  > >>         miners for Taproot and in the future then I prefer to just not
                  > activate anything at all. I'm fine for calling
                  > >>         bitcoin ossified, accepting that segwit is Bitcoin's last
                  > network upgrade. Taproot is amazing but no new
                  > >>         feature is worth a network split down the middle.
                  > >>         > > > Maybe in 10 or 20 years, when other blockchains implement
                  > features like Taproot and many more, we will
                  > >>         become envious enough to put aside our differences on how to
                  > behave towards miners and finally activate Taproot.
                  > >>         > > > An activation mechanism is a consensus change like any
                  > other change, can be contentious like any other
                  > >>         change, and we must resolve it like any other change. Otherwise
                  > we risk arriving at the darkest timeline.
                  > >>         > > > Cheers
                  > >>         > > > Ariel Lorenzo-Luaces
                  > >>         > > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via
                  > bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org
                  > >>         <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
                  > >>         > > >
                  > >>         > > > > Yesterday (February 16th) we held a second meeting on
                  > Taproot
                  > >>         > > > > activation on IRC which again was open to all. Despite
                  > what appeared
                  > >>         > > > > to be majority support for LOT=false over LOT=true in
                  > the first
                  > >>         > > > > meeting I (and others) thought the arguments had not
                  > been explored in
                  > >>         > > > > depth and that we should have a follow up meeting
                  > almost entirely
                  > >>         > > > > focused on whether LOT (lockinontimeout) should be set
                  > to true or
                  > >>         > > > > false.
                  > >>         > > > >
                  > >>         > > > > The meeting was announced here:
                  > >>         > > > >
                  > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                  > >>         <
                  > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                  > >
                  > >>         > > > >
                  > >>         > > > > In that mailing list post I outlined the arguments for
                  > LOT=true (T1 to
                  > >>         > > > > T6) and arguments for LOT=false (F1 to F6) in their
                  > strongest form I
                  > >>         > > > > could. David Harding responded with an additional
                  > argument for
                  > >>         > > > > LOT=false (F7) here:
                  > >>         > > > >
                  > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
                  > >>         <
                  > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
                  > >
                  > >>         > > > >
                  > >>         > > > > These meetings are very challenging given they are open
                  > to all, you
                  > >>         > > > > don’t know who will attend and you don’t know most
                  > people’s views in
                  > >>         > > > > advance. I tried to give time for both the LOT=true
                  > arguments and the
                  > >>         > > > > LOT=false arguments to be discussed as I knew there was
                  > support for
                  > >>         > > > > both. We only tried evaluating which had more support
                  > and which had
                  > >>         > > > > more strong opposition towards the end of the meeting.
                  > >>         > > > >
                  > >>         > > > > The conversation log is here:
                  > >>         > > > > http://gnusha.org/taproot-activation/2021-02-16.log <
                  > http://gnusha.org/taproot-activation/2021-02-16.log>
                  > >>         > > > >
                  > >>         > > > > (If you are so inclined you can watch a video of the
                  > meeting here.
                  > >>         > > > > Thanks to the YouTube account “Bitcoin” for setting up
                  > the livestream:
                  > >>         > > > > https://www.youtube.com/watch?v=vpl5q1ovMLM <
                  > https://www.youtube.com/watch?v=vpl5q1ovMLM>)
                  > >>         > > > >
                  > >>         > > > > A summary of the meeting was provided by Luke Dashjr on
                  > Mastodon here:
                  > >>         > > > >
                  > https://bitcoinhackers.org/@lukedashjr/105742918779234566
                  > >>         <https://bitcoinhackers.org/@lukedashjr/105742918779234566>
                  > >>         > > > >
                  > >>         > > > > Today's #Bitcoin #Taproot meeting was IMO largely
                  > unproductive, but we
                  > >>         > > > > did manage to come to consensus on everything but
                  > LockinOnTimeout.
                  > >>         > > > >
                  > >>         > > > > Activation height range: 693504-745920
                  > >>         > > > >
                  > >>         > > > > MASF threshold: 1815/2016 blocks (90%)
                  > >>         > > > >
                  > >>         > > > > Keep in mind only ~100 people showed for the meetings,
                  > hardly
                  > >>         > > > > representative of the entire community.
                  > >>         > > > >
                  > >>         > > > > So, these details remain JUST a proposal for now.
                  > >>         > > > >
                  > >>         > > > > It seems inevitable that there won't be consensus on
                  > LOT.
                  > >>         > > > >
                  > >>         > > > > Everyone will have to choose for himself. :/
                  > >>         > > > >
                  > >>         > > > > Personally I agree with most of this. I agree that
                  > there wasn’t
                  > >>         > > > > overwhelming consensus for either LOT=true or
                  > LOT=false. However, from
                  > >>         > > > > my perspective there was clearly more strong opposition
                  > (what would
                  > >>         > > > > usually be deemed a NACK in Bitcoin Core review
                  > terminology) from
                  > >>         > > > > Bitcoin Core contributors, Lightning developers and
                  > other community
                  > >>         > > > > members against LOT=true than there was for LOT=false.
                  > Andrew Chow
                  > >>         > > > > tried to summarize views from the meeting in this
                  > analysis:
                  > >>         > > > >
                  > https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
                  > >>         <
                  > https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>
                  > >>         > > > >
                  > >>         > > > > I am also aware of other current and previous Bitcoin
                  > Core
                  > >>         > > > > contributors and Lightning developers who didn’t attend
                  > the meeting in
                  > >>         > > > > person who are opposed to LOT=true. I don’t want to put
                  > them in the
                  > >>         > > > > spotlight for no reason but if you go through the
                  > conversation logs of
                  > >>         > > > > not only the meeting but the weeks of discussion prior
                  > to this meeting
                  > >>         > > > > you will see their views evaluated on the
                  > ##taproot-activation
                  > >>         > > > > channel. In addition, on taprootactivation.com <
                  > http://taprootactivation.com> some mining pools
                  > >>         > > > > expressed a preference for lot=false though I don’t
                  > know how strong
                  > >>         > > > > that preference was.
                  > >>         > > > >
                  > >>         > > > > I am only one voice but it is my current assessment
                  > that if we are to
                  > >>         > > > > attempt to finalize Taproot activation parameters and
                  > propose them to
                  > >>         > > > > the community at this time our only option is to
                  > propose LOT=false.
                  > >>         > > > > Any further delay appears to me counterproductive in
                  > our collective
                  > >>         > > > > aim to get the Taproot soft fork activated as early as
                  > possible.
                  > >>         > > > >
                  > >>         > > > > Obviously others are free to disagree with that
                  > assessment and
                  > >>         > > > > continue discussions but personally I will be
                  > attempting to avoid
                  > >>         > > > > those discussions unless prominent new information
                  > comes to light or
                  > >>         > > > > various specific individuals change their minds.
                  > >>         > > > >
                  > >>         > > > > Next week we are planning a code review of the Bitcoin
                  > Core PR #19573
                  > >>         > > > > which was initially delayed because of this LOT
                  > discussion. As I’ve
                  > >>         > > > > said previously that will be loosely following the
                  > format of the
                  > >>         > > > > Bitcoin Core PR review club and will be lower level and
                  > more
                  > >>         > > > > technical. That is planned for Tuesday February 23rd at
                  > 19:00 UTC on
                  > >>         > > > > the IRC channel ##taproot-activation.
                  > >>         > > > >
                  > >>         > > > > Thanks to the meeting participants (and those who
                  > joined the
                  > >>         > > > > discussion on the channel prior and post the meeting)
                  > for engaging
                  > >>         > > > > productively and in good faith.
                  > >>         > >
                  > >>         > > --
                  > >>         > > Michael Folkson
                  > >>         > > Email: michaelfolkson@gmail•com <mailto:
                  > michaelfolkson@gmail•com>
                  > >>         > > Keybase: michaelfolkson
                  > >>         > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                  > >>         > > _______________________________________________
                  > >>         > > bitcoin-dev mailing list
                  > >>         > > bitcoin-dev@lists•linuxfoundation.org <mailto:
                  > bitcoin-dev@lists•linuxfoundation.org>
                  > >>         > >
                  > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                  > >>         <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                  > >
                  > >>
                  > >>
                  > >>
                  > >>
                  > >>     --
                  > >>     Michael Folkson
                  > >>     Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com>
                  > >>     Keybase: michaelfolkson
                  > >>     PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                  > >>     _______________________________________________
                  > >>     bitcoin-dev mailing list
                  > >>     bitcoin-dev@lists•linuxfoundation.org <mailto:
                  > bitcoin-dev@lists•linuxfoundation.org>
                  > >>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                  > >>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
                  > >
                  > >
                  > >
                  > > --
                  > > Michael Folkson
                  > > Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com>
                  > > Keybase: michaelfolkson
                  > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                  >
                  
                  
                  -- 
                  Michael Folkson
                  Email: michaelfolkson@gmail•com
                  Keybase: michaelfolkson
                  PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                  
                  [-- Attachment #2: Type: text/html, Size: 31620 bytes --]
                  
                  ^ permalink raw reply	[flat|nested] 42+ messages in thread

                • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                      2021-02-18 14:51                 ` Michael Folkson
                    @ 2021-02-18 14:53                   ` Matt Corallo
                      2021-02-18 15:01                     ` Matt Corallo
                      0 siblings, 1 reply; 42+ messages in thread
                    From: Matt Corallo @ 2021-02-18 14:53 UTC (permalink / raw)
                      To: Michael Folkson; +Cc: Bitcoin Protocol Discussion
                    
                    You say "short term PR", I say "risking millions of user dollars".
                    
                    On 2/18/21 09:51, Michael Folkson wrote:
                    >  > getting unlucky and hitting a 4-block reorg that happens to include a double-spend and some PR around an exchange 
                    > losing millions would be worse than having Taproot is good.
                    > 
                    > We are at the point where an upgrade that confers significant long term benefits for the whole ecosystem is not as 
                    > important as bad short term PR? That is a depressing outlook if that is what you believe.
                    > 
                    > Even in that worst case scenario exchanges should not lose money if they are competent and are able to manage that risk.
                    > 
                    > On Thu, Feb 18, 2021 at 2:42 PM Matt Corallo <lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo•com>> wrote:
                    > 
                    >     We've had several softforks in Bitcoin which, through the course of their activation, had a several-block reorg. That
                    >     should be indication enough that we need to very carefully consider activation to ensure we reduce the risk of that as
                    >     much as absolutely possible. Again, while I think Taproot is a huge improvement and am looking forward to being able to
                    >     use it, getting unlucky and hitting a 4-block reorg that happens to include a double-spend and some PR around an
                    >     exchange losing millions would be worse than having Taproot is good.
                    > 
                    >     Matt
                    > 
                    >     On 2/18/21 09:26, Michael Folkson wrote:
                    >      > Thanks for your response Matt. It is a fair challenge. There is always going to be an element of risk with soft
                    >     forks,
                    >      > all we can do is attempt to minimize that risk. I would argue that risk has been minimized for Taproot.
                    >      >
                    >      > You know (better than I do in fact) that Bitcoin (and layers built on top of it) greatly benefit from upgrades
                    >     such as
                    >      > Taproot. To say we shouldn't do Taproot or any future soft forks because there is a small but real risk of chain
                    >     splits
                    >      > I think is shortsighted. Indeed I think even if we collectively decided not to do any future soft fork upgrades ever
                    >      > again on this mailing list that wouldn't stop soft fork attempts from other people in future.
                    >      >
                    >      > I don't think there is anything else we can do to minimize that risk for the Taproot soft fork at this point
                    >     though I'm
                    >      > open to ideas. To reiterate that risk will never be zero. I don't think I see Bitcoin as fragile as you seem to
                    >     (though
                    >      > admittedly you have a much better understanding than me of what happened in 2017).
                    >      >
                    >      > The likely scenario for the Taproot soft fork is LOT turns out to be entirely irrelevant and miners activate Taproot
                    >      > before it becomes relevant. And even the unlikely worst case scenario would only cause short term disruption and
                    >      > wouldn't kill Bitcoin long term.
                    >      >
                    >      > On Thu, Feb 18, 2021 at 2:01 PM Matt Corallo <lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo•com>
                    >     <mailto:lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo•com>>> wrote:
                    >      >
                    >      >     If the eventual outcome is that different implementations (that have material *transaction processing* userbases,
                    >      >     and I’m not sure to what extent that’s true with Knots) ship different consensus rules, we should stop here
                    >     and not
                    >      >     activate Taproot. Seriously.
                    >      >
                    >      >     Bitcoin is a consensus system. The absolute worst outcome at all possible is to have it fall out of consensus.
                    >      >
                    >      >     Matt
                    >      >
                    >      >>     On Feb 18, 2021, at 08:11, Michael Folkson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org
                    >     <mailto:bitcoin-dev@lists•linuxfoundation.org>
                    >      >>     <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>> wrote:
                    >      >>
                    >      >>     
                    >      >>     Right, that is one option. Personally I would prefer a Bitcoin Core release sets LOT=false (based on what I have
                    >      >>     heard from Bitcoin Core contributors) and a community effort releases a version with LOT=true. I don't think
                    >     users
                    >      >>     should be forced to choose something they may have no context on before they are allowed to use Bitcoin Core.
                    >      >>
                    >      >>     My current understanding is that roasbeef is planning to set LOT=false on btcd (an alternative protocol
                    >      >>     implementation to Bitcoin Core) and Luke Dashjr hasn't yet decided on Bitcoin Knots.
                    >      >>
                    >      >>
                    >      >>
                    >      >>     On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <ZmnSCPxj@protonmail•com <mailto:ZmnSCPxj@protonmail•com>
                    >     <mailto:ZmnSCPxj@protonmail•com <mailto:ZmnSCPxj@protonmail•com>>> wrote:
                    >      >>
                    >      >>         Good morning all,
                    >      >>
                    >      >>         > "An activation mechanism is a consensus change like any other change, can be contentious like any other
                    >      >>         change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline."
                    >      >>         >
                    >      >>         > Who's we here?
                    >      >>         >
                    >      >>         > Release both and let the network decide.
                    >      >>
                    >      >>         A thing that could be done, without mandating either LOT=true or LOT=false, would be to have a release that
                    >      >>         requires a `taprootlot=1` or `taprootlot=0` and refuses to start if the parameter is not set.
                    >      >>
                    >      >>         This assures everyone that neither choice is being forced on users, and instead what is being forced on
                    >     users,
                    >      >>         is for users to make that choice themselves.
                    >      >>
                    >      >>         Regards,
                    >      >>         ZmnSCPxj
                    >      >>
                    >      >>         >
                    >      >>         > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org
                    >     <mailto:bitcoin-dev@lists•linuxfoundation.org>
                    >      >>         <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>> wrote:
                    >      >>         >
                    >      >>         > > Thanks for your response Ariel. It would be useful if you responded to specific points I have made
                    >     in the
                    >      >>         mailing list post or at least quote these ephemeral "people" you speak of. I don't know if you're responding
                    >      >>         to conversation on the IRC channel or on social media etc.
                    >      >>         > >
                    >      >>         > > > The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted
                    >     into
                    >      >>         code. But in fact this isn't true and some voices in this discussion need to be more humble about what users
                    >      >>         must or must not run.
                    >      >>         > >
                    >      >>         > > I personally have never made this assumption. Of course users aren't forced to run any particular
                    >     software
                    >      >>         version, quite the opposite. Defaults set in software versions matter though as many users won't change
                    >     them.
                    >      >>         > >
                    >      >>         > > > Does no one realize that it is a very possible outcome that if LOT=true is released there may be
                    >     only a
                    >      >>         handful of people that begin running it while everyone else delays their upgrade (with the very good
                    >     reason of
                    >      >>         not getting involved in politics) and a year later those handful of people just become stuck at the
                    >     moment of
                    >      >>         MUST_SIGNAL, unable to mine new blocks?
                    >      >>         > >
                    >      >>         > > It is a possible outcome but the likely outcome is that miners activate Taproot before LOT is even
                    >      >>         relevant. I think it is prudent to prepare for the unlikely but possible outcome that miners fail to
                    >     activate
                    >      >>         and hence have this discussion now rather than be unprepared for that eventuality. If LOT is set to
                    >     false in a
                    >      >>         software release there is the possibility (T2 in
                    >      >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                    >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>
                    >      >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                    >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>>) of individuals or a
                    >      >>         proportion of the community changing LOT to true. In that sense setting LOT=false in a software release
                    >      >>         appears to be no more safe than LOT=true.
                    >      >>         > >
                    >      >>         > > > The result: a wasted year of waiting and a minority of people who didn't want to be lenient with
                    >     miners
                    >      >>         by default.
                    >      >>         > >
                    >      >>         > > There is the (unlikely but possible) possibility of a wasted year if LOT is set to false and miners fail
                    >      >>         to activate. I'm not convinced by this perception that LOT=true is antagonistic to miners. I actually
                    >     think it
                    >      >>         offers them clarity on what will happen over a year time period and removes the need for coordinated or
                    >      >>         uncoordinated community UASF efforts on top of LOT=false.
                    >      >>         > >
                    >      >>         > > > An activation mechanism is a consensus change like any other change, can be contentious like any other
                    >      >>         change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
                    >      >>         > >
                    >      >>         > > I don't know what you are recommending here to avoid "this darkest timeline". Open discussions have
                    >      >>         occurred and are continuing and in my mailing list post that you responded to **I recommended we propose
                    >      >>         LOT=false be set in protocol implementations such as Bitcoin Core**. I do think this apocalyptic language
                    >      >>         isn't particularly helpful. In an open consensus system discussion is healthy, we should prepare for bad or
                    >      >>         worst case scenarios in advance and doing so is not antagonistic or destructive. Mining pools have pledged
                    >      >>         support for Taproot but we don't build secure systems based on pledges of support, we build them to minimize
                    >      >>         trust in any human actors. We can be grateful that people like Alejandro have worked hard on
                    >      >> taprootactivation.com <http://taprootactivation.com> <http://taprootactivation.com
                    >     <http://taprootactivation.com>> (and this effort has informed the discussion) without
                    >      >>         taking pledges of support as cast iron guarantees.
                    >      >>         > >
                    >      >>         > > TL;DR It sounds like you agree with my recommendation to set LOT=false in protocol implementations in my
                    >      >>         email :)
                    >      >>         > >
                    >      >>         > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <arielluaces@gmail•com
                    >     <mailto:arielluaces@gmail•com>
                    >      >>         <mailto:arielluaces@gmail•com <mailto:arielluaces@gmail•com>>> wrote:
                    >      >>         > >
                    >      >>         > > > Something what strikes me about the conversation is the emotion surrounding the letters UASF.
                    >      >>         > > > It appears as if people discuss UASF as if it's a massive tidal wave of support that is
                    >     inevitable, like
                    >      >>         we saw during segwit activation. But the actual definition is "any activation that is not a MASF".
                    >      >>         > > > A UASF can consist of a single node, ten nodes, a thousand, half of all nodes, all business' nodes, or
                    >      >>         even all the non mining nodes. On another dimension it can have zero mining support, 51% support, 49%
                    >     support,
                    >      >>         or any support right up against a miner activation threshold.
                    >      >>         > > > Hell a UASF doesn't even need code or even a single node running as long as it exists as a possibility
                    >      >>         in people's minds.
                    >      >>         > > > The only thing a UASF doesn't have is miner support above an agreed activation threshold (some number
                    >      >>         above %51).
                    >      >>         > > > I say this because it strikes me when people say that they are for LOT=true with the logic that
                    >     since a
                    >      >>         UASF is guaranteed to happen then it's better to just make it default from the beginning. Words like
                    >      >>         coordination and safety are sometimes sprinkled into the argument.
                    >      >>         > > > The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted
                    >     into
                    >      >>         code. But in fact this isn't true and some voices in this discussion need to be more humble about what users
                    >      >>         must or must not run.
                    >      >>         > > > Does no one realize that it is a very possible outcome that if LOT=true is released there may be
                    >     only a
                    >      >>         handful of people that begin running it while everyone else delays their upgrade (with the very good
                    >     reason of
                    >      >>         not getting involved in politics) and a year later those handful of people just become stuck at the
                    >     moment of
                    >      >>         MUST_SIGNAL, unable to mine new blocks? Or attracting a minority of miners, activating, and forking off
                    >     into a
                    >      >>         minority fork. Then a lot=false could be started that ends up activating the feature now that the stubborn
                    >      >>         option has ran its course.
                    >      >>         > > > The result: a wasted year of waiting and a minority of people who didn't want to be lenient with
                    >     miners
                    >      >>         by default. The chains could be called BitcoinLenient and BitcoinStubborn.
                    >      >>         > > > How is that strictly safer or more coordinated?
                    >      >>         > > > I may be in the minority, or maybe a silent majority, or maybe a majority that just hasn't considered
                    >      >>         this as a choice but honestly if there is contention about whether we're going to be stubborn or lenient
                    >     with
                    >      >>         miners for Taproot and in the future then I prefer to just not activate anything at all. I'm fine for
                    >     calling
                    >      >>         bitcoin ossified, accepting that segwit is Bitcoin's last network upgrade. Taproot is amazing but no new
                    >      >>         feature is worth a network split down the middle.
                    >      >>         > > > Maybe in 10 or 20 years, when other blockchains implement features like Taproot and many more, we will
                    >      >>         become envious enough to put aside our differences on how to behave towards miners and finally activate
                    >     Taproot.
                    >      >>         > > > An activation mechanism is a consensus change like any other change, can be contentious like any other
                    >      >>         change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
                    >      >>         > > > Cheers
                    >      >>         > > > Ariel Lorenzo-Luaces
                    >      >>         > > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev
                    >     <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
                    >      >>         <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>> wrote:
                    >      >>         > > >
                    >      >>         > > > > Yesterday (February 16th) we held a second meeting on Taproot
                    >      >>         > > > > activation on IRC which again was open to all. Despite what appeared
                    >      >>         > > > > to be majority support for LOT=false over LOT=true in the first
                    >      >>         > > > > meeting I (and others) thought the arguments had not been explored in
                    >      >>         > > > > depth and that we should have a follow up meeting almost entirely
                    >      >>         > > > > focused on whether LOT (lockinontimeout) should be set to true or
                    >      >>         > > > > false.
                    >      >>         > > > >
                    >      >>         > > > > The meeting was announced here:
                    >      >>         > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                    >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>
                    >      >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                    >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>>
                    >      >>         > > > >
                    >      >>         > > > > In that mailing list post I outlined the arguments for LOT=true (T1 to
                    >      >>         > > > > T6) and arguments for LOT=false (F1 to F6) in their strongest form I
                    >      >>         > > > > could. David Harding responded with an additional argument for
                    >      >>         > > > > LOT=false (F7) here:
                    >      >>         > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
                    >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html>
                    >      >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
                    >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html>>
                    >      >>         > > > >
                    >      >>         > > > > These meetings are very challenging given they are open to all, you
                    >      >>         > > > > don’t know who will attend and you don’t know most people’s views in
                    >      >>         > > > > advance. I tried to give time for both the LOT=true arguments and the
                    >      >>         > > > > LOT=false arguments to be discussed as I knew there was support for
                    >      >>         > > > > both. We only tried evaluating which had more support and which had
                    >      >>         > > > > more strong opposition towards the end of the meeting.
                    >      >>         > > > >
                    >      >>         > > > > The conversation log is here:
                    >      >>         > > > > http://gnusha.org/taproot-activation/2021-02-16.log
                    >     <http://gnusha.org/taproot-activation/2021-02-16.log> <http://gnusha.org/taproot-activation/2021-02-16.log
                    >     <http://gnusha.org/taproot-activation/2021-02-16.log>>
                    >      >>         > > > >
                    >      >>         > > > > (If you are so inclined you can watch a video of the meeting here.
                    >      >>         > > > > Thanks to the YouTube account “Bitcoin” for setting up the livestream:
                    >      >>         > > > > https://www.youtube.com/watch?v=vpl5q1ovMLM <https://www.youtube.com/watch?v=vpl5q1ovMLM>
                    >     <https://www.youtube.com/watch?v=vpl5q1ovMLM <https://www.youtube.com/watch?v=vpl5q1ovMLM>>)
                    >      >>         > > > >
                    >      >>         > > > > A summary of the meeting was provided by Luke Dashjr on Mastodon here:
                    >      >>         > > > > https://bitcoinhackers.org/@lukedashjr/105742918779234566
                    >     <https://bitcoinhackers.org/@lukedashjr/105742918779234566>
                    >      >>         <https://bitcoinhackers.org/@lukedashjr/105742918779234566
                    >     <https://bitcoinhackers.org/@lukedashjr/105742918779234566>>
                    >      >>         > > > >
                    >      >>         > > > > Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we
                    >      >>         > > > > did manage to come to consensus on everything but LockinOnTimeout.
                    >      >>         > > > >
                    >      >>         > > > > Activation height range: 693504-745920
                    >      >>         > > > >
                    >      >>         > > > > MASF threshold: 1815/2016 blocks (90%)
                    >      >>         > > > >
                    >      >>         > > > > Keep in mind only ~100 people showed for the meetings, hardly
                    >      >>         > > > > representative of the entire community.
                    >      >>         > > > >
                    >      >>         > > > > So, these details remain JUST a proposal for now.
                    >      >>         > > > >
                    >      >>         > > > > It seems inevitable that there won't be consensus on LOT.
                    >      >>         > > > >
                    >      >>         > > > > Everyone will have to choose for himself. :/
                    >      >>         > > > >
                    >      >>         > > > > Personally I agree with most of this. I agree that there wasn’t
                    >      >>         > > > > overwhelming consensus for either LOT=true or LOT=false. However, from
                    >      >>         > > > > my perspective there was clearly more strong opposition (what would
                    >      >>         > > > > usually be deemed a NACK in Bitcoin Core review terminology) from
                    >      >>         > > > > Bitcoin Core contributors, Lightning developers and other community
                    >      >>         > > > > members against LOT=true than there was for LOT=false. Andrew Chow
                    >      >>         > > > > tried to summarize views from the meeting in this analysis:
                    >      >>         > > > > https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
                    >     <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>
                    >      >>         <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
                    >     <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>>
                    >      >>         > > > >
                    >      >>         > > > > I am also aware of other current and previous Bitcoin Core
                    >      >>         > > > > contributors and Lightning developers who didn’t attend the meeting in
                    >      >>         > > > > person who are opposed to LOT=true. I don’t want to put them in the
                    >      >>         > > > > spotlight for no reason but if you go through the conversation logs of
                    >      >>         > > > > not only the meeting but the weeks of discussion prior to this meeting
                    >      >>         > > > > you will see their views evaluated on the ##taproot-activation
                    >      >>         > > > > channel. In addition, on taprootactivation.com <http://taprootactivation.com>
                    >     <http://taprootactivation.com <http://taprootactivation.com>> some mining pools
                    >      >>         > > > > expressed a preference for lot=false though I don’t know how strong
                    >      >>         > > > > that preference was.
                    >      >>         > > > >
                    >      >>         > > > > I am only one voice but it is my current assessment that if we are to
                    >      >>         > > > > attempt to finalize Taproot activation parameters and propose them to
                    >      >>         > > > > the community at this time our only option is to propose LOT=false.
                    >      >>         > > > > Any further delay appears to me counterproductive in our collective
                    >      >>         > > > > aim to get the Taproot soft fork activated as early as possible.
                    >      >>         > > > >
                    >      >>         > > > > Obviously others are free to disagree with that assessment and
                    >      >>         > > > > continue discussions but personally I will be attempting to avoid
                    >      >>         > > > > those discussions unless prominent new information comes to light or
                    >      >>         > > > > various specific individuals change their minds.
                    >      >>         > > > >
                    >      >>         > > > > Next week we are planning a code review of the Bitcoin Core PR #19573
                    >      >>         > > > > which was initially delayed because of this LOT discussion. As I’ve
                    >      >>         > > > > said previously that will be loosely following the format of the
                    >      >>         > > > > Bitcoin Core PR review club and will be lower level and more
                    >      >>         > > > > technical. That is planned for Tuesday February 23rd at 19:00 UTC on
                    >      >>         > > > > the IRC channel ##taproot-activation.
                    >      >>         > > > >
                    >      >>         > > > > Thanks to the meeting participants (and those who joined the
                    >      >>         > > > > discussion on the channel prior and post the meeting) for engaging
                    >      >>         > > > > productively and in good faith.
                    >      >>         > >
                    >      >>         > > --
                    >      >>         > > Michael Folkson
                    >      >>         > > Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com> <mailto:michaelfolkson@gmail•com
                    >     <mailto:michaelfolkson@gmail•com>>
                    >      >>         > > Keybase: michaelfolkson
                    >      >>         > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                    >      >>         > > _______________________________________________
                    >      >>         > > bitcoin-dev mailing list
                    >      >>         > > bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
                    >     <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>
                    >      >>         > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                    >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
                    >      >>         <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                    >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>>
                    >      >>
                    >      >>
                    >      >>
                    >      >>
                    >      >>     --
                    >      >>     Michael Folkson
                    >      >>     Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com> <mailto:michaelfolkson@gmail•com
                    >     <mailto:michaelfolkson@gmail•com>>
                    >      >>     Keybase: michaelfolkson
                    >      >>     PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                    >      >>     _______________________________________________
                    >      >>     bitcoin-dev mailing list
                    >      >> bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
                    >     <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>
                    >      >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                    >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
                    >      >>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                    >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>>
                    >      >
                    >      >
                    >      >
                    >      > --
                    >      > Michael Folkson
                    >      > Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com> <mailto:michaelfolkson@gmail•com
                    >     <mailto:michaelfolkson@gmail•com>>
                    >      > Keybase: michaelfolkson
                    >      > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                    > 
                    > 
                    > 
                    > -- 
                    > Michael Folkson
                    > Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com>
                    > Keybase: michaelfolkson
                    > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                    
                    
                    ^ permalink raw reply	[flat|nested] 42+ messages in thread

                  • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                        2021-02-18 14:53                   ` Matt Corallo
                      @ 2021-02-18 15:01                     ` Matt Corallo
                        0 siblings, 0 replies; 42+ messages in thread
                      From: Matt Corallo @ 2021-02-18 15:01 UTC (permalink / raw)
                        To: Bitcoin Protocol Discussion, Michael Folkson
                      
                      To ensure we're on the same page, here - I'm not advocating we give up on Taproot. Indeed, without having dug deep into 
                      the issue, my overall impression is that Knots has a tiny transaction-processing userbase and it likely isn't worth 
                      giving deep thought to whether it forks itself off from the network or not. My point is that, if it were the case that 
                      various implementations of Bitcoin's consensus that have material userbases were to release either a configurable 
                      consensus mechanism (without incredible care being given to it, not just a "we can't decide, whatever" argument) or a 
                      different consensus, we'd be much, much better off not having Taproot at all.
                      
                      Matt
                      
                      On 2/18/21 09:53, Matt Corallo via bitcoin-dev wrote:
                      > You say "short term PR", I say "risking millions of user dollars".
                      > 
                      > On 2/18/21 09:51, Michael Folkson wrote:
                      >>  > getting unlucky and hitting a 4-block reorg that happens to include a double-spend and some PR around an exchange 
                      >> losing millions would be worse than having Taproot is good.
                      >>
                      >> We are at the point where an upgrade that confers significant long term benefits for the whole ecosystem is not as 
                      >> important as bad short term PR? That is a depressing outlook if that is what you believe.
                      >>
                      >> Even in that worst case scenario exchanges should not lose money if they are competent and are able to manage that risk.
                      >>
                      >> On Thu, Feb 18, 2021 at 2:42 PM Matt Corallo <lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo•com>> wrote:
                      >>
                      >>     We've had several softforks in Bitcoin which, through the course of their activation, had a several-block reorg. That
                      >>     should be indication enough that we need to very carefully consider activation to ensure we reduce the risk of 
                      >> that as
                      >>     much as absolutely possible. Again, while I think Taproot is a huge improvement and am looking forward to being 
                      >> able to
                      >>     use it, getting unlucky and hitting a 4-block reorg that happens to include a double-spend and some PR around an
                      >>     exchange losing millions would be worse than having Taproot is good.
                      >>
                      >>     Matt
                      >>
                      >>     On 2/18/21 09:26, Michael Folkson wrote:
                      >>      > Thanks for your response Matt. It is a fair challenge. There is always going to be an element of risk with soft
                      >>     forks,
                      >>      > all we can do is attempt to minimize that risk. I would argue that risk has been minimized for Taproot.
                      >>      >
                      >>      > You know (better than I do in fact) that Bitcoin (and layers built on top of it) greatly benefit from upgrades
                      >>     such as
                      >>      > Taproot. To say we shouldn't do Taproot or any future soft forks because there is a small but real risk of chain
                      >>     splits
                      >>      > I think is shortsighted. Indeed I think even if we collectively decided not to do any future soft fork upgrades 
                      >> ever
                      >>      > again on this mailing list that wouldn't stop soft fork attempts from other people in future.
                      >>      >
                      >>      > I don't think there is anything else we can do to minimize that risk for the Taproot soft fork at this point
                      >>     though I'm
                      >>      > open to ideas. To reiterate that risk will never be zero. I don't think I see Bitcoin as fragile as you seem to
                      >>     (though
                      >>      > admittedly you have a much better understanding than me of what happened in 2017).
                      >>      >
                      >>      > The likely scenario for the Taproot soft fork is LOT turns out to be entirely irrelevant and miners activate 
                      >> Taproot
                      >>      > before it becomes relevant. And even the unlikely worst case scenario would only cause short term disruption and
                      >>      > wouldn't kill Bitcoin long term.
                      >>      >
                      >>      > On Thu, Feb 18, 2021 at 2:01 PM Matt Corallo <lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo•com>
                      >>     <mailto:lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo•com>>> wrote:
                      >>      >
                      >>      >     If the eventual outcome is that different implementations (that have material *transaction processing* 
                      >> userbases,
                      >>      >     and I’m not sure to what extent that’s true with Knots) ship different consensus rules, we should stop here
                      >>     and not
                      >>      >     activate Taproot. Seriously.
                      >>      >
                      >>      >     Bitcoin is a consensus system. The absolute worst outcome at all possible is to have it fall out of consensus.
                      >>      >
                      >>      >     Matt
                      >>      >
                      >>      >>     On Feb 18, 2021, at 08:11, Michael Folkson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org
                      >>     <mailto:bitcoin-dev@lists•linuxfoundation.org>
                      >>      >>     <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>> wrote:
                      >>      >>
                      >>      >>     
                      >>      >>     Right, that is one option. Personally I would prefer a Bitcoin Core release sets LOT=false (based on what 
                      >> I have
                      >>      >>     heard from Bitcoin Core contributors) and a community effort releases a version with LOT=true. I don't think
                      >>     users
                      >>      >>     should be forced to choose something they may have no context on before they are allowed to use Bitcoin Core.
                      >>      >>
                      >>      >>     My current understanding is that roasbeef is planning to set LOT=false on btcd (an alternative protocol
                      >>      >>     implementation to Bitcoin Core) and Luke Dashjr hasn't yet decided on Bitcoin Knots.
                      >>      >>
                      >>      >>
                      >>      >>
                      >>      >>     On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <ZmnSCPxj@protonmail•com <mailto:ZmnSCPxj@protonmail•com>
                      >>     <mailto:ZmnSCPxj@protonmail•com <mailto:ZmnSCPxj@protonmail•com>>> wrote:
                      >>      >>
                      >>      >>         Good morning all,
                      >>      >>
                      >>      >>         > "An activation mechanism is a consensus change like any other change, can be contentious like any other
                      >>      >>         change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest 
                      >> timeline."
                      >>      >>         >
                      >>      >>         > Who's we here?
                      >>      >>         >
                      >>      >>         > Release both and let the network decide.
                      >>      >>
                      >>      >>         A thing that could be done, without mandating either LOT=true or LOT=false, would be to have a release 
                      >> that
                      >>      >>         requires a `taprootlot=1` or `taprootlot=0` and refuses to start if the parameter is not set.
                      >>      >>
                      >>      >>         This assures everyone that neither choice is being forced on users, and instead what is being forced on
                      >>     users,
                      >>      >>         is for users to make that choice themselves.
                      >>      >>
                      >>      >>         Regards,
                      >>      >>         ZmnSCPxj
                      >>      >>
                      >>      >>         >
                      >>      >>         > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org
                      >>     <mailto:bitcoin-dev@lists•linuxfoundation.org>
                      >>      >>         <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>> wrote:
                      >>      >>         >
                      >>      >>         > > Thanks for your response Ariel. It would be useful if you responded to specific points I have made
                      >>     in the
                      >>      >>         mailing list post or at least quote these ephemeral "people" you speak of. I don't know if you're 
                      >> responding
                      >>      >>         to conversation on the IRC channel or on social media etc.
                      >>      >>         > >
                      >>      >>         > > > The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted
                      >>     into
                      >>      >>         code. But in fact this isn't true and some voices in this discussion need to be more humble about what 
                      >> users
                      >>      >>         must or must not run.
                      >>      >>         > >
                      >>      >>         > > I personally have never made this assumption. Of course users aren't forced to run any particular
                      >>     software
                      >>      >>         version, quite the opposite. Defaults set in software versions matter though as many users won't change
                      >>     them.
                      >>      >>         > >
                      >>      >>         > > > Does no one realize that it is a very possible outcome that if LOT=true is released there may be
                      >>     only a
                      >>      >>         handful of people that begin running it while everyone else delays their upgrade (with the very good
                      >>     reason of
                      >>      >>         not getting involved in politics) and a year later those handful of people just become stuck at the
                      >>     moment of
                      >>      >>         MUST_SIGNAL, unable to mine new blocks?
                      >>      >>         > >
                      >>      >>         > > It is a possible outcome but the likely outcome is that miners activate Taproot before LOT is even
                      >>      >>         relevant. I think it is prudent to prepare for the unlikely but possible outcome that miners fail to
                      >>     activate
                      >>      >>         and hence have this discussion now rather than be unprepared for that eventuality. If LOT is set to
                      >>     false in a
                      >>      >>         software release there is the possibility (T2 in
                      >>      >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                      >>     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>
                      >>      >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                      >>     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>>) of individuals or a
                      >>      >>         proportion of the community changing LOT to true. In that sense setting LOT=false in a software release
                      >>      >>         appears to be no more safe than LOT=true.
                      >>      >>         > >
                      >>      >>         > > > The result: a wasted year of waiting and a minority of people who didn't want to be lenient with
                      >>     miners
                      >>      >>         by default.
                      >>      >>         > >
                      >>      >>         > > There is the (unlikely but possible) possibility of a wasted year if LOT is set to false and 
                      >> miners fail
                      >>      >>         to activate. I'm not convinced by this perception that LOT=true is antagonistic to miners. I actually
                      >>     think it
                      >>      >>         offers them clarity on what will happen over a year time period and removes the need for coordinated or
                      >>      >>         uncoordinated community UASF efforts on top of LOT=false.
                      >>      >>         > >
                      >>      >>         > > > An activation mechanism is a consensus change like any other change, can be contentious like any 
                      >> other
                      >>      >>         change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
                      >>      >>         > >
                      >>      >>         > > I don't know what you are recommending here to avoid "this darkest timeline". Open discussions have
                      >>      >>         occurred and are continuing and in my mailing list post that you responded to **I recommended we propose
                      >>      >>         LOT=false be set in protocol implementations such as Bitcoin Core**. I do think this apocalyptic language
                      >>      >>         isn't particularly helpful. In an open consensus system discussion is healthy, we should prepare for 
                      >> bad or
                      >>      >>         worst case scenarios in advance and doing so is not antagonistic or destructive. Mining pools have 
                      >> pledged
                      >>      >>         support for Taproot but we don't build secure systems based on pledges of support, we build them to 
                      >> minimize
                      >>      >>         trust in any human actors. We can be grateful that people like Alejandro have worked hard on
                      >>      >> taprootactivation.com <http://taprootactivation.com> <http://taprootactivation.com
                      >>     <http://taprootactivation.com>> (and this effort has informed the discussion) without
                      >>      >>         taking pledges of support as cast iron guarantees.
                      >>      >>         > >
                      >>      >>         > > TL;DR It sounds like you agree with my recommendation to set LOT=false in protocol implementations 
                      >> in my
                      >>      >>         email :)
                      >>      >>         > >
                      >>      >>         > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <arielluaces@gmail•com
                      >>     <mailto:arielluaces@gmail•com>
                      >>      >>         <mailto:arielluaces@gmail•com <mailto:arielluaces@gmail•com>>> wrote:
                      >>      >>         > >
                      >>      >>         > > > Something what strikes me about the conversation is the emotion surrounding the letters UASF.
                      >>      >>         > > > It appears as if people discuss UASF as if it's a massive tidal wave of support that is
                      >>     inevitable, like
                      >>      >>         we saw during segwit activation. But the actual definition is "any activation that is not a MASF".
                      >>      >>         > > > A UASF can consist of a single node, ten nodes, a thousand, half of all nodes, all business' 
                      >> nodes, or
                      >>      >>         even all the non mining nodes. On another dimension it can have zero mining support, 51% support, 49%
                      >>     support,
                      >>      >>         or any support right up against a miner activation threshold.
                      >>      >>         > > > Hell a UASF doesn't even need code or even a single node running as long as it exists as a 
                      >> possibility
                      >>      >>         in people's minds.
                      >>      >>         > > > The only thing a UASF doesn't have is miner support above an agreed activation threshold (some 
                      >> number
                      >>      >>         above %51).
                      >>      >>         > > > I say this because it strikes me when people say that they are for LOT=true with the logic that
                      >>     since a
                      >>      >>         UASF is guaranteed to happen then it's better to just make it default from the beginning. Words like
                      >>      >>         coordination and safety are sometimes sprinkled into the argument.
                      >>      >>         > > > The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted
                      >>     into
                      >>      >>         code. But in fact this isn't true and some voices in this discussion need to be more humble about what 
                      >> users
                      >>      >>         must or must not run.
                      >>      >>         > > > Does no one realize that it is a very possible outcome that if LOT=true is released there may be
                      >>     only a
                      >>      >>         handful of people that begin running it while everyone else delays their upgrade (with the very good
                      >>     reason of
                      >>      >>         not getting involved in politics) and a year later those handful of people just become stuck at the
                      >>     moment of
                      >>      >>         MUST_SIGNAL, unable to mine new blocks? Or attracting a minority of miners, activating, and forking off
                      >>     into a
                      >>      >>         minority fork. Then a lot=false could be started that ends up activating the feature now that the 
                      >> stubborn
                      >>      >>         option has ran its course.
                      >>      >>         > > > The result: a wasted year of waiting and a minority of people who didn't want to be lenient with
                      >>     miners
                      >>      >>         by default. The chains could be called BitcoinLenient and BitcoinStubborn.
                      >>      >>         > > > How is that strictly safer or more coordinated?
                      >>      >>         > > > I may be in the minority, or maybe a silent majority, or maybe a majority that just hasn't 
                      >> considered
                      >>      >>         this as a choice but honestly if there is contention about whether we're going to be stubborn or lenient
                      >>     with
                      >>      >>         miners for Taproot and in the future then I prefer to just not activate anything at all. I'm fine for
                      >>     calling
                      >>      >>         bitcoin ossified, accepting that segwit is Bitcoin's last network upgrade. Taproot is amazing but no new
                      >>      >>         feature is worth a network split down the middle.
                      >>      >>         > > > Maybe in 10 or 20 years, when other blockchains implement features like Taproot and many more, 
                      >> we will
                      >>      >>         become envious enough to put aside our differences on how to behave towards miners and finally activate
                      >>     Taproot.
                      >>      >>         > > > An activation mechanism is a consensus change like any other change, can be contentious like any 
                      >> other
                      >>      >>         change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
                      >>      >>         > > > Cheers
                      >>      >>         > > > Ariel Lorenzo-Luaces
                      >>      >>         > > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev
                      >>     <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
                      >>      >>         <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>> wrote:
                      >>      >>         > > >
                      >>      >>         > > > > Yesterday (February 16th) we held a second meeting on Taproot
                      >>      >>         > > > > activation on IRC which again was open to all. Despite what appeared
                      >>      >>         > > > > to be majority support for LOT=false over LOT=true in the first
                      >>      >>         > > > > meeting I (and others) thought the arguments had not been explored in
                      >>      >>         > > > > depth and that we should have a follow up meeting almost entirely
                      >>      >>         > > > > focused on whether LOT (lockinontimeout) should be set to true or
                      >>      >>         > > > > false.
                      >>      >>         > > > >
                      >>      >>         > > > > The meeting was announced here:
                      >>      >>         > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                      >>     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>
                      >>      >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                      >>     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>>
                      >>      >>         > > > >
                      >>      >>         > > > > In that mailing list post I outlined the arguments for LOT=true (T1 to
                      >>      >>         > > > > T6) and arguments for LOT=false (F1 to F6) in their strongest form I
                      >>      >>         > > > > could. David Harding responded with an additional argument for
                      >>      >>         > > > > LOT=false (F7) here:
                      >>      >>         > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
                      >>     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html>
                      >>      >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
                      >>     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html>>
                      >>      >>         > > > >
                      >>      >>         > > > > These meetings are very challenging given they are open to all, you
                      >>      >>         > > > > don’t know who will attend and you don’t know most people’s views in
                      >>      >>         > > > > advance. I tried to give time for both the LOT=true arguments and the
                      >>      >>         > > > > LOT=false arguments to be discussed as I knew there was support for
                      >>      >>         > > > > both. We only tried evaluating which had more support and which had
                      >>      >>         > > > > more strong opposition towards the end of the meeting.
                      >>      >>         > > > >
                      >>      >>         > > > > The conversation log is here:
                      >>      >>         > > > > http://gnusha.org/taproot-activation/2021-02-16.log
                      >>     <http://gnusha.org/taproot-activation/2021-02-16.log> <http://gnusha.org/taproot-activation/2021-02-16.log
                      >>     <http://gnusha.org/taproot-activation/2021-02-16.log>>
                      >>      >>         > > > >
                      >>      >>         > > > > (If you are so inclined you can watch a video of the meeting here.
                      >>      >>         > > > > Thanks to the YouTube account “Bitcoin” for setting up the livestream:
                      >>      >>         > > > > https://www.youtube.com/watch?v=vpl5q1ovMLM <https://www.youtube.com/watch?v=vpl5q1ovMLM>
                      >>     <https://www.youtube.com/watch?v=vpl5q1ovMLM <https://www.youtube.com/watch?v=vpl5q1ovMLM>>)
                      >>      >>         > > > >
                      >>      >>         > > > > A summary of the meeting was provided by Luke Dashjr on Mastodon here:
                      >>      >>         > > > > https://bitcoinhackers.org/@lukedashjr/105742918779234566
                      >>     <https://bitcoinhackers.org/@lukedashjr/105742918779234566>
                      >>      >>         <https://bitcoinhackers.org/@lukedashjr/105742918779234566
                      >>     <https://bitcoinhackers.org/@lukedashjr/105742918779234566>>
                      >>      >>         > > > >
                      >>      >>         > > > > Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we
                      >>      >>         > > > > did manage to come to consensus on everything but LockinOnTimeout.
                      >>      >>         > > > >
                      >>      >>         > > > > Activation height range: 693504-745920
                      >>      >>         > > > >
                      >>      >>         > > > > MASF threshold: 1815/2016 blocks (90%)
                      >>      >>         > > > >
                      >>      >>         > > > > Keep in mind only ~100 people showed for the meetings, hardly
                      >>      >>         > > > > representative of the entire community.
                      >>      >>         > > > >
                      >>      >>         > > > > So, these details remain JUST a proposal for now.
                      >>      >>         > > > >
                      >>      >>         > > > > It seems inevitable that there won't be consensus on LOT.
                      >>      >>         > > > >
                      >>      >>         > > > > Everyone will have to choose for himself. :/
                      >>      >>         > > > >
                      >>      >>         > > > > Personally I agree with most of this. I agree that there wasn’t
                      >>      >>         > > > > overwhelming consensus for either LOT=true or LOT=false. However, from
                      >>      >>         > > > > my perspective there was clearly more strong opposition (what would
                      >>      >>         > > > > usually be deemed a NACK in Bitcoin Core review terminology) from
                      >>      >>         > > > > Bitcoin Core contributors, Lightning developers and other community
                      >>      >>         > > > > members against LOT=true than there was for LOT=false. Andrew Chow
                      >>      >>         > > > > tried to summarize views from the meeting in this analysis:
                      >>      >>         > > > > https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
                      >>     <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>
                      >>      >>         <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
                      >>     <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>>
                      >>      >>         > > > >
                      >>      >>         > > > > I am also aware of other current and previous Bitcoin Core
                      >>      >>         > > > > contributors and Lightning developers who didn’t attend the meeting in
                      >>      >>         > > > > person who are opposed to LOT=true. I don’t want to put them in the
                      >>      >>         > > > > spotlight for no reason but if you go through the conversation logs of
                      >>      >>         > > > > not only the meeting but the weeks of discussion prior to this meeting
                      >>      >>         > > > > you will see their views evaluated on the ##taproot-activation
                      >>      >>         > > > > channel. In addition, on taprootactivation.com <http://taprootactivation.com>
                      >>     <http://taprootactivation.com <http://taprootactivation.com>> some mining pools
                      >>      >>         > > > > expressed a preference for lot=false though I don’t know how strong
                      >>      >>         > > > > that preference was.
                      >>      >>         > > > >
                      >>      >>         > > > > I am only one voice but it is my current assessment that if we are to
                      >>      >>         > > > > attempt to finalize Taproot activation parameters and propose them to
                      >>      >>         > > > > the community at this time our only option is to propose LOT=false.
                      >>      >>         > > > > Any further delay appears to me counterproductive in our collective
                      >>      >>         > > > > aim to get the Taproot soft fork activated as early as possible.
                      >>      >>         > > > >
                      >>      >>         > > > > Obviously others are free to disagree with that assessment and
                      >>      >>         > > > > continue discussions but personally I will be attempting to avoid
                      >>      >>         > > > > those discussions unless prominent new information comes to light or
                      >>      >>         > > > > various specific individuals change their minds.
                      >>      >>         > > > >
                      >>      >>         > > > > Next week we are planning a code review of the Bitcoin Core PR #19573
                      >>      >>         > > > > which was initially delayed because of this LOT discussion. As I’ve
                      >>      >>         > > > > said previously that will be loosely following the format of the
                      >>      >>         > > > > Bitcoin Core PR review club and will be lower level and more
                      >>      >>         > > > > technical. That is planned for Tuesday February 23rd at 19:00 UTC on
                      >>      >>         > > > > the IRC channel ##taproot-activation.
                      >>      >>         > > > >
                      >>      >>         > > > > Thanks to the meeting participants (and those who joined the
                      >>      >>         > > > > discussion on the channel prior and post the meeting) for engaging
                      >>      >>         > > > > productively and in good faith.
                      >>      >>         > >
                      >>      >>         > > --
                      >>      >>         > > Michael Folkson
                      >>      >>         > > Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com> <mailto:michaelfolkson@gmail•com
                      >>     <mailto:michaelfolkson@gmail•com>>
                      >>      >>         > > Keybase: michaelfolkson
                      >>      >>         > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                      >>      >>         > > _______________________________________________
                      >>      >>         > > bitcoin-dev mailing list
                      >>      >>         > > bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
                      >>     <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>
                      >>      >>         > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                      >>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
                      >>      >>         <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                      >>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>>
                      >>      >>
                      >>      >>
                      >>      >>
                      >>      >>
                      >>      >>     --
                      >>      >>     Michael Folkson
                      >>      >>     Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com> <mailto:michaelfolkson@gmail•com
                      >>     <mailto:michaelfolkson@gmail•com>>
                      >>      >>     Keybase: michaelfolkson
                      >>      >>     PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                      >>      >>     _______________________________________________
                      >>      >>     bitcoin-dev mailing list
                      >>      >> bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
                      >>     <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>
                      >>      >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                      >>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
                      >>      >>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                      >>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>>
                      >>      >
                      >>      >
                      >>      >
                      >>      > --
                      >>      > Michael Folkson
                      >>      > Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com> <mailto:michaelfolkson@gmail•com
                      >>     <mailto:michaelfolkson@gmail•com>>
                      >>      > Keybase: michaelfolkson
                      >>      > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                      >>
                      >>
                      >>
                      >> -- 
                      >> Michael Folkson
                      >> Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com>
                      >> Keybase: michaelfolkson
                      >> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                      > _______________________________________________
                      > bitcoin-dev mailing list
                      > bitcoin-dev@lists•linuxfoundation.org
                      > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                      
                      
                      ^ permalink raw reply	[flat|nested] 42+ messages in thread

                • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                    2021-02-18 14:42               ` Matt Corallo
                    2021-02-18 14:51                 ` Michael Folkson
                  @ 2021-02-18 15:04                 ` Keagan McClelland
                    2021-02-18 15:18                   ` Matt Corallo
                    1 sibling, 1 reply; 42+ messages in thread
                  From: Keagan McClelland @ 2021-02-18 15:04 UTC (permalink / raw)
                    To: Matt Corallo, Bitcoin Protocol Discussion; +Cc: Michael Folkson
                  
                  [-- Attachment #1: Type: text/plain, Size: 24387 bytes --]
                  
                  Hi all,
                  
                  I think it's important for us to consider what is actually being considered
                  for activation here.
                  
                  The designation of "soft fork" is accurate but I don't think it adequately
                  conveys how non-intrusive a change like this is. All that taproot does
                  (unless I'm completely missing something) is imbue a previously undefined
                  script version with actual semantics. In order for a chain reorg to take
                  place it would mean that someone would have to have a use case for that
                  script version today. This is something I think that we can easily check by
                  digging through the UTXO set or history. If anyone is using that script
                  version, we absolutely should not be using it, but that doesn't mean that
                  we can't switch to a script version that no one is actually using.
                  
                  If no one is even attempting to use the script version, then the change has
                  no effect on whether a chain split occurs because there is simply no block
                  that contains a transaction that only some of the network will accept.
                  
                  Furthermore, I don't know how Bitcoin can stand the test of time if we
                  allow developers who rely on "undefined behavior" (which the taproot script
                  version presently is) to exert tremendous influence over what code does or
                  does not get run. This isn't a soft fork that makes some particular UTXO's
                  unspendable. It isn't one that bans miners from collecting fees. It is a
                  change that means that certain "always accept" transactions actually have
                  real conditions you have to meet. I can't imagine a less intrusive change.
                  
                  On the other hand, choosing to let L=F be a somewhat final call sets a very
                  real precedent that 10% of what I estimate to be 1% of bitcoin users can
                  effectively block any change from here on forward. At that point we are
                  saying that miners are in control of network consensus in ways they have
                  not been up until now. I don't think this is a more desirable outcome to
                  let ~0.1% of the network get to block *non-intrusive* changes that the rest
                  of the network wants.
                  
                  I can certainly live with an L=F attempt as a way to punt on the
                  discussion, maybe the activation happens and this will all be fine. But if
                  it doesn't, I hardly think that users of Bitcoin are just going to be like
                  "well, guess that's it for Taproot". I have no idea what ensues at that
                  point, but probably another community led UASF movement.
                  
                  I wasn't super well educated on this stuff back in '17 when Segwit went
                  down, as I was new at that time, so if I'm missing something please say so.
                  But from my point of view, we can't treat all soft forks as equal.
                  
                  Keagan
                  
                  On Thu, Feb 18, 2021 at 7:43 AM Matt Corallo via bitcoin-dev <
                  bitcoin-dev@lists•linuxfoundation.org> wrote:
                  
                  > We've had several softforks in Bitcoin which, through the course of their
                  > activation, had a several-block reorg. That
                  > should be indication enough that we need to very carefully consider
                  > activation to ensure we reduce the risk of that as
                  > much as absolutely possible. Again, while I think Taproot is a huge
                  > improvement and am looking forward to being able to
                  > use it, getting unlucky and hitting a 4-block reorg that happens to
                  > include a double-spend and some PR around an
                  > exchange losing millions would be worse than having Taproot is good.
                  >
                  > Matt
                  >
                  > On 2/18/21 09:26, Michael Folkson wrote:
                  > > Thanks for your response Matt. It is a fair challenge. There is always
                  > going to be an element of risk with soft forks,
                  > > all we can do is attempt to minimize that risk. I would argue that risk
                  > has been minimized for Taproot.
                  > >
                  > > You know (better than I do in fact) that Bitcoin (and layers built on
                  > top of it) greatly benefit from upgrades such as
                  > > Taproot. To say we shouldn't do Taproot or any future soft forks because
                  > there is a small but real risk of chain splits
                  > > I think is shortsighted. Indeed I think even if we collectively decided
                  > not to do any future soft fork upgrades ever
                  > > again on this mailing list that wouldn't stop soft fork attempts from
                  > other people in future.
                  > >
                  > > I don't think there is anything else we can do to minimize that risk for
                  > the Taproot soft fork at this point though I'm
                  > > open to ideas. To reiterate that risk will never be zero. I don't think
                  > I see Bitcoin as fragile as you seem to (though
                  > > admittedly you have a much better understanding than me of what happened
                  > in 2017).
                  > >
                  > > The likely scenario for the Taproot soft fork is LOT turns out to be
                  > entirely irrelevant and miners activate Taproot
                  > > before it becomes relevant. And even the unlikely worst case scenario
                  > would only cause short term disruption and
                  > > wouldn't kill Bitcoin long term.
                  > >
                  > > On Thu, Feb 18, 2021 at 2:01 PM Matt Corallo <lf-lists@mattcorallo•com
                  > <mailto:lf-lists@mattcorallo•com>> wrote:
                  > >
                  > >     If the eventual outcome is that different implementations (that have
                  > material *transaction processing* userbases,
                  > >     and I’m not sure to what extent that’s true with Knots) ship
                  > different consensus rules, we should stop here and not
                  > >     activate Taproot. Seriously.
                  > >
                  > >     Bitcoin is a consensus system. The absolute worst outcome at all
                  > possible is to have it fall out of consensus.
                  > >
                  > >     Matt
                  > >
                  > >>     On Feb 18, 2021, at 08:11, Michael Folkson via bitcoin-dev <
                  > bitcoin-dev@lists•linuxfoundation.org
                  > >>     <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
                  > >>
                  > >>     
                  > >>     Right, that is one option. Personally I would prefer a Bitcoin Core
                  > release sets LOT=false (based on what I have
                  > >>     heard from Bitcoin Core contributors) and a community effort
                  > releases a version with LOT=true. I don't think users
                  > >>     should be forced to choose something they may have no context on
                  > before they are allowed to use Bitcoin Core.
                  > >>
                  > >>     My current understanding is that roasbeef is planning to set
                  > LOT=false on btcd (an alternative protocol
                  > >>     implementation to Bitcoin Core) and Luke Dashjr hasn't yet decided
                  > on Bitcoin Knots.
                  > >>
                  > >>
                  > >>
                  > >>     On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <ZmnSCPxj@protonmail•com
                  > <mailto:ZmnSCPxj@protonmail•com>> wrote:
                  > >>
                  > >>         Good morning all,
                  > >>
                  > >>         > "An activation mechanism is a consensus change like any other
                  > change, can be contentious like any other
                  > >>         change, and we must resolve it like any other change. Otherwise
                  > we risk arriving at the darkest timeline."
                  > >>         >
                  > >>         > Who's we here?
                  > >>         >
                  > >>         > Release both and let the network decide.
                  > >>
                  > >>         A thing that could be done, without mandating either LOT=true
                  > or LOT=false, would be to have a release that
                  > >>         requires a `taprootlot=1` or `taprootlot=0` and refuses to
                  > start if the parameter is not set.
                  > >>
                  > >>         This assures everyone that neither choice is being forced on
                  > users, and instead what is being forced on users,
                  > >>         is for users to make that choice themselves.
                  > >>
                  > >>         Regards,
                  > >>         ZmnSCPxj
                  > >>
                  > >>         >
                  > >>         > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via
                  > bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org
                  > >>         <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
                  > >>         >
                  > >>         > > Thanks for your response Ariel. It would be useful if you
                  > responded to specific points I have made in the
                  > >>         mailing list post or at least quote these ephemeral "people"
                  > you speak of. I don't know if you're responding
                  > >>         to conversation on the IRC channel or on social media etc.
                  > >>         > >
                  > >>         > > > The argument comes from a naive assumption that users
                  > MUST upgrade to the choice that is submitted into
                  > >>         code. But in fact this isn't true and some voices in this
                  > discussion need to be more humble about what users
                  > >>         must or must not run.
                  > >>         > >
                  > >>         > > I personally have never made this assumption. Of course
                  > users aren't forced to run any particular software
                  > >>         version, quite the opposite. Defaults set in software versions
                  > matter though as many users won't change them.
                  > >>         > >
                  > >>         > > > Does no one realize that it is a very possible outcome
                  > that if LOT=true is released there may be only a
                  > >>         handful of people that begin running it while everyone else
                  > delays their upgrade (with the very good reason of
                  > >>         not getting involved in politics) and a year later those
                  > handful of people just become stuck at the moment of
                  > >>         MUST_SIGNAL, unable to mine new blocks?
                  > >>         > >
                  > >>         > > It is a possible outcome but the likely outcome is that
                  > miners activate Taproot before LOT is even
                  > >>         relevant. I think it is prudent to prepare for the unlikely but
                  > possible outcome that miners fail to activate
                  > >>         and hence have this discussion now rather than be unprepared
                  > for that eventuality. If LOT is set to false in a
                  > >>         software release there is the possibility (T2 in
                  > >>
                  > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                  > >>         <
                  > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>)
                  > of individuals or a
                  > >>         proportion of the community changing LOT to true. In that sense
                  > setting LOT=false in a software release
                  > >>         appears to be no more safe than LOT=true.
                  > >>         > >
                  > >>         > > > The result: a wasted year of waiting and a minority of
                  > people who didn't want to be lenient with miners
                  > >>         by default.
                  > >>         > >
                  > >>         > > There is the (unlikely but possible) possibility of a
                  > wasted year if LOT is set to false and miners fail
                  > >>         to activate. I'm not convinced by this perception that LOT=true
                  > is antagonistic to miners. I actually think it
                  > >>         offers them clarity on what will happen over a year time period
                  > and removes the need for coordinated or
                  > >>         uncoordinated community UASF efforts on top of LOT=false.
                  > >>         > >
                  > >>         > > > An activation mechanism is a consensus change like any
                  > other change, can be contentious like any other
                  > >>         change, and we must resolve it like any other change. Otherwise
                  > we risk arriving at the darkest timeline.
                  > >>         > >
                  > >>         > > I don't know what you are recommending here to avoid "this
                  > darkest timeline". Open discussions have
                  > >>         occurred and are continuing and in my mailing list post that
                  > you responded to **I recommended we propose
                  > >>         LOT=false be set in protocol implementations such as Bitcoin
                  > Core**. I do think this apocalyptic language
                  > >>         isn't particularly helpful. In an open consensus system
                  > discussion is healthy, we should prepare for bad or
                  > >>         worst case scenarios in advance and doing so is not
                  > antagonistic or destructive. Mining pools have pledged
                  > >>         support for Taproot but we don't build secure systems based on
                  > pledges of support, we build them to minimize
                  > >>         trust in any human actors. We can be grateful that people like
                  > Alejandro have worked hard on
                  > >>         taprootactivation.com <http://taprootactivation.com> (and this
                  > effort has informed the discussion) without
                  > >>         taking pledges of support as cast iron guarantees.
                  > >>         > >
                  > >>         > > TL;DR It sounds like you agree with my recommendation to
                  > set LOT=false in protocol implementations in my
                  > >>         email :)
                  > >>         > >
                  > >>         > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <
                  > arielluaces@gmail•com
                  > >>         <mailto:arielluaces@gmail•com>> wrote:
                  > >>         > >
                  > >>         > > > Something what strikes me about the conversation is the
                  > emotion surrounding the letters UASF.
                  > >>         > > > It appears as if people discuss UASF as if it's a massive
                  > tidal wave of support that is inevitable, like
                  > >>         we saw during segwit activation. But the actual definition is
                  > "any activation that is not a MASF".
                  > >>         > > > A UASF can consist of a single node, ten nodes, a
                  > thousand, half of all nodes, all business' nodes, or
                  > >>         even all the non mining nodes. On another dimension it can have
                  > zero mining support, 51% support, 49% support,
                  > >>         or any support right up against a miner activation threshold.
                  > >>         > > > Hell a UASF doesn't even need code or even a single node
                  > running as long as it exists as a possibility
                  > >>         in people's minds.
                  > >>         > > > The only thing a UASF doesn't have is miner support above
                  > an agreed activation threshold (some number
                  > >>         above %51).
                  > >>         > > > I say this because it strikes me when people say that
                  > they are for LOT=true with the logic that since a
                  > >>         UASF is guaranteed to happen then it's better to just make it
                  > default from the beginning. Words like
                  > >>         coordination and safety are sometimes sprinkled into the
                  > argument.
                  > >>         > > > The argument comes from a naive assumption that users
                  > MUST upgrade to the choice that is submitted into
                  > >>         code. But in fact this isn't true and some voices in this
                  > discussion need to be more humble about what users
                  > >>         must or must not run.
                  > >>         > > > Does no one realize that it is a very possible outcome
                  > that if LOT=true is released there may be only a
                  > >>         handful of people that begin running it while everyone else
                  > delays their upgrade (with the very good reason of
                  > >>         not getting involved in politics) and a year later those
                  > handful of people just become stuck at the moment of
                  > >>         MUST_SIGNAL, unable to mine new blocks? Or attracting a
                  > minority of miners, activating, and forking off into a
                  > >>         minority fork. Then a lot=false could be started that ends up
                  > activating the feature now that the stubborn
                  > >>         option has ran its course.
                  > >>         > > > The result: a wasted year of waiting and a minority of
                  > people who didn't want to be lenient with miners
                  > >>         by default. The chains could be called BitcoinLenient and
                  > BitcoinStubborn.
                  > >>         > > > How is that strictly safer or more coordinated?
                  > >>         > > > I may be in the minority, or maybe a silent majority, or
                  > maybe a majority that just hasn't considered
                  > >>         this as a choice but honestly if there is contention about
                  > whether we're going to be stubborn or lenient with
                  > >>         miners for Taproot and in the future then I prefer to just not
                  > activate anything at all. I'm fine for calling
                  > >>         bitcoin ossified, accepting that segwit is Bitcoin's last
                  > network upgrade. Taproot is amazing but no new
                  > >>         feature is worth a network split down the middle.
                  > >>         > > > Maybe in 10 or 20 years, when other blockchains implement
                  > features like Taproot and many more, we will
                  > >>         become envious enough to put aside our differences on how to
                  > behave towards miners and finally activate Taproot.
                  > >>         > > > An activation mechanism is a consensus change like any
                  > other change, can be contentious like any other
                  > >>         change, and we must resolve it like any other change. Otherwise
                  > we risk arriving at the darkest timeline.
                  > >>         > > > Cheers
                  > >>         > > > Ariel Lorenzo-Luaces
                  > >>         > > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via
                  > bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org
                  > >>         <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
                  > >>         > > >
                  > >>         > > > > Yesterday (February 16th) we held a second meeting on
                  > Taproot
                  > >>         > > > > activation on IRC which again was open to all. Despite
                  > what appeared
                  > >>         > > > > to be majority support for LOT=false over LOT=true in
                  > the first
                  > >>         > > > > meeting I (and others) thought the arguments had not
                  > been explored in
                  > >>         > > > > depth and that we should have a follow up meeting
                  > almost entirely
                  > >>         > > > > focused on whether LOT (lockinontimeout) should be set
                  > to true or
                  > >>         > > > > false.
                  > >>         > > > >
                  > >>         > > > > The meeting was announced here:
                  > >>         > > > >
                  > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                  > >>         <
                  > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                  > >
                  > >>         > > > >
                  > >>         > > > > In that mailing list post I outlined the arguments for
                  > LOT=true (T1 to
                  > >>         > > > > T6) and arguments for LOT=false (F1 to F6) in their
                  > strongest form I
                  > >>         > > > > could. David Harding responded with an additional
                  > argument for
                  > >>         > > > > LOT=false (F7) here:
                  > >>         > > > >
                  > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
                  > >>         <
                  > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
                  > >
                  > >>         > > > >
                  > >>         > > > > These meetings are very challenging given they are open
                  > to all, you
                  > >>         > > > > don’t know who will attend and you don’t know most
                  > people’s views in
                  > >>         > > > > advance. I tried to give time for both the LOT=true
                  > arguments and the
                  > >>         > > > > LOT=false arguments to be discussed as I knew there was
                  > support for
                  > >>         > > > > both. We only tried evaluating which had more support
                  > and which had
                  > >>         > > > > more strong opposition towards the end of the meeting.
                  > >>         > > > >
                  > >>         > > > > The conversation log is here:
                  > >>         > > > > http://gnusha.org/taproot-activation/2021-02-16.log <
                  > http://gnusha.org/taproot-activation/2021-02-16.log>
                  > >>         > > > >
                  > >>         > > > > (If you are so inclined you can watch a video of the
                  > meeting here.
                  > >>         > > > > Thanks to the YouTube account “Bitcoin” for setting up
                  > the livestream:
                  > >>         > > > > https://www.youtube.com/watch?v=vpl5q1ovMLM <
                  > https://www.youtube.com/watch?v=vpl5q1ovMLM>)
                  > >>         > > > >
                  > >>         > > > > A summary of the meeting was provided by Luke Dashjr on
                  > Mastodon here:
                  > >>         > > > >
                  > https://bitcoinhackers.org/@lukedashjr/105742918779234566
                  > >>         <https://bitcoinhackers.org/@lukedashjr/105742918779234566>
                  > >>         > > > >
                  > >>         > > > > Today's #Bitcoin #Taproot meeting was IMO largely
                  > unproductive, but we
                  > >>         > > > > did manage to come to consensus on everything but
                  > LockinOnTimeout.
                  > >>         > > > >
                  > >>         > > > > Activation height range: 693504-745920
                  > >>         > > > >
                  > >>         > > > > MASF threshold: 1815/2016 blocks (90%)
                  > >>         > > > >
                  > >>         > > > > Keep in mind only ~100 people showed for the meetings,
                  > hardly
                  > >>         > > > > representative of the entire community.
                  > >>         > > > >
                  > >>         > > > > So, these details remain JUST a proposal for now.
                  > >>         > > > >
                  > >>         > > > > It seems inevitable that there won't be consensus on
                  > LOT.
                  > >>         > > > >
                  > >>         > > > > Everyone will have to choose for himself. :/
                  > >>         > > > >
                  > >>         > > > > Personally I agree with most of this. I agree that
                  > there wasn’t
                  > >>         > > > > overwhelming consensus for either LOT=true or
                  > LOT=false. However, from
                  > >>         > > > > my perspective there was clearly more strong opposition
                  > (what would
                  > >>         > > > > usually be deemed a NACK in Bitcoin Core review
                  > terminology) from
                  > >>         > > > > Bitcoin Core contributors, Lightning developers and
                  > other community
                  > >>         > > > > members against LOT=true than there was for LOT=false.
                  > Andrew Chow
                  > >>         > > > > tried to summarize views from the meeting in this
                  > analysis:
                  > >>         > > > >
                  > https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
                  > >>         <
                  > https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>
                  > >>         > > > >
                  > >>         > > > > I am also aware of other current and previous Bitcoin
                  > Core
                  > >>         > > > > contributors and Lightning developers who didn’t attend
                  > the meeting in
                  > >>         > > > > person who are opposed to LOT=true. I don’t want to put
                  > them in the
                  > >>         > > > > spotlight for no reason but if you go through the
                  > conversation logs of
                  > >>         > > > > not only the meeting but the weeks of discussion prior
                  > to this meeting
                  > >>         > > > > you will see their views evaluated on the
                  > ##taproot-activation
                  > >>         > > > > channel. In addition, on taprootactivation.com <
                  > http://taprootactivation.com> some mining pools
                  > >>         > > > > expressed a preference for lot=false though I don’t
                  > know how strong
                  > >>         > > > > that preference was.
                  > >>         > > > >
                  > >>         > > > > I am only one voice but it is my current assessment
                  > that if we are to
                  > >>         > > > > attempt to finalize Taproot activation parameters and
                  > propose them to
                  > >>         > > > > the community at this time our only option is to
                  > propose LOT=false.
                  > >>         > > > > Any further delay appears to me counterproductive in
                  > our collective
                  > >>         > > > > aim to get the Taproot soft fork activated as early as
                  > possible.
                  > >>         > > > >
                  > >>         > > > > Obviously others are free to disagree with that
                  > assessment and
                  > >>         > > > > continue discussions but personally I will be
                  > attempting to avoid
                  > >>         > > > > those discussions unless prominent new information
                  > comes to light or
                  > >>         > > > > various specific individuals change their minds.
                  > >>         > > > >
                  > >>         > > > > Next week we are planning a code review of the Bitcoin
                  > Core PR #19573
                  > >>         > > > > which was initially delayed because of this LOT
                  > discussion. As I’ve
                  > >>         > > > > said previously that will be loosely following the
                  > format of the
                  > >>         > > > > Bitcoin Core PR review club and will be lower level and
                  > more
                  > >>         > > > > technical. That is planned for Tuesday February 23rd at
                  > 19:00 UTC on
                  > >>         > > > > the IRC channel ##taproot-activation.
                  > >>         > > > >
                  > >>         > > > > Thanks to the meeting participants (and those who
                  > joined the
                  > >>         > > > > discussion on the channel prior and post the meeting)
                  > for engaging
                  > >>         > > > > productively and in good faith.
                  > >>         > >
                  > >>         > > --
                  > >>         > > Michael Folkson
                  > >>         > > Email: michaelfolkson@gmail•com <mailto:
                  > michaelfolkson@gmail•com>
                  > >>         > > Keybase: michaelfolkson
                  > >>         > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                  > >>         > > _______________________________________________
                  > >>         > > bitcoin-dev mailing list
                  > >>         > > bitcoin-dev@lists•linuxfoundation.org <mailto:
                  > bitcoin-dev@lists•linuxfoundation.org>
                  > >>         > >
                  > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                  > >>         <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                  > >
                  > >>
                  > >>
                  > >>
                  > >>
                  > >>     --
                  > >>     Michael Folkson
                  > >>     Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com>
                  > >>     Keybase: michaelfolkson
                  > >>     PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                  > >>     _______________________________________________
                  > >>     bitcoin-dev mailing list
                  > >>     bitcoin-dev@lists•linuxfoundation.org <mailto:
                  > bitcoin-dev@lists•linuxfoundation.org>
                  > >>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                  > >>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
                  > >
                  > >
                  > >
                  > > --
                  > > Michael Folkson
                  > > Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com>
                  > > Keybase: michaelfolkson
                  > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                  > _______________________________________________
                  > bitcoin-dev mailing list
                  > bitcoin-dev@lists•linuxfoundation.org
                  > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                  >
                  
                  [-- Attachment #2: Type: text/html, Size: 33600 bytes --]
                  
                  ^ permalink raw reply	[flat|nested] 42+ messages in thread

                • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                      2021-02-18 15:04                 ` Keagan McClelland
                    @ 2021-02-18 15:18                   ` Matt Corallo
                      2021-02-19  2:20                     ` Ariel Luaces
                      2021-02-19 11:30                     ` ZmnSCPxj
                      0 siblings, 2 replies; 42+ messages in thread
                    From: Matt Corallo @ 2021-02-18 15:18 UTC (permalink / raw)
                      To: Keagan McClelland, Bitcoin Protocol Discussion; +Cc: Michael Folkson
                    
                    This is absolutely the case, however note that the activation method itself is consensus code which executes as a part 
                    of a fork, and one which deserves as much scrutiny as anything else. While taproot is a model of how a soft-fork should 
                    be designed, this doesn't imply anything about the consensus code which represents the activation thereof.
                    
                    Hence all the debate around activation - ultimately its also defining a fork, and given the politics around it, one 
                    which almost certainly carries significantly more risk than Taproot.
                    
                    Note that I don't believe anyone is advocating for "try to activate, and if it fails, move on". Various people have 
                    various views on how conservative and timelines for what to do at that point, but I believe most in this discussion are 
                    OK with flag-day-based activation (given some level of care) if it becomes clear Taproot is supported by a vast majority 
                    of Bitcoin users and is only not activating due to lagging miner upgrades.
                    
                    Matt
                    
                    On 2/18/21 10:04, Keagan McClelland wrote:
                    > Hi all,
                    > 
                    > I think it's important for us to consider what is actually being considered for activation here.
                    > 
                    > The designation of "soft fork" is accurate but I don't think it adequately conveys how non-intrusive a change like this 
                    > is. All that taproot does (unless I'm completely missing something) is imbue a previously undefined script version with 
                    > actual semantics. In order for a chain reorg to take place it would mean that someone would have to have a use case for 
                    > that script version today. This is something I think that we can easily check by digging through the UTXO set or 
                    > history. If anyone is using that script version, we absolutely should not be using it, but that doesn't mean that we 
                    > can't switch to a script version that no one is actually using.
                    > 
                    > If no one is even attempting to use the script version, then the change has no effect on whether a chain split occurs 
                    > because there is simply no block that contains a transaction that only some of the network will accept.
                    > 
                    > Furthermore, I don't know how Bitcoin can stand the test of time if we allow developers who rely on "undefined behavior" 
                    > (which the taproot script version presently is) to exert tremendous influence over what code does or does not get run. 
                    > This isn't a soft fork that makes some particular UTXO's unspendable. It isn't one that bans miners from collecting 
                    > fees. It is a change that means that certain "always accept" transactions actually have real conditions you have to 
                    > meet. I can't imagine a less intrusive change.
                    > 
                    > On the other hand, choosing to let L=F be a somewhat final call sets a very real precedent that 10% of what I estimate 
                    > to be 1% of bitcoin users can effectively block any change from here on forward. At that point we are saying that miners 
                    > are in control of network consensus in ways they have not been up until now. I don't think this is a more desirable 
                    > outcome to let ~0.1% of the network get to block /non-intrusive/ changes that the rest of the network wants.
                    > 
                    > I can certainly live with an L=F attempt as a way to punt on the discussion, maybe the activation happens and this will 
                    > all be fine. But if it doesn't, I hardly think that users of Bitcoin are just going to be like "well, guess that's it 
                    > for Taproot". I have no idea what ensues at that point, but probably another community led UASF movement.
                    > 
                    > I wasn't super well educated on this stuff back in '17 when Segwit went down, as I was new at that time, so if I'm 
                    > missing something please say so. But from my point of view, we can't treat all soft forks as equal.
                    > 
                    > Keagan
                    > 
                    > On Thu, Feb 18, 2021 at 7:43 AM Matt Corallo via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org 
                    > <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
                    > 
                    >     We've had several softforks in Bitcoin which, through the course of their activation, had a several-block reorg. That
                    >     should be indication enough that we need to very carefully consider activation to ensure we reduce the risk of that as
                    >     much as absolutely possible. Again, while I think Taproot is a huge improvement and am looking forward to being able to
                    >     use it, getting unlucky and hitting a 4-block reorg that happens to include a double-spend and some PR around an
                    >     exchange losing millions would be worse than having Taproot is good.
                    > 
                    >     Matt
                    > 
                    >     On 2/18/21 09:26, Michael Folkson wrote:
                    >      > Thanks for your response Matt. It is a fair challenge. There is always going to be an element of risk with soft
                    >     forks,
                    >      > all we can do is attempt to minimize that risk. I would argue that risk has been minimized for Taproot.
                    >      >
                    >      > You know (better than I do in fact) that Bitcoin (and layers built on top of it) greatly benefit from upgrades
                    >     such as
                    >      > Taproot. To say we shouldn't do Taproot or any future soft forks because there is a small but real risk of chain
                    >     splits
                    >      > I think is shortsighted. Indeed I think even if we collectively decided not to do any future soft fork upgrades ever
                    >      > again on this mailing list that wouldn't stop soft fork attempts from other people in future.
                    >      >
                    >      > I don't think there is anything else we can do to minimize that risk for the Taproot soft fork at this point
                    >     though I'm
                    >      > open to ideas. To reiterate that risk will never be zero. I don't think I see Bitcoin as fragile as you seem to
                    >     (though
                    >      > admittedly you have a much better understanding than me of what happened in 2017).
                    >      >
                    >      > The likely scenario for the Taproot soft fork is LOT turns out to be entirely irrelevant and miners activate Taproot
                    >      > before it becomes relevant. And even the unlikely worst case scenario would only cause short term disruption and
                    >      > wouldn't kill Bitcoin long term.
                    >      >
                    >      > On Thu, Feb 18, 2021 at 2:01 PM Matt Corallo <lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo•com>
                    >     <mailto:lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo•com>>> wrote:
                    >      >
                    >      >     If the eventual outcome is that different implementations (that have material *transaction processing* userbases,
                    >      >     and I’m not sure to what extent that’s true with Knots) ship different consensus rules, we should stop here
                    >     and not
                    >      >     activate Taproot. Seriously.
                    >      >
                    >      >     Bitcoin is a consensus system. The absolute worst outcome at all possible is to have it fall out of consensus.
                    >      >
                    >      >     Matt
                    >      >
                    >      >>     On Feb 18, 2021, at 08:11, Michael Folkson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org
                    >     <mailto:bitcoin-dev@lists•linuxfoundation.org>
                    >      >>     <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>> wrote:
                    >      >>
                    >      >>     
                    >      >>     Right, that is one option. Personally I would prefer a Bitcoin Core release sets LOT=false (based on what I have
                    >      >>     heard from Bitcoin Core contributors) and a community effort releases a version with LOT=true. I don't think
                    >     users
                    >      >>     should be forced to choose something they may have no context on before they are allowed to use Bitcoin Core.
                    >      >>
                    >      >>     My current understanding is that roasbeef is planning to set LOT=false on btcd (an alternative protocol
                    >      >>     implementation to Bitcoin Core) and Luke Dashjr hasn't yet decided on Bitcoin Knots.
                    >      >>
                    >      >>
                    >      >>
                    >      >>     On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <ZmnSCPxj@protonmail•com <mailto:ZmnSCPxj@protonmail•com>
                    >     <mailto:ZmnSCPxj@protonmail•com <mailto:ZmnSCPxj@protonmail•com>>> wrote:
                    >      >>
                    >      >>         Good morning all,
                    >      >>
                    >      >>         > "An activation mechanism is a consensus change like any other change, can be contentious like any other
                    >      >>         change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline."
                    >      >>         >
                    >      >>         > Who's we here?
                    >      >>         >
                    >      >>         > Release both and let the network decide.
                    >      >>
                    >      >>         A thing that could be done, without mandating either LOT=true or LOT=false, would be to have a release that
                    >      >>         requires a `taprootlot=1` or `taprootlot=0` and refuses to start if the parameter is not set.
                    >      >>
                    >      >>         This assures everyone that neither choice is being forced on users, and instead what is being forced on
                    >     users,
                    >      >>         is for users to make that choice themselves.
                    >      >>
                    >      >>         Regards,
                    >      >>         ZmnSCPxj
                    >      >>
                    >      >>         >
                    >      >>         > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org
                    >     <mailto:bitcoin-dev@lists•linuxfoundation.org>
                    >      >>         <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>> wrote:
                    >      >>         >
                    >      >>         > > Thanks for your response Ariel. It would be useful if you responded to specific points I have made
                    >     in the
                    >      >>         mailing list post or at least quote these ephemeral "people" you speak of. I don't know if you're responding
                    >      >>         to conversation on the IRC channel or on social media etc.
                    >      >>         > >
                    >      >>         > > > The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted
                    >     into
                    >      >>         code. But in fact this isn't true and some voices in this discussion need to be more humble about what users
                    >      >>         must or must not run.
                    >      >>         > >
                    >      >>         > > I personally have never made this assumption. Of course users aren't forced to run any particular
                    >     software
                    >      >>         version, quite the opposite. Defaults set in software versions matter though as many users won't change
                    >     them.
                    >      >>         > >
                    >      >>         > > > Does no one realize that it is a very possible outcome that if LOT=true is released there may be
                    >     only a
                    >      >>         handful of people that begin running it while everyone else delays their upgrade (with the very good
                    >     reason of
                    >      >>         not getting involved in politics) and a year later those handful of people just become stuck at the
                    >     moment of
                    >      >>         MUST_SIGNAL, unable to mine new blocks?
                    >      >>         > >
                    >      >>         > > It is a possible outcome but the likely outcome is that miners activate Taproot before LOT is even
                    >      >>         relevant. I think it is prudent to prepare for the unlikely but possible outcome that miners fail to
                    >     activate
                    >      >>         and hence have this discussion now rather than be unprepared for that eventuality. If LOT is set to
                    >     false in a
                    >      >>         software release there is the possibility (T2 in
                    >      >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                    >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>
                    >      >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                    >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>>) of individuals or a
                    >      >>         proportion of the community changing LOT to true. In that sense setting LOT=false in a software release
                    >      >>         appears to be no more safe than LOT=true.
                    >      >>         > >
                    >      >>         > > > The result: a wasted year of waiting and a minority of people who didn't want to be lenient with
                    >     miners
                    >      >>         by default.
                    >      >>         > >
                    >      >>         > > There is the (unlikely but possible) possibility of a wasted year if LOT is set to false and miners fail
                    >      >>         to activate. I'm not convinced by this perception that LOT=true is antagonistic to miners. I actually
                    >     think it
                    >      >>         offers them clarity on what will happen over a year time period and removes the need for coordinated or
                    >      >>         uncoordinated community UASF efforts on top of LOT=false.
                    >      >>         > >
                    >      >>         > > > An activation mechanism is a consensus change like any other change, can be contentious like any other
                    >      >>         change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
                    >      >>         > >
                    >      >>         > > I don't know what you are recommending here to avoid "this darkest timeline". Open discussions have
                    >      >>         occurred and are continuing and in my mailing list post that you responded to **I recommended we propose
                    >      >>         LOT=false be set in protocol implementations such as Bitcoin Core**. I do think this apocalyptic language
                    >      >>         isn't particularly helpful. In an open consensus system discussion is healthy, we should prepare for bad or
                    >      >>         worst case scenarios in advance and doing so is not antagonistic or destructive. Mining pools have pledged
                    >      >>         support for Taproot but we don't build secure systems based on pledges of support, we build them to minimize
                    >      >>         trust in any human actors. We can be grateful that people like Alejandro have worked hard on
                    >      >> taprootactivation.com <http://taprootactivation.com> <http://taprootactivation.com
                    >     <http://taprootactivation.com>> (and this effort has informed the discussion) without
                    >      >>         taking pledges of support as cast iron guarantees.
                    >      >>         > >
                    >      >>         > > TL;DR It sounds like you agree with my recommendation to set LOT=false in protocol implementations in my
                    >      >>         email :)
                    >      >>         > >
                    >      >>         > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <arielluaces@gmail•com
                    >     <mailto:arielluaces@gmail•com>
                    >      >>         <mailto:arielluaces@gmail•com <mailto:arielluaces@gmail•com>>> wrote:
                    >      >>         > >
                    >      >>         > > > Something what strikes me about the conversation is the emotion surrounding the letters UASF.
                    >      >>         > > > It appears as if people discuss UASF as if it's a massive tidal wave of support that is
                    >     inevitable, like
                    >      >>         we saw during segwit activation. But the actual definition is "any activation that is not a MASF".
                    >      >>         > > > A UASF can consist of a single node, ten nodes, a thousand, half of all nodes, all business' nodes, or
                    >      >>         even all the non mining nodes. On another dimension it can have zero mining support, 51% support, 49%
                    >     support,
                    >      >>         or any support right up against a miner activation threshold.
                    >      >>         > > > Hell a UASF doesn't even need code or even a single node running as long as it exists as a possibility
                    >      >>         in people's minds.
                    >      >>         > > > The only thing a UASF doesn't have is miner support above an agreed activation threshold (some number
                    >      >>         above %51).
                    >      >>         > > > I say this because it strikes me when people say that they are for LOT=true with the logic that
                    >     since a
                    >      >>         UASF is guaranteed to happen then it's better to just make it default from the beginning. Words like
                    >      >>         coordination and safety are sometimes sprinkled into the argument.
                    >      >>         > > > The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted
                    >     into
                    >      >>         code. But in fact this isn't true and some voices in this discussion need to be more humble about what users
                    >      >>         must or must not run.
                    >      >>         > > > Does no one realize that it is a very possible outcome that if LOT=true is released there may be
                    >     only a
                    >      >>         handful of people that begin running it while everyone else delays their upgrade (with the very good
                    >     reason of
                    >      >>         not getting involved in politics) and a year later those handful of people just become stuck at the
                    >     moment of
                    >      >>         MUST_SIGNAL, unable to mine new blocks? Or attracting a minority of miners, activating, and forking off
                    >     into a
                    >      >>         minority fork. Then a lot=false could be started that ends up activating the feature now that the stubborn
                    >      >>         option has ran its course.
                    >      >>         > > > The result: a wasted year of waiting and a minority of people who didn't want to be lenient with
                    >     miners
                    >      >>         by default. The chains could be called BitcoinLenient and BitcoinStubborn.
                    >      >>         > > > How is that strictly safer or more coordinated?
                    >      >>         > > > I may be in the minority, or maybe a silent majority, or maybe a majority that just hasn't considered
                    >      >>         this as a choice but honestly if there is contention about whether we're going to be stubborn or lenient
                    >     with
                    >      >>         miners for Taproot and in the future then I prefer to just not activate anything at all. I'm fine for
                    >     calling
                    >      >>         bitcoin ossified, accepting that segwit is Bitcoin's last network upgrade. Taproot is amazing but no new
                    >      >>         feature is worth a network split down the middle.
                    >      >>         > > > Maybe in 10 or 20 years, when other blockchains implement features like Taproot and many more, we will
                    >      >>         become envious enough to put aside our differences on how to behave towards miners and finally activate
                    >     Taproot.
                    >      >>         > > > An activation mechanism is a consensus change like any other change, can be contentious like any other
                    >      >>         change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
                    >      >>         > > > Cheers
                    >      >>         > > > Ariel Lorenzo-Luaces
                    >      >>         > > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev
                    >     <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
                    >      >>         <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>> wrote:
                    >      >>         > > >
                    >      >>         > > > > Yesterday (February 16th) we held a second meeting on Taproot
                    >      >>         > > > > activation on IRC which again was open to all. Despite what appeared
                    >      >>         > > > > to be majority support for LOT=false over LOT=true in the first
                    >      >>         > > > > meeting I (and others) thought the arguments had not been explored in
                    >      >>         > > > > depth and that we should have a follow up meeting almost entirely
                    >      >>         > > > > focused on whether LOT (lockinontimeout) should be set to true or
                    >      >>         > > > > false.
                    >      >>         > > > >
                    >      >>         > > > > The meeting was announced here:
                    >      >>         > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                    >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>
                    >      >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                    >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>>
                    >      >>         > > > >
                    >      >>         > > > > In that mailing list post I outlined the arguments for LOT=true (T1 to
                    >      >>         > > > > T6) and arguments for LOT=false (F1 to F6) in their strongest form I
                    >      >>         > > > > could. David Harding responded with an additional argument for
                    >      >>         > > > > LOT=false (F7) here:
                    >      >>         > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
                    >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html>
                    >      >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
                    >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html>>
                    >      >>         > > > >
                    >      >>         > > > > These meetings are very challenging given they are open to all, you
                    >      >>         > > > > don’t know who will attend and you don’t know most people’s views in
                    >      >>         > > > > advance. I tried to give time for both the LOT=true arguments and the
                    >      >>         > > > > LOT=false arguments to be discussed as I knew there was support for
                    >      >>         > > > > both. We only tried evaluating which had more support and which had
                    >      >>         > > > > more strong opposition towards the end of the meeting.
                    >      >>         > > > >
                    >      >>         > > > > The conversation log is here:
                    >      >>         > > > > http://gnusha.org/taproot-activation/2021-02-16.log
                    >     <http://gnusha.org/taproot-activation/2021-02-16.log> <http://gnusha.org/taproot-activation/2021-02-16.log
                    >     <http://gnusha.org/taproot-activation/2021-02-16.log>>
                    >      >>         > > > >
                    >      >>         > > > > (If you are so inclined you can watch a video of the meeting here.
                    >      >>         > > > > Thanks to the YouTube account “Bitcoin” for setting up the livestream:
                    >      >>         > > > > https://www.youtube.com/watch?v=vpl5q1ovMLM <https://www.youtube.com/watch?v=vpl5q1ovMLM>
                    >     <https://www.youtube.com/watch?v=vpl5q1ovMLM <https://www.youtube.com/watch?v=vpl5q1ovMLM>>)
                    >      >>         > > > >
                    >      >>         > > > > A summary of the meeting was provided by Luke Dashjr on Mastodon here:
                    >      >>         > > > > https://bitcoinhackers.org/@lukedashjr/105742918779234566
                    >     <https://bitcoinhackers.org/@lukedashjr/105742918779234566>
                    >      >>         <https://bitcoinhackers.org/@lukedashjr/105742918779234566
                    >     <https://bitcoinhackers.org/@lukedashjr/105742918779234566>>
                    >      >>         > > > >
                    >      >>         > > > > Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we
                    >      >>         > > > > did manage to come to consensus on everything but LockinOnTimeout.
                    >      >>         > > > >
                    >      >>         > > > > Activation height range: 693504-745920
                    >      >>         > > > >
                    >      >>         > > > > MASF threshold: 1815/2016 blocks (90%)
                    >      >>         > > > >
                    >      >>         > > > > Keep in mind only ~100 people showed for the meetings, hardly
                    >      >>         > > > > representative of the entire community.
                    >      >>         > > > >
                    >      >>         > > > > So, these details remain JUST a proposal for now.
                    >      >>         > > > >
                    >      >>         > > > > It seems inevitable that there won't be consensus on LOT.
                    >      >>         > > > >
                    >      >>         > > > > Everyone will have to choose for himself. :/
                    >      >>         > > > >
                    >      >>         > > > > Personally I agree with most of this. I agree that there wasn’t
                    >      >>         > > > > overwhelming consensus for either LOT=true or LOT=false. However, from
                    >      >>         > > > > my perspective there was clearly more strong opposition (what would
                    >      >>         > > > > usually be deemed a NACK in Bitcoin Core review terminology) from
                    >      >>         > > > > Bitcoin Core contributors, Lightning developers and other community
                    >      >>         > > > > members against LOT=true than there was for LOT=false. Andrew Chow
                    >      >>         > > > > tried to summarize views from the meeting in this analysis:
                    >      >>         > > > > https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
                    >     <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>
                    >      >>         <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
                    >     <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>>
                    >      >>         > > > >
                    >      >>         > > > > I am also aware of other current and previous Bitcoin Core
                    >      >>         > > > > contributors and Lightning developers who didn’t attend the meeting in
                    >      >>         > > > > person who are opposed to LOT=true. I don’t want to put them in the
                    >      >>         > > > > spotlight for no reason but if you go through the conversation logs of
                    >      >>         > > > > not only the meeting but the weeks of discussion prior to this meeting
                    >      >>         > > > > you will see their views evaluated on the ##taproot-activation
                    >      >>         > > > > channel. In addition, on taprootactivation.com <http://taprootactivation.com>
                    >     <http://taprootactivation.com <http://taprootactivation.com>> some mining pools
                    >      >>         > > > > expressed a preference for lot=false though I don’t know how strong
                    >      >>         > > > > that preference was.
                    >      >>         > > > >
                    >      >>         > > > > I am only one voice but it is my current assessment that if we are to
                    >      >>         > > > > attempt to finalize Taproot activation parameters and propose them to
                    >      >>         > > > > the community at this time our only option is to propose LOT=false.
                    >      >>         > > > > Any further delay appears to me counterproductive in our collective
                    >      >>         > > > > aim to get the Taproot soft fork activated as early as possible.
                    >      >>         > > > >
                    >      >>         > > > > Obviously others are free to disagree with that assessment and
                    >      >>         > > > > continue discussions but personally I will be attempting to avoid
                    >      >>         > > > > those discussions unless prominent new information comes to light or
                    >      >>         > > > > various specific individuals change their minds.
                    >      >>         > > > >
                    >      >>         > > > > Next week we are planning a code review of the Bitcoin Core PR #19573
                    >      >>         > > > > which was initially delayed because of this LOT discussion. As I’ve
                    >      >>         > > > > said previously that will be loosely following the format of the
                    >      >>         > > > > Bitcoin Core PR review club and will be lower level and more
                    >      >>         > > > > technical. That is planned for Tuesday February 23rd at 19:00 UTC on
                    >      >>         > > > > the IRC channel ##taproot-activation.
                    >      >>         > > > >
                    >      >>         > > > > Thanks to the meeting participants (and those who joined the
                    >      >>         > > > > discussion on the channel prior and post the meeting) for engaging
                    >      >>         > > > > productively and in good faith.
                    >      >>         > >
                    >      >>         > > --
                    >      >>         > > Michael Folkson
                    >      >>         > > Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com> <mailto:michaelfolkson@gmail•com
                    >     <mailto:michaelfolkson@gmail•com>>
                    >      >>         > > Keybase: michaelfolkson
                    >      >>         > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                    >      >>         > > _______________________________________________
                    >      >>         > > bitcoin-dev mailing list
                    >      >>         > > bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
                    >     <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>
                    >      >>         > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                    >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
                    >      >>         <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                    >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>>
                    >      >>
                    >      >>
                    >      >>
                    >      >>
                    >      >>     --
                    >      >>     Michael Folkson
                    >      >>     Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com> <mailto:michaelfolkson@gmail•com
                    >     <mailto:michaelfolkson@gmail•com>>
                    >      >>     Keybase: michaelfolkson
                    >      >>     PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                    >      >>     _______________________________________________
                    >      >>     bitcoin-dev mailing list
                    >      >> bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
                    >     <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>
                    >      >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                    >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
                    >      >>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                    >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>>
                    >      >
                    >      >
                    >      >
                    >      > --
                    >      > Michael Folkson
                    >      > Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com> <mailto:michaelfolkson@gmail•com
                    >     <mailto:michaelfolkson@gmail•com>>
                    >      > Keybase: michaelfolkson
                    >      > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                    >     _______________________________________________
                    >     bitcoin-dev mailing list
                    >     bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
                    >     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                    >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
                    > 
                    
                    
                    ^ permalink raw reply	[flat|nested] 42+ messages in thread

                  • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                        2021-02-18 15:18                   ` Matt Corallo
                      @ 2021-02-19  2:20                     ` Ariel Luaces
                        2021-02-19 11:30                     ` ZmnSCPxj
                        1 sibling, 0 replies; 42+ messages in thread
                      From: Ariel Luaces @ 2021-02-19  2:20 UTC (permalink / raw)
                        To: Matt Corallo, Bitcoin Protocol Discussion
                      
                      Hi Michael
                      I think you're right, sorry for getting a little apocalyptic at the
                      end there lol.
                      
                      > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org
                      >
                      > Thanks for your response Ariel. It would be useful if you responded to specific points I have made in the mailing list post or at least quote these ephemeral "people" you speak of. I don't know if you're responding to conversation on the IRC channel or on social media etc.
                      > > The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted into code. But in fact this isn't true and some voices in this discussion need to be more humble about what users must or must not run.
                      > I personally have never made this assumption. Of course users aren't forced to run any particular software version, quite the opposite. Defaults set in software versions matter though as many users won't change them.
                      
                      I'm mostly referring to the two IRC discussions. I normally try to
                      avoid singling people out that's why I didn't refer to anyone in
                      perticular.
                      Here I'll list a couple of quotes from these ephemeral people, while
                      reading them keep in mind what would happen if a majority users and
                      miners decide to just avoid the latest version.
                      - 11:06: "LOT=true does not split the chain. It strictly reduces the
                      liklihood of that."
                      - 11:06: "LOT=false has chainsplit risks, not LOT=true"
                      - 08:59 "I guess it would be helpful to hear miners' answers to that question."
                      Response: 09:01 "not sure why; miners don't decide anything in this
                      regard it's more of `Taproot is activating. Please accelerate it if
                      you can`"
                      Reading the logs again I see some voices that do consider the right
                      that users and miners have to run whatever version they want
                      Response: 09:03 "I ask because you said something that's equivalent to
                      `miners don't get to decide which version of core their run`."
                      - T1, T2, T3, and T6 have language that assumes mass support for a
                      UASF and then proceed to make conclusions on what is safer and easier
                      to coordinate
                      A voice in the discussion expressed the same point I'm making:
                      10:53 "I disagree with T1: i don't think there is any logical
                      consequence in hardcoding LOT=true ensuring Taproot activation and
                      even less ensuring no political shenanigans. We obviously need
                      economic majority to run it and that would open way more political
                      arguments that they bluntly take part in an UASF without any bad
                      behaviour from miners."
                      - 11:14 "we know people will run LOT=true regardless of the default,
                      so it will be safer if LOT=true is made the default"
                      - 11:18 "With LOT=true, attempted UASFs are not necessary"
                      - 11:18 "why give them the ability to act maliciously in the first place?"
                      Response:11:18"LOT=false does not; people choosing to run software
                      that will enforce taproot under some reasonable circumstances provides
                      the information.  LOT=false just reduces the risk of unexpected
                      results from resulting in danger."
                      Response: 11:18 "LOT=false strictly increases the risks though.."
                      Response: 11:18 "please stop saying that, there are tradeoffs both ways."
                      - 11:11 "LOT=false gives miners the ability to decide [in response to
                      someone saying that LOT=false gives everyone else in the community the
                      ability to decide]"
                      This quote is a bit more nuanced because the implication is that
                      LOT=true doesn't give the ability to decide. But in reality they have
                      the ability to decide to not upgrade. Users  can also not upgrade to
                      be in solidarity with miners to protect them from unfair distrust and
                      aggression.
                      All the arguments above for LOT=true are rooted in the assumption that
                      everyone must upgrade to the latest version because of course they
                      will...? But that's not a given.
                      
                      There are examples of people being aware that miners and users can run
                      any version they want. I misjudged the number of people who know that
                      LOT=true doesn't guarantee anything.
                      - 11:17 "The LOT=True crowd seems to have an underlying assumption
                      that a UASF will occur instead of something more orderly like Modern
                      Softfork Activation suggested, why? I don't think chances of that
                      happening are very high unless things play out similarly to Segwit but
                      it doesn't look like that."
                      - 11:17 "UASFs can be made much more difficult with a counter-UASF....
                      UASFs like this one and segwit relied on intolerant-minority effects"
                      (I'm assuming counter-UASF means not upgrading as opposed to upgrading
                      to a new client that rejects the activation flag)
                      
                      > There is the (unlikely but possible) possibility of a wasted year if LOT is set to false and miners fail to activate. I'm not convinced by this perception that LOT=true is antagonistic to miners. I actually think it offers them clarity on what will happen over a year time period and removes the need for coordinated or uncoordinated community UASF efforts on top of LOT=false.
                      If you look at https://taprootactivation.com/ no miners seem to be
                      expressing any support at all for lot=true. To pre-empt the counter
                      argument, I know that miners don't decide, I'm just using that poll as
                      a proxy to estimate whether they would be antagonized by the promotion
                      of LOT=true.
                      I'm not a miner and I think the "fork will happen regardless of the
                      consequences" attitude is antagonistic towards everyone in general,
                      not just miners.
                      The LOT=true activation mechanism may be tolerated today because
                      Taproot has wide support. But in order to prevent future antagonistic
                      behavior around future network changes (possibly more controversial
                      ones) we should continue the norm of including miners in the
                      activation process, as the friends they are.
                      This idea that LOT=true provides clarity is another is another example
                      of an argument rooted in the assumption that users will upgrade
                      because of course they will. No activation mechanism provides ANY
                      guarantees and neither does LOT=true so it's infair to frame it as if
                      it does.
                      This is your argument Michael, please don't take anything I say
                      personally I'm just arguing the points.
                      
                      > It is a possible outcome but the likely outcome is that miners activate Taproot before LOT is even relevant. I think it is prudent to prepare for the unlikely but possible outcome that miners fail to activate and hence have this discussion now rather than be unprepared for that eventuality. If LOT is set to false in a software release there is the possibility (T2 in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html) of individuals or a proportion of the community changing LOT to true. In that sense setting LOT=false in a software release appears to be no more safe than LOT=true.
                      If a LOT=true client is released I think the likely outcome is that
                      people won't upgrade at all and I would say that miners failing to
                      activate  will become more likely than you think, strictly due to a
                      loud group promoting LOT=true.
                      It's true that some will stubbornly run LOT=true regardless. But if
                      they have not been provoked to do so then I would hope the community
                      promotes unity and shuns needlessly conflictive attitudes to avoid
                      the, admittedly inevitable, network split from gathering momentum (a
                      counter-UASF).
                      I hope individuals opt for unity and become intolerant (counter-UASF)
                      of intolerance (unprovoked-UASF).
                      
                      > TL;DR It sounds like you agree with my recommendation to set LOT=false in protocol implementations in my email :)
                      Yes I do agree with the recommendation of LOT=false. Thank you for
                      organizing the discussion.
                      
                      On Thu, Feb 18, 2021 at 3:12 AM Samson Mow <samson.mow@gmail•com> wrote:
                      >
                      > "An activation mechanism is a consensus change like any other change, can be contentious like any other change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline."
                      >
                      > Who's we here?
                      By "we" I meant everyone involved in the discussion of the activation
                      mechanism. The discussion is slowly growing and eventually has to
                      reach social media.
                      >
                      > Release both and let the network decide.
                      If two clients are released with matching activation parameters except
                      for opposing LOT then LOT=true kind of spoils the LOT=false choice
                      (only if LOT=true manages to gather support) because running LOT=false
                      is being complicit/tolerant of the aggressive attitude of LOT=true.
                      In the case of both being released I would opt for running neither and
                      I hope most users and miners do too. Again, with the caveat that only
                      if there is visible significant support for LOT=true. And yes, the
                      "significant" is a subjective word and, based on risk appetite, is
                      different for everyone. That's part of the issue.
                      A funny metaphor is that if someone is visibly pissing in a pool I'm
                      not going to swim on the other side of the pool, I just won't swim at
                      all and go do whatever I was doing before.
                      
                      Cheers
                      Ariel Lorenzo-Luaces
                      
                      On Thu, Feb 18, 2021 at 7:18 AM Matt Corallo via bitcoin-dev
                      <bitcoin-dev@lists•linuxfoundation.org> wrote:
                      >
                      > This is absolutely the case, however note that the activation method itself is consensus code which executes as a part
                      > of a fork, and one which deserves as much scrutiny as anything else. While taproot is a model of how a soft-fork should
                      > be designed, this doesn't imply anything about the consensus code which represents the activation thereof.
                      >
                      > Hence all the debate around activation - ultimately its also defining a fork, and given the politics around it, one
                      > which almost certainly carries significantly more risk than Taproot.
                      >
                      > Note that I don't believe anyone is advocating for "try to activate, and if it fails, move on". Various people have
                      > various views on how conservative and timelines for what to do at that point, but I believe most in this discussion are
                      > OK with flag-day-based activation (given some level of care) if it becomes clear Taproot is supported by a vast majority
                      > of Bitcoin users and is only not activating due to lagging miner upgrades.
                      >
                      > Matt
                      >
                      > On 2/18/21 10:04, Keagan McClelland wrote:
                      > > Hi all,
                      > >
                      > > I think it's important for us to consider what is actually being considered for activation here.
                      > >
                      > > The designation of "soft fork" is accurate but I don't think it adequately conveys how non-intrusive a change like this
                      > > is. All that taproot does (unless I'm completely missing something) is imbue a previously undefined script version with
                      > > actual semantics. In order for a chain reorg to take place it would mean that someone would have to have a use case for
                      > > that script version today. This is something I think that we can easily check by digging through the UTXO set or
                      > > history. If anyone is using that script version, we absolutely should not be using it, but that doesn't mean that we
                      > > can't switch to a script version that no one is actually using.
                      > >
                      > > If no one is even attempting to use the script version, then the change has no effect on whether a chain split occurs
                      > > because there is simply no block that contains a transaction that only some of the network will accept.
                      > >
                      > > Furthermore, I don't know how Bitcoin can stand the test of time if we allow developers who rely on "undefined behavior"
                      > > (which the taproot script version presently is) to exert tremendous influence over what code does or does not get run.
                      > > This isn't a soft fork that makes some particular UTXO's unspendable. It isn't one that bans miners from collecting
                      > > fees. It is a change that means that certain "always accept" transactions actually have real conditions you have to
                      > > meet. I can't imagine a less intrusive change.
                      > >
                      > > On the other hand, choosing to let L=F be a somewhat final call sets a very real precedent that 10% of what I estimate
                      > > to be 1% of bitcoin users can effectively block any change from here on forward. At that point we are saying that miners
                      > > are in control of network consensus in ways they have not been up until now. I don't think this is a more desirable
                      > > outcome to let ~0.1% of the network get to block /non-intrusive/ changes that the rest of the network wants.
                      > >
                      > > I can certainly live with an L=F attempt as a way to punt on the discussion, maybe the activation happens and this will
                      > > all be fine. But if it doesn't, I hardly think that users of Bitcoin are just going to be like "well, guess that's it
                      > > for Taproot". I have no idea what ensues at that point, but probably another community led UASF movement.
                      > >
                      > > I wasn't super well educated on this stuff back in '17 when Segwit went down, as I was new at that time, so if I'm
                      > > missing something please say so. But from my point of view, we can't treat all soft forks as equal.
                      > >
                      > > Keagan
                      > >
                      > > On Thu, Feb 18, 2021 at 7:43 AM Matt Corallo via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org
                      > > <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
                      > >
                      > >     We've had several softforks in Bitcoin which, through the course of their activation, had a several-block reorg. That
                      > >     should be indication enough that we need to very carefully consider activation to ensure we reduce the risk of that as
                      > >     much as absolutely possible. Again, while I think Taproot is a huge improvement and am looking forward to being able to
                      > >     use it, getting unlucky and hitting a 4-block reorg that happens to include a double-spend and some PR around an
                      > >     exchange losing millions would be worse than having Taproot is good.
                      > >
                      > >     Matt
                      > >
                      > >     On 2/18/21 09:26, Michael Folkson wrote:
                      > >      > Thanks for your response Matt. It is a fair challenge. There is always going to be an element of risk with soft
                      > >     forks,
                      > >      > all we can do is attempt to minimize that risk. I would argue that risk has been minimized for Taproot.
                      > >      >
                      > >      > You know (better than I do in fact) that Bitcoin (and layers built on top of it) greatly benefit from upgrades
                      > >     such as
                      > >      > Taproot. To say we shouldn't do Taproot or any future soft forks because there is a small but real risk of chain
                      > >     splits
                      > >      > I think is shortsighted. Indeed I think even if we collectively decided not to do any future soft fork upgrades ever
                      > >      > again on this mailing list that wouldn't stop soft fork attempts from other people in future.
                      > >      >
                      > >      > I don't think there is anything else we can do to minimize that risk for the Taproot soft fork at this point
                      > >     though I'm
                      > >      > open to ideas. To reiterate that risk will never be zero. I don't think I see Bitcoin as fragile as you seem to
                      > >     (though
                      > >      > admittedly you have a much better understanding than me of what happened in 2017).
                      > >      >
                      > >      > The likely scenario for the Taproot soft fork is LOT turns out to be entirely irrelevant and miners activate Taproot
                      > >      > before it becomes relevant. And even the unlikely worst case scenario would only cause short term disruption and
                      > >      > wouldn't kill Bitcoin long term.
                      > >      >
                      > >      > On Thu, Feb 18, 2021 at 2:01 PM Matt Corallo <lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo•com>
                      > >     <mailto:lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo•com>>> wrote:
                      > >      >
                      > >      >     If the eventual outcome is that different implementations (that have material *transaction processing* userbases,
                      > >      >     and I’m not sure to what extent that’s true with Knots) ship different consensus rules, we should stop here
                      > >     and not
                      > >      >     activate Taproot. Seriously.
                      > >      >
                      > >      >     Bitcoin is a consensus system. The absolute worst outcome at all possible is to have it fall out of consensus.
                      > >      >
                      > >      >     Matt
                      > >      >
                      > >      >>     On Feb 18, 2021, at 08:11, Michael Folkson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org
                      > >     <mailto:bitcoin-dev@lists•linuxfoundation.org>
                      > >      >>     <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>> wrote:
                      > >      >>
                      > >      >>     
                      > >      >>     Right, that is one option. Personally I would prefer a Bitcoin Core release sets LOT=false (based on what I have
                      > >      >>     heard from Bitcoin Core contributors) and a community effort releases a version with LOT=true. I don't think
                      > >     users
                      > >      >>     should be forced to choose something they may have no context on before they are allowed to use Bitcoin Core.
                      > >      >>
                      > >      >>     My current understanding is that roasbeef is planning to set LOT=false on btcd (an alternative protocol
                      > >      >>     implementation to Bitcoin Core) and Luke Dashjr hasn't yet decided on Bitcoin Knots.
                      > >      >>
                      > >      >>
                      > >      >>
                      > >      >>     On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <ZmnSCPxj@protonmail•com <mailto:ZmnSCPxj@protonmail•com>
                      > >     <mailto:ZmnSCPxj@protonmail•com <mailto:ZmnSCPxj@protonmail•com>>> wrote:
                      > >      >>
                      > >      >>         Good morning all,
                      > >      >>
                      > >      >>         > "An activation mechanism is a consensus change like any other change, can be contentious like any other
                      > >      >>         change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline."
                      > >      >>         >
                      > >      >>         > Who's we here?
                      > >      >>         >
                      > >      >>         > Release both and let the network decide.
                      > >      >>
                      > >      >>         A thing that could be done, without mandating either LOT=true or LOT=false, would be to have a release that
                      > >      >>         requires a `taprootlot=1` or `taprootlot=0` and refuses to start if the parameter is not set.
                      > >      >>
                      > >      >>         This assures everyone that neither choice is being forced on users, and instead what is being forced on
                      > >     users,
                      > >      >>         is for users to make that choice themselves.
                      > >      >>
                      > >      >>         Regards,
                      > >      >>         ZmnSCPxj
                      > >      >>
                      > >      >>         >
                      > >      >>         > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org
                      > >     <mailto:bitcoin-dev@lists•linuxfoundation.org>
                      > >      >>         <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>> wrote:
                      > >      >>         >
                      > >      >>         > > Thanks for your response Ariel. It would be useful if you responded to specific points I have made
                      > >     in the
                      > >      >>         mailing list post or at least quote these ephemeral "people" you speak of. I don't know if you're responding
                      > >      >>         to conversation on the IRC channel or on social media etc.
                      > >      >>         > >
                      > >      >>         > > > The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted
                      > >     into
                      > >      >>         code. But in fact this isn't true and some voices in this discussion need to be more humble about what users
                      > >      >>         must or must not run.
                      > >      >>         > >
                      > >      >>         > > I personally have never made this assumption. Of course users aren't forced to run any particular
                      > >     software
                      > >      >>         version, quite the opposite. Defaults set in software versions matter though as many users won't change
                      > >     them.
                      > >      >>         > >
                      > >      >>         > > > Does no one realize that it is a very possible outcome that if LOT=true is released there may be
                      > >     only a
                      > >      >>         handful of people that begin running it while everyone else delays their upgrade (with the very good
                      > >     reason of
                      > >      >>         not getting involved in politics) and a year later those handful of people just become stuck at the
                      > >     moment of
                      > >      >>         MUST_SIGNAL, unable to mine new blocks?
                      > >      >>         > >
                      > >      >>         > > It is a possible outcome but the likely outcome is that miners activate Taproot before LOT is even
                      > >      >>         relevant. I think it is prudent to prepare for the unlikely but possible outcome that miners fail to
                      > >     activate
                      > >      >>         and hence have this discussion now rather than be unprepared for that eventuality. If LOT is set to
                      > >     false in a
                      > >      >>         software release there is the possibility (T2 in
                      > >      >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                      > >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>
                      > >      >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                      > >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>>) of individuals or a
                      > >      >>         proportion of the community changing LOT to true. In that sense setting LOT=false in a software release
                      > >      >>         appears to be no more safe than LOT=true.
                      > >      >>         > >
                      > >      >>         > > > The result: a wasted year of waiting and a minority of people who didn't want to be lenient with
                      > >     miners
                      > >      >>         by default.
                      > >      >>         > >
                      > >      >>         > > There is the (unlikely but possible) possibility of a wasted year if LOT is set to false and miners fail
                      > >      >>         to activate. I'm not convinced by this perception that LOT=true is antagonistic to miners. I actually
                      > >     think it
                      > >      >>         offers them clarity on what will happen over a year time period and removes the need for coordinated or
                      > >      >>         uncoordinated community UASF efforts on top of LOT=false.
                      > >      >>         > >
                      > >      >>         > > > An activation mechanism is a consensus change like any other change, can be contentious like any other
                      > >      >>         change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
                      > >      >>         > >
                      > >      >>         > > I don't know what you are recommending here to avoid "this darkest timeline". Open discussions have
                      > >      >>         occurred and are continuing and in my mailing list post that you responded to **I recommended we propose
                      > >      >>         LOT=false be set in protocol implementations such as Bitcoin Core**. I do think this apocalyptic language
                      > >      >>         isn't particularly helpful. In an open consensus system discussion is healthy, we should prepare for bad or
                      > >      >>         worst case scenarios in advance and doing so is not antagonistic or destructive. Mining pools have pledged
                      > >      >>         support for Taproot but we don't build secure systems based on pledges of support, we build them to minimize
                      > >      >>         trust in any human actors. We can be grateful that people like Alejandro have worked hard on
                      > >      >> taprootactivation.com <http://taprootactivation.com> <http://taprootactivation.com
                      > >     <http://taprootactivation.com>> (and this effort has informed the discussion) without
                      > >      >>         taking pledges of support as cast iron guarantees.
                      > >      >>         > >
                      > >      >>         > > TL;DR It sounds like you agree with my recommendation to set LOT=false in protocol implementations in my
                      > >      >>         email :)
                      > >      >>         > >
                      > >      >>         > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <arielluaces@gmail•com
                      > >     <mailto:arielluaces@gmail•com>
                      > >      >>         <mailto:arielluaces@gmail•com <mailto:arielluaces@gmail•com>>> wrote:
                      > >      >>         > >
                      > >      >>         > > > Something what strikes me about the conversation is the emotion surrounding the letters UASF.
                      > >      >>         > > > It appears as if people discuss UASF as if it's a massive tidal wave of support that is
                      > >     inevitable, like
                      > >      >>         we saw during segwit activation. But the actual definition is "any activation that is not a MASF".
                      > >      >>         > > > A UASF can consist of a single node, ten nodes, a thousand, half of all nodes, all business' nodes, or
                      > >      >>         even all the non mining nodes. On another dimension it can have zero mining support, 51% support, 49%
                      > >     support,
                      > >      >>         or any support right up against a miner activation threshold.
                      > >      >>         > > > Hell a UASF doesn't even need code or even a single node running as long as it exists as a possibility
                      > >      >>         in people's minds.
                      > >      >>         > > > The only thing a UASF doesn't have is miner support above an agreed activation threshold (some number
                      > >      >>         above %51).
                      > >      >>         > > > I say this because it strikes me when people say that they are for LOT=true with the logic that
                      > >     since a
                      > >      >>         UASF is guaranteed to happen then it's better to just make it default from the beginning. Words like
                      > >      >>         coordination and safety are sometimes sprinkled into the argument.
                      > >      >>         > > > The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted
                      > >     into
                      > >      >>         code. But in fact this isn't true and some voices in this discussion need to be more humble about what users
                      > >      >>         must or must not run.
                      > >      >>         > > > Does no one realize that it is a very possible outcome that if LOT=true is released there may be
                      > >     only a
                      > >      >>         handful of people that begin running it while everyone else delays their upgrade (with the very good
                      > >     reason of
                      > >      >>         not getting involved in politics) and a year later those handful of people just become stuck at the
                      > >     moment of
                      > >      >>         MUST_SIGNAL, unable to mine new blocks? Or attracting a minority of miners, activating, and forking off
                      > >     into a
                      > >      >>         minority fork. Then a lot=false could be started that ends up activating the feature now that the stubborn
                      > >      >>         option has ran its course.
                      > >      >>         > > > The result: a wasted year of waiting and a minority of people who didn't want to be lenient with
                      > >     miners
                      > >      >>         by default. The chains could be called BitcoinLenient and BitcoinStubborn.
                      > >      >>         > > > How is that strictly safer or more coordinated?
                      > >      >>         > > > I may be in the minority, or maybe a silent majority, or maybe a majority that just hasn't considered
                      > >      >>         this as a choice but honestly if there is contention about whether we're going to be stubborn or lenient
                      > >     with
                      > >      >>         miners for Taproot and in the future then I prefer to just not activate anything at all. I'm fine for
                      > >     calling
                      > >      >>         bitcoin ossified, accepting that segwit is Bitcoin's last network upgrade. Taproot is amazing but no new
                      > >      >>         feature is worth a network split down the middle.
                      > >      >>         > > > Maybe in 10 or 20 years, when other blockchains implement features like Taproot and many more, we will
                      > >      >>         become envious enough to put aside our differences on how to behave towards miners and finally activate
                      > >     Taproot.
                      > >      >>         > > > An activation mechanism is a consensus change like any other change, can be contentious like any other
                      > >      >>         change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
                      > >      >>         > > > Cheers
                      > >      >>         > > > Ariel Lorenzo-Luaces
                      > >      >>         > > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev
                      > >     <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
                      > >      >>         <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>> wrote:
                      > >      >>         > > >
                      > >      >>         > > > > Yesterday (February 16th) we held a second meeting on Taproot
                      > >      >>         > > > > activation on IRC which again was open to all. Despite what appeared
                      > >      >>         > > > > to be majority support for LOT=false over LOT=true in the first
                      > >      >>         > > > > meeting I (and others) thought the arguments had not been explored in
                      > >      >>         > > > > depth and that we should have a follow up meeting almost entirely
                      > >      >>         > > > > focused on whether LOT (lockinontimeout) should be set to true or
                      > >      >>         > > > > false.
                      > >      >>         > > > >
                      > >      >>         > > > > The meeting was announced here:
                      > >      >>         > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                      > >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>
                      > >      >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                      > >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>>
                      > >      >>         > > > >
                      > >      >>         > > > > In that mailing list post I outlined the arguments for LOT=true (T1 to
                      > >      >>         > > > > T6) and arguments for LOT=false (F1 to F6) in their strongest form I
                      > >      >>         > > > > could. David Harding responded with an additional argument for
                      > >      >>         > > > > LOT=false (F7) here:
                      > >      >>         > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
                      > >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html>
                      > >      >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
                      > >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html>>
                      > >      >>         > > > >
                      > >      >>         > > > > These meetings are very challenging given they are open to all, you
                      > >      >>         > > > > don’t know who will attend and you don’t know most people’s views in
                      > >      >>         > > > > advance. I tried to give time for both the LOT=true arguments and the
                      > >      >>         > > > > LOT=false arguments to be discussed as I knew there was support for
                      > >      >>         > > > > both. We only tried evaluating which had more support and which had
                      > >      >>         > > > > more strong opposition towards the end of the meeting.
                      > >      >>         > > > >
                      > >      >>         > > > > The conversation log is here:
                      > >      >>         > > > > http://gnusha.org/taproot-activation/2021-02-16.log
                      > >     <http://gnusha.org/taproot-activation/2021-02-16.log> <http://gnusha.org/taproot-activation/2021-02-16.log
                      > >     <http://gnusha.org/taproot-activation/2021-02-16.log>>
                      > >      >>         > > > >
                      > >      >>         > > > > (If you are so inclined you can watch a video of the meeting here.
                      > >      >>         > > > > Thanks to the YouTube account “Bitcoin” for setting up the livestream:
                      > >      >>         > > > > https://www.youtube.com/watch?v=vpl5q1ovMLM <https://www.youtube.com/watch?v=vpl5q1ovMLM>
                      > >     <https://www.youtube.com/watch?v=vpl5q1ovMLM <https://www.youtube.com/watch?v=vpl5q1ovMLM>>)
                      > >      >>         > > > >
                      > >      >>         > > > > A summary of the meeting was provided by Luke Dashjr on Mastodon here:
                      > >      >>         > > > > https://bitcoinhackers.org/@lukedashjr/105742918779234566
                      > >     <https://bitcoinhackers.org/@lukedashjr/105742918779234566>
                      > >      >>         <https://bitcoinhackers.org/@lukedashjr/105742918779234566
                      > >     <https://bitcoinhackers.org/@lukedashjr/105742918779234566>>
                      > >      >>         > > > >
                      > >      >>         > > > > Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we
                      > >      >>         > > > > did manage to come to consensus on everything but LockinOnTimeout.
                      > >      >>         > > > >
                      > >      >>         > > > > Activation height range: 693504-745920
                      > >      >>         > > > >
                      > >      >>         > > > > MASF threshold: 1815/2016 blocks (90%)
                      > >      >>         > > > >
                      > >      >>         > > > > Keep in mind only ~100 people showed for the meetings, hardly
                      > >      >>         > > > > representative of the entire community.
                      > >      >>         > > > >
                      > >      >>         > > > > So, these details remain JUST a proposal for now.
                      > >      >>         > > > >
                      > >      >>         > > > > It seems inevitable that there won't be consensus on LOT.
                      > >      >>         > > > >
                      > >      >>         > > > > Everyone will have to choose for himself. :/
                      > >      >>         > > > >
                      > >      >>         > > > > Personally I agree with most of this. I agree that there wasn’t
                      > >      >>         > > > > overwhelming consensus for either LOT=true or LOT=false. However, from
                      > >      >>         > > > > my perspective there was clearly more strong opposition (what would
                      > >      >>         > > > > usually be deemed a NACK in Bitcoin Core review terminology) from
                      > >      >>         > > > > Bitcoin Core contributors, Lightning developers and other community
                      > >      >>         > > > > members against LOT=true than there was for LOT=false. Andrew Chow
                      > >      >>         > > > > tried to summarize views from the meeting in this analysis:
                      > >      >>         > > > > https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
                      > >     <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>
                      > >      >>         <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
                      > >     <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>>
                      > >      >>         > > > >
                      > >      >>         > > > > I am also aware of other current and previous Bitcoin Core
                      > >      >>         > > > > contributors and Lightning developers who didn’t attend the meeting in
                      > >      >>         > > > > person who are opposed to LOT=true. I don’t want to put them in the
                      > >      >>         > > > > spotlight for no reason but if you go through the conversation logs of
                      > >      >>         > > > > not only the meeting but the weeks of discussion prior to this meeting
                      > >      >>         > > > > you will see their views evaluated on the ##taproot-activation
                      > >      >>         > > > > channel. In addition, on taprootactivation.com <http://taprootactivation.com>
                      > >     <http://taprootactivation.com <http://taprootactivation.com>> some mining pools
                      > >      >>         > > > > expressed a preference for lot=false though I don’t know how strong
                      > >      >>         > > > > that preference was.
                      > >      >>         > > > >
                      > >      >>         > > > > I am only one voice but it is my current assessment that if we are to
                      > >      >>         > > > > attempt to finalize Taproot activation parameters and propose them to
                      > >      >>         > > > > the community at this time our only option is to propose LOT=false.
                      > >      >>         > > > > Any further delay appears to me counterproductive in our collective
                      > >      >>         > > > > aim to get the Taproot soft fork activated as early as possible.
                      > >      >>         > > > >
                      > >      >>         > > > > Obviously others are free to disagree with that assessment and
                      > >      >>         > > > > continue discussions but personally I will be attempting to avoid
                      > >      >>         > > > > those discussions unless prominent new information comes to light or
                      > >      >>         > > > > various specific individuals change their minds.
                      > >      >>         > > > >
                      > >      >>         > > > > Next week we are planning a code review of the Bitcoin Core PR #19573
                      > >      >>         > > > > which was initially delayed because of this LOT discussion. As I’ve
                      > >      >>         > > > > said previously that will be loosely following the format of the
                      > >      >>         > > > > Bitcoin Core PR review club and will be lower level and more
                      > >      >>         > > > > technical. That is planned for Tuesday February 23rd at 19:00 UTC on
                      > >      >>         > > > > the IRC channel ##taproot-activation.
                      > >      >>         > > > >
                      > >      >>         > > > > Thanks to the meeting participants (and those who joined the
                      > >      >>         > > > > discussion on the channel prior and post the meeting) for engaging
                      > >      >>         > > > > productively and in good faith.
                      > >      >>         > >
                      > >      >>         > > --
                      > >      >>         > > Michael Folkson
                      > >      >>         > > Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com> <mailto:michaelfolkson@gmail•com
                      > >     <mailto:michaelfolkson@gmail•com>>
                      > >      >>         > > Keybase: michaelfolkson
                      > >      >>         > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                      > >      >>         > > _______________________________________________
                      > >      >>         > > bitcoin-dev mailing list
                      > >      >>         > > bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
                      > >     <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>
                      > >      >>         > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                      > >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
                      > >      >>         <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                      > >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>>
                      > >      >>
                      > >      >>
                      > >      >>
                      > >      >>
                      > >      >>     --
                      > >      >>     Michael Folkson
                      > >      >>     Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com> <mailto:michaelfolkson@gmail•com
                      > >     <mailto:michaelfolkson@gmail•com>>
                      > >      >>     Keybase: michaelfolkson
                      > >      >>     PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                      > >      >>     _______________________________________________
                      > >      >>     bitcoin-dev mailing list
                      > >      >> bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
                      > >     <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>
                      > >      >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                      > >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
                      > >      >>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                      > >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>>
                      > >      >
                      > >      >
                      > >      >
                      > >      > --
                      > >      > Michael Folkson
                      > >      > Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com> <mailto:michaelfolkson@gmail•com
                      > >     <mailto:michaelfolkson@gmail•com>>
                      > >      > Keybase: michaelfolkson
                      > >      > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                      > >     _______________________________________________
                      > >     bitcoin-dev mailing list
                      > >     bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
                      > >     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                      > >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
                      > >
                      > _______________________________________________
                      > bitcoin-dev mailing list
                      > bitcoin-dev@lists•linuxfoundation.org
                      > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                      
                      
                      
                      ^ permalink raw reply	[flat|nested] 42+ messages in thread

                    • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                        2021-02-18 15:18                   ` Matt Corallo
                        2021-02-19  2:20                     ` Ariel Luaces
                      @ 2021-02-19 11:30                     ` ZmnSCPxj
                        2021-02-19 12:05                       ` Adam Back
                        1 sibling, 1 reply; 42+ messages in thread
                      From: ZmnSCPxj @ 2021-02-19 11:30 UTC (permalink / raw)
                        To: Matt Corallo, Bitcoin Protocol Discussion; +Cc: Michael Folkson
                      
                      Good morning list,
                      
                      > This is absolutely the case, however note that the activation method itself is consensus code which executes as a part
                      > of a fork, and one which deserves as much scrutiny as anything else. While taproot is a model of how a soft-fork should
                      > be designed, this doesn't imply anything about the consensus code which represents the activation thereof.
                      >
                      > Hence all the debate around activation - ultimately its also defining a fork, and given the politics around it, one
                      > which almost certainly carries significantly more risk than Taproot.
                      >
                      > Note that I don't believe anyone is advocating for "try to activate, and if it fails, move on". Various people have
                      > various views on how conservative and timelines for what to do at that point, but I believe most in this discussion are
                      > OK with flag-day-based activation (given some level of care) if it becomes clear Taproot is supported by a vast majority
                      > of Bitcoin users and is only not activating due to lagging miner upgrades.
                      
                      
                      Okay, I am backing off this proposal to force the LOT=false/true decision on users, it was not particularly serious anyway (and was more a reaction to the request of Samson Mow to just release both versions, which to my mind is no different from such a thing).
                      
                      
                      Nonetheless, as a thought experiment: the main issue is that some number of people run LOT=true when miners do not activate Taproot early for some reason and we decide to leave LOT=false for this particular bit until it times out.
                      The issue is that those people will get forked off the network at the end of this particular deployment attempt.
                      
                      I suspect those people will still exist whether or not Bitcoin Core supports any kind of LOT=true mode.
                      ("Never again" for some people)
                      
                      How do we convince them to go run LOT=false instead of getting themselves forked off?
                      Or do we simply let them?
                      
                      (and how is that different from asking each user to decide on LOT=false/true right now?)
                      ("reasonable default"?)
                      (fundamentally speaking you still have to educate the users on the ramifications of accepting the default and changing it.)
                      
                      
                      Another thought experiment: From the point of view of a user who strongly supports LOT=true, would dev consensus around releasing LOT=false be considered as "developers forcing their views on users"?
                      Why or why not?
                      
                      
                      Regards,
                      ZmnSCPxj
                      
                      > Matt
                      >
                      > On 2/18/21 10:04, Keagan McClelland wrote:
                      >
                      > > Hi all,
                      > > I think it's important for us to consider what is actually being considered for activation here.
                      > > The designation of "soft fork" is accurate but I don't think it adequately conveys how non-intrusive a change like this
                      > > is. All that taproot does (unless I'm completely missing something) is imbue a previously undefined script version with
                      > > actual semantics. In order for a chain reorg to take place it would mean that someone would have to have a use case for
                      > > that script version today. This is something I think that we can easily check by digging through the UTXO set or
                      > > history. If anyone is using that script version, we absolutely should not be using it, but that doesn't mean that we
                      > > can't switch to a script version that no one is actually using.
                      > > If no one is even attempting to use the script version, then the change has no effect on whether a chain split occurs
                      > > because there is simply no block that contains a transaction that only some of the network will accept.
                      > > Furthermore, I don't know how Bitcoin can stand the test of time if we allow developers who rely on "undefined behavior"
                      > > (which the taproot script version presently is) to exert tremendous influence over what code does or does not get run.
                      > > This isn't a soft fork that makes some particular UTXO's unspendable. It isn't one that bans miners from collecting
                      > > fees. It is a change that means that certain "always accept" transactions actually have real conditions you have to
                      > > meet. I can't imagine a less intrusive change.
                      > > On the other hand, choosing to let L=F be a somewhat final call sets a very real precedent that 10% of what I estimate
                      > > to be 1% of bitcoin users can effectively block any change from here on forward. At that point we are saying that miners
                      > > are in control of network consensus in ways they have not been up until now. I don't think this is a more desirable
                      > > outcome to let ~0.1% of the network get to block /non-intrusive/ changes that the rest of the network wants.
                      > > I can certainly live with an L=F attempt as a way to punt on the discussion, maybe the activation happens and this will
                      > > all be fine. But if it doesn't, I hardly think that users of Bitcoin are just going to be like "well, guess that's it
                      > > for Taproot". I have no idea what ensues at that point, but probably another community led UASF movement.
                      > > I wasn't super well educated on this stuff back in '17 when Segwit went down, as I was new at that time, so if I'm
                      > > missing something please say so. But from my point of view, we can't treat all soft forks as equal.
                      > > Keagan
                      > > On Thu, Feb 18, 2021 at 7:43 AM Matt Corallo via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org
                      > > mailto:bitcoin-dev@lists•linuxfoundation.org> wrote:
                      > >
                      > >     We've had several softforks in Bitcoin which, through the course of their activation, had a several-block reorg. That
                      > >     should be indication enough that we need to very carefully consider activation to ensure we reduce the risk of that as
                      > >     much as absolutely possible. Again, while I think Taproot is a huge improvement and am looking forward to being able to
                      > >     use it, getting unlucky and hitting a 4-block reorg that happens to include a double-spend and some PR around an
                      > >     exchange losing millions would be worse than having Taproot is good.
                      > >
                      > >     Matt
                      > >
                      > >     On 2/18/21 09:26, Michael Folkson wrote:
                      > >      > Thanks for your response Matt. It is a fair challenge. There is always going to be an element of risk with soft
                      > >     forks,
                      > >      > all we can do is attempt to minimize that risk. I would argue that risk has been minimized for Taproot.
                      > >      >
                      > >      > You know (better than I do in fact) that Bitcoin (and layers built on top of it) greatly benefit from upgrades
                      > >     such as
                      > >      > Taproot. To say we shouldn't do Taproot or any future soft forks because there is a small but real risk of chain
                      > >     splits
                      > >      > I think is shortsighted. Indeed I think even if we collectively decided not to do any future soft fork upgrades ever
                      > >      > again on this mailing list that wouldn't stop soft fork attempts from other people in future.
                      > >      >
                      > >      > I don't think there is anything else we can do to minimize that risk for the Taproot soft fork at this point
                      > >     though I'm
                      > >      > open to ideas. To reiterate that risk will never be zero. I don't think I see Bitcoin as fragile as you seem to
                      > >     (though
                      > >      > admittedly you have a much better understanding than me of what happened in 2017).
                      > >      >
                      > >      > The likely scenario for the Taproot soft fork is LOT turns out to be entirely irrelevant and miners activate Taproot
                      > >      > before it becomes relevant. And even the unlikely worst case scenario would only cause short term disruption and
                      > >      > wouldn't kill Bitcoin long term.
                      > >      >
                      > >      > On Thu, Feb 18, 2021 at 2:01 PM Matt Corallo <lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo•com>
                      > >     <mailto:lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo•com>>> wrote:
                      > >      >
                      > >      >     If the eventual outcome is that different implementations (that have material *transaction processing* userbases,
                      > >      >     and I’m not sure to what extent that’s true with Knots) ship different consensus rules, we should stop here
                      > >     and not
                      > >      >     activate Taproot. Seriously.
                      > >      >
                      > >      >     Bitcoin is a consensus system. The absolute worst outcome at all possible is to have it fall out of consensus.
                      > >      >
                      > >      >     Matt
                      > >      >
                      > >      >>     On Feb 18, 2021, at 08:11, Michael Folkson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org
                      > >     <mailto:bitcoin-dev@lists•linuxfoundation.org>
                      > >      >>     <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>> wrote:
                      > >      >>
                      > >      >>     
                      > >      >>     Right, that is one option. Personally I would prefer a Bitcoin Core release sets LOT=false (based on what I have
                      > >      >>     heard from Bitcoin Core contributors) and a community effort releases a version with LOT=true. I don't think
                      > >     users
                      > >      >>     should be forced to choose something they may have no context on before they are allowed to use Bitcoin Core.
                      > >      >>
                      > >      >>     My current understanding is that roasbeef is planning to set LOT=false on btcd (an alternative protocol
                      > >      >>     implementation to Bitcoin Core) and Luke Dashjr hasn't yet decided on Bitcoin Knots.
                      > >      >>
                      > >      >>
                      > >      >>
                      > >      >>     On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <ZmnSCPxj@protonmail•com <mailto:ZmnSCPxj@protonmail•com>
                      > >     <mailto:ZmnSCPxj@protonmail•com <mailto:ZmnSCPxj@protonmail•com>>> wrote:
                      > >      >>
                      > >      >>         Good morning all,
                      > >      >>
                      > >      >>         > "An activation mechanism is a consensus change like any other change, can be contentious like any other
                      > >      >>         change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline."
                      > >      >>         >
                      > >      >>         > Who's we here?
                      > >      >>         >
                      > >      >>         > Release both and let the network decide.
                      > >      >>
                      > >      >>         A thing that could be done, without mandating either LOT=true or LOT=false, would be to have a release that
                      > >      >>         requires a `taprootlot=1` or `taprootlot=0` and refuses to start if the parameter is not set.
                      > >      >>
                      > >      >>         This assures everyone that neither choice is being forced on users, and instead what is being forced on
                      > >     users,
                      > >      >>         is for users to make that choice themselves.
                      > >      >>
                      > >      >>         Regards,
                      > >      >>         ZmnSCPxj
                      > >      >>
                      > >      >>         >
                      > >      >>         > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org
                      > >     <mailto:bitcoin-dev@lists•linuxfoundation.org>
                      > >      >>         <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>> wrote:
                      > >      >>         >
                      > >      >>         > > Thanks for your response Ariel. It would be useful if you responded to specific points I have made
                      > >     in the
                      > >      >>         mailing list post or at least quote these ephemeral "people" you speak of. I don't know if you're responding
                      > >      >>         to conversation on the IRC channel or on social media etc.
                      > >      >>         > >
                      > >      >>         > > > The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted
                      > >     into
                      > >      >>         code. But in fact this isn't true and some voices in this discussion need to be more humble about what users
                      > >      >>         must or must not run.
                      > >      >>         > >
                      > >      >>         > > I personally have never made this assumption. Of course users aren't forced to run any particular
                      > >     software
                      > >      >>         version, quite the opposite. Defaults set in software versions matter though as many users won't change
                      > >     them.
                      > >      >>         > >
                      > >      >>         > > > Does no one realize that it is a very possible outcome that if LOT=true is released there may be
                      > >     only a
                      > >      >>         handful of people that begin running it while everyone else delays their upgrade (with the very good
                      > >     reason of
                      > >      >>         not getting involved in politics) and a year later those handful of people just become stuck at the
                      > >     moment of
                      > >      >>         MUST_SIGNAL, unable to mine new blocks?
                      > >      >>         > >
                      > >      >>         > > It is a possible outcome but the likely outcome is that miners activate Taproot before LOT is even
                      > >      >>         relevant. I think it is prudent to prepare for the unlikely but possible outcome that miners fail to
                      > >     activate
                      > >      >>         and hence have this discussion now rather than be unprepared for that eventuality. If LOT is set to
                      > >     false in a
                      > >      >>         software release there is the possibility (T2 in
                      > >      >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                      > >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>
                      > >      >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                      > >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>>) of individuals or a
                      > >      >>         proportion of the community changing LOT to true. In that sense setting LOT=false in a software release
                      > >      >>         appears to be no more safe than LOT=true.
                      > >      >>         > >
                      > >      >>         > > > The result: a wasted year of waiting and a minority of people who didn't want to be lenient with
                      > >     miners
                      > >      >>         by default.
                      > >      >>         > >
                      > >      >>         > > There is the (unlikely but possible) possibility of a wasted year if LOT is set to false and miners fail
                      > >      >>         to activate. I'm not convinced by this perception that LOT=true is antagonistic to miners. I actually
                      > >     think it
                      > >      >>         offers them clarity on what will happen over a year time period and removes the need for coordinated or
                      > >      >>         uncoordinated community UASF efforts on top of LOT=false.
                      > >      >>         > >
                      > >      >>         > > > An activation mechanism is a consensus change like any other change, can be contentious like any other
                      > >      >>         change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
                      > >      >>         > >
                      > >      >>         > > I don't know what you are recommending here to avoid "this darkest timeline". Open discussions have
                      > >      >>         occurred and are continuing and in my mailing list post that you responded to **I recommended we propose
                      > >      >>         LOT=false be set in protocol implementations such as Bitcoin Core**. I do think this apocalyptic language
                      > >      >>         isn't particularly helpful. In an open consensus system discussion is healthy, we should prepare for bad or
                      > >      >>         worst case scenarios in advance and doing so is not antagonistic or destructive. Mining pools have pledged
                      > >      >>         support for Taproot but we don't build secure systems based on pledges of support, we build them to minimize
                      > >      >>         trust in any human actors. We can be grateful that people like Alejandro have worked hard on
                      > >      >> taprootactivation.com <http://taprootactivation.com> <http://taprootactivation.com
                      > >     <http://taprootactivation.com>> (and this effort has informed the discussion) without
                      > >      >>         taking pledges of support as cast iron guarantees.
                      > >      >>         > >
                      > >      >>         > > TL;DR It sounds like you agree with my recommendation to set LOT=false in protocol implementations in my
                      > >      >>         email :)
                      > >      >>         > >
                      > >      >>         > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <arielluaces@gmail•com
                      > >     <mailto:arielluaces@gmail•com>
                      > >      >>         <mailto:arielluaces@gmail•com <mailto:arielluaces@gmail•com>>> wrote:
                      > >      >>         > >
                      > >      >>         > > > Something what strikes me about the conversation is the emotion surrounding the letters UASF.
                      > >      >>         > > > It appears as if people discuss UASF as if it's a massive tidal wave of support that is
                      > >     inevitable, like
                      > >      >>         we saw during segwit activation. But the actual definition is "any activation that is not a MASF".
                      > >      >>         > > > A UASF can consist of a single node, ten nodes, a thousand, half of all nodes, all business' nodes, or
                      > >      >>         even all the non mining nodes. On another dimension it can have zero mining support, 51% support, 49%
                      > >     support,
                      > >      >>         or any support right up against a miner activation threshold.
                      > >      >>         > > > Hell a UASF doesn't even need code or even a single node running as long as it exists as a possibility
                      > >      >>         in people's minds.
                      > >      >>         > > > The only thing a UASF doesn't have is miner support above an agreed activation threshold (some number
                      > >      >>         above %51).
                      > >      >>         > > > I say this because it strikes me when people say that they are for LOT=true with the logic that
                      > >     since a
                      > >      >>         UASF is guaranteed to happen then it's better to just make it default from the beginning. Words like
                      > >      >>         coordination and safety are sometimes sprinkled into the argument.
                      > >      >>         > > > The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted
                      > >     into
                      > >      >>         code. But in fact this isn't true and some voices in this discussion need to be more humble about what users
                      > >      >>         must or must not run.
                      > >      >>         > > > Does no one realize that it is a very possible outcome that if LOT=true is released there may be
                      > >     only a
                      > >      >>         handful of people that begin running it while everyone else delays their upgrade (with the very good
                      > >     reason of
                      > >      >>         not getting involved in politics) and a year later those handful of people just become stuck at the
                      > >     moment of
                      > >      >>         MUST_SIGNAL, unable to mine new blocks? Or attracting a minority of miners, activating, and forking off
                      > >     into a
                      > >      >>         minority fork. Then a lot=false could be started that ends up activating the feature now that the stubborn
                      > >      >>         option has ran its course.
                      > >      >>         > > > The result: a wasted year of waiting and a minority of people who didn't want to be lenient with
                      > >     miners
                      > >      >>         by default. The chains could be called BitcoinLenient and BitcoinStubborn.
                      > >      >>         > > > How is that strictly safer or more coordinated?
                      > >      >>         > > > I may be in the minority, or maybe a silent majority, or maybe a majority that just hasn't considered
                      > >      >>         this as a choice but honestly if there is contention about whether we're going to be stubborn or lenient
                      > >     with
                      > >      >>         miners for Taproot and in the future then I prefer to just not activate anything at all. I'm fine for
                      > >     calling
                      > >      >>         bitcoin ossified, accepting that segwit is Bitcoin's last network upgrade. Taproot is amazing but no new
                      > >      >>         feature is worth a network split down the middle.
                      > >      >>         > > > Maybe in 10 or 20 years, when other blockchains implement features like Taproot and many more, we will
                      > >      >>         become envious enough to put aside our differences on how to behave towards miners and finally activate
                      > >     Taproot.
                      > >      >>         > > > An activation mechanism is a consensus change like any other change, can be contentious like any other
                      > >      >>         change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
                      > >      >>         > > > Cheers
                      > >      >>         > > > Ariel Lorenzo-Luaces
                      > >      >>         > > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev
                      > >     <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
                      > >      >>         <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>> wrote:
                      > >      >>         > > >
                      > >      >>         > > > > Yesterday (February 16th) we held a second meeting on Taproot
                      > >      >>         > > > > activation on IRC which again was open to all. Despite what appeared
                      > >      >>         > > > > to be majority support for LOT=false over LOT=true in the first
                      > >      >>         > > > > meeting I (and others) thought the arguments had not been explored in
                      > >      >>         > > > > depth and that we should have a follow up meeting almost entirely
                      > >      >>         > > > > focused on whether LOT (lockinontimeout) should be set to true or
                      > >      >>         > > > > false.
                      > >      >>         > > > >
                      > >      >>         > > > > The meeting was announced here:
                      > >      >>         > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                      > >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>
                      > >      >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                      > >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>>
                      > >      >>         > > > >
                      > >      >>         > > > > In that mailing list post I outlined the arguments for LOT=true (T1 to
                      > >      >>         > > > > T6) and arguments for LOT=false (F1 to F6) in their strongest form I
                      > >      >>         > > > > could. David Harding responded with an additional argument for
                      > >      >>         > > > > LOT=false (F7) here:
                      > >      >>         > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
                      > >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html>
                      > >      >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
                      > >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html>>
                      > >      >>         > > > >
                      > >      >>         > > > > These meetings are very challenging given they are open to all, you
                      > >      >>         > > > > don’t know who will attend and you don’t know most people’s views in
                      > >      >>         > > > > advance. I tried to give time for both the LOT=true arguments and the
                      > >      >>         > > > > LOT=false arguments to be discussed as I knew there was support for
                      > >      >>         > > > > both. We only tried evaluating which had more support and which had
                      > >      >>         > > > > more strong opposition towards the end of the meeting.
                      > >      >>         > > > >
                      > >      >>         > > > > The conversation log is here:
                      > >      >>         > > > > http://gnusha.org/taproot-activation/2021-02-16.log
                      > >     <http://gnusha.org/taproot-activation/2021-02-16.log> <http://gnusha.org/taproot-activation/2021-02-16.log
                      > >     <http://gnusha.org/taproot-activation/2021-02-16.log>>
                      > >      >>         > > > >
                      > >      >>         > > > > (If you are so inclined you can watch a video of the meeting here.
                      > >      >>         > > > > Thanks to the YouTube account “Bitcoin” for setting up the livestream:
                      > >      >>         > > > > https://www.youtube.com/watch?v=vpl5q1ovMLM <https://www.youtube.com/watch?v=vpl5q1ovMLM>
                      > >     <https://www.youtube.com/watch?v=vpl5q1ovMLM <https://www.youtube.com/watch?v=vpl5q1ovMLM>>)
                      > >      >>         > > > >
                      > >      >>         > > > > A summary of the meeting was provided by Luke Dashjr on Mastodon here:
                      > >      >>         > > > > https://bitcoinhackers.org/@lukedashjr/105742918779234566
                      > >     <https://bitcoinhackers.org/@lukedashjr/105742918779234566>
                      > >      >>         <https://bitcoinhackers.org/@lukedashjr/105742918779234566
                      > >     <https://bitcoinhackers.org/@lukedashjr/105742918779234566>>
                      > >      >>         > > > >
                      > >      >>         > > > > Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we
                      > >      >>         > > > > did manage to come to consensus on everything but LockinOnTimeout.
                      > >      >>         > > > >
                      > >      >>         > > > > Activation height range: 693504-745920
                      > >      >>         > > > >
                      > >      >>         > > > > MASF threshold: 1815/2016 blocks (90%)
                      > >      >>         > > > >
                      > >      >>         > > > > Keep in mind only ~100 people showed for the meetings, hardly
                      > >      >>         > > > > representative of the entire community.
                      > >      >>         > > > >
                      > >      >>         > > > > So, these details remain JUST a proposal for now.
                      > >      >>         > > > >
                      > >      >>         > > > > It seems inevitable that there won't be consensus on LOT.
                      > >      >>         > > > >
                      > >      >>         > > > > Everyone will have to choose for himself. :/
                      > >      >>         > > > >
                      > >      >>         > > > > Personally I agree with most of this. I agree that there wasn’t
                      > >      >>         > > > > overwhelming consensus for either LOT=true or LOT=false. However, from
                      > >      >>         > > > > my perspective there was clearly more strong opposition (what would
                      > >      >>         > > > > usually be deemed a NACK in Bitcoin Core review terminology) from
                      > >      >>         > > > > Bitcoin Core contributors, Lightning developers and other community
                      > >      >>         > > > > members against LOT=true than there was for LOT=false. Andrew Chow
                      > >      >>         > > > > tried to summarize views from the meeting in this analysis:
                      > >      >>         > > > > https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
                      > >     <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>
                      > >      >>         <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
                      > >     <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>>
                      > >      >>         > > > >
                      > >      >>         > > > > I am also aware of other current and previous Bitcoin Core
                      > >      >>         > > > > contributors and Lightning developers who didn’t attend the meeting in
                      > >      >>         > > > > person who are opposed to LOT=true. I don’t want to put them in the
                      > >      >>         > > > > spotlight for no reason but if you go through the conversation logs of
                      > >      >>         > > > > not only the meeting but the weeks of discussion prior to this meeting
                      > >      >>         > > > > you will see their views evaluated on the ##taproot-activation
                      > >      >>         > > > > channel. In addition, on taprootactivation.com <http://taprootactivation.com>
                      > >     <http://taprootactivation.com <http://taprootactivation.com>> some mining pools
                      > >      >>         > > > > expressed a preference for lot=false though I don’t know how strong
                      > >      >>         > > > > that preference was.
                      > >      >>         > > > >
                      > >      >>         > > > > I am only one voice but it is my current assessment that if we are to
                      > >      >>         > > > > attempt to finalize Taproot activation parameters and propose them to
                      > >      >>         > > > > the community at this time our only option is to propose LOT=false.
                      > >      >>         > > > > Any further delay appears to me counterproductive in our collective
                      > >      >>         > > > > aim to get the Taproot soft fork activated as early as possible.
                      > >      >>         > > > >
                      > >      >>         > > > > Obviously others are free to disagree with that assessment and
                      > >      >>         > > > > continue discussions but personally I will be attempting to avoid
                      > >      >>         > > > > those discussions unless prominent new information comes to light or
                      > >      >>         > > > > various specific individuals change their minds.
                      > >      >>         > > > >
                      > >      >>         > > > > Next week we are planning a code review of the Bitcoin Core PR #19573
                      > >      >>         > > > > which was initially delayed because of this LOT discussion. As I’ve
                      > >      >>         > > > > said previously that will be loosely following the format of the
                      > >      >>         > > > > Bitcoin Core PR review club and will be lower level and more
                      > >      >>         > > > > technical. That is planned for Tuesday February 23rd at 19:00 UTC on
                      > >      >>         > > > > the IRC channel ##taproot-activation.
                      > >      >>         > > > >
                      > >      >>         > > > > Thanks to the meeting participants (and those who joined the
                      > >      >>         > > > > discussion on the channel prior and post the meeting) for engaging
                      > >      >>         > > > > productively and in good faith.
                      > >      >>         > >
                      > >      >>         > > --
                      > >      >>         > > Michael Folkson
                      > >      >>         > > Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com> <mailto:michaelfolkson@gmail•com
                      > >     <mailto:michaelfolkson@gmail•com>>
                      > >      >>         > > Keybase: michaelfolkson
                      > >      >>         > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                      > >      >>         > > _______________________________________________
                      > >      >>         > > bitcoin-dev mailing list
                      > >      >>         > > bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
                      > >     <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>
                      > >      >>         > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                      > >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
                      > >      >>         <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                      > >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>>
                      > >      >>
                      > >      >>
                      > >      >>
                      > >      >>
                      > >      >>     --
                      > >      >>     Michael Folkson
                      > >      >>     Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com> <mailto:michaelfolkson@gmail•com
                      > >     <mailto:michaelfolkson@gmail•com>>
                      > >      >>     Keybase: michaelfolkson
                      > >      >>     PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                      > >      >>     _______________________________________________
                      > >      >>     bitcoin-dev mailing list
                      > >      >> bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
                      > >     <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>
                      > >      >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                      > >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
                      > >      >>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                      > >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>>
                      > >      >
                      > >      >
                      > >      >
                      > >      > --
                      > >      > Michael Folkson
                      > >      > Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com> <mailto:michaelfolkson@gmail•com
                      > >     <mailto:michaelfolkson@gmail•com>>
                      > >      > Keybase: michaelfolkson
                      > >      > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                      > >     _______________________________________________
                      > >     bitcoin-dev mailing list
                      > >     bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
                      > >     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                      > >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
                      > >
                      >
                      > bitcoin-dev mailing list
                      > bitcoin-dev@lists•linuxfoundation.org
                      > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                      
                      
                      
                      
                      
                      ^ permalink raw reply	[flat|nested] 42+ messages in thread

                    • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                          2021-02-19 11:30                     ` ZmnSCPxj
                        @ 2021-02-19 12:05                       ` Adam Back
                          2021-02-19 14:13                         ` Matt Corallo
                          0 siblings, 1 reply; 42+ messages in thread
                        From: Adam Back @ 2021-02-19 12:05 UTC (permalink / raw)
                          To: ZmnSCPxj, Bitcoin Protocol Discussion; +Cc: Michael Folkson
                        
                        Personally I don't really have much of a view and think either
                        LOT=true or false is better in the context, they both seem safe given
                        the current context, where basically everyone is saying "are we there
                        yet", including pools (88.7% going out of their way to say YES
                        https://taprootactivation.com).  Not that pools are deciding of
                        anything, being service providers to miners, who can and will switch
                        pool fast, and miners in-turn being service providers to the market
                        and as the various forks showed will follow the market.
                        
                        I think it's a very good idea for safety, if there is a tested and
                        reviewed code with an option to force LOT=true, even if the
                        bitcoin-core implementation ends up defaulting to LOT=false.
                        
                        Part of the danger is rushed versions of things like BIP 91 to avoid a
                        chain split where miners left brinkmanship just a bit too late, to
                        avert BIP 148 forking, and BIP 91 was used to expedite activation to
                        avoid that. The rushed proposal, code, review, ship cycle on that was
                        dangerously fast - less time and eyes for review was the danger.
                        
                        > would dev consensus around releasing LOT=false be considered as "developers forcing their views on users"?
                        
                        given there are clearly people of both views, or for now don't care
                        but might later, it would minimally be friendly and useful if
                        bitcoin-core has a LOT=true option - and that IMO goes some way to
                        avoid the assumptive control via defaults.
                        
                        Otherwise it could be read as saying "developers on average
                        disapprove, but if you, the market disagree, go figure it out for
                        yourself" which is not a good message for being defensive and avoiding
                        mis-interpretation of code repositories or shipped defaults as
                        "control".
                        
                        Adam
                        
                        On Fri, 19 Feb 2021 at 11:30, ZmnSCPxj via bitcoin-dev
                        <bitcoin-dev@lists•linuxfoundation.org> wrote:
                        >
                        > Good morning list,
                        >
                        > > This is absolutely the case, however note that the activation method itself is consensus code which executes as a part
                        > > of a fork, and one which deserves as much scrutiny as anything else. While taproot is a model of how a soft-fork should
                        > > be designed, this doesn't imply anything about the consensus code which represents the activation thereof.
                        > >
                        > > Hence all the debate around activation - ultimately its also defining a fork, and given the politics around it, one
                        > > which almost certainly carries significantly more risk than Taproot.
                        > >
                        > > Note that I don't believe anyone is advocating for "try to activate, and if it fails, move on". Various people have
                        > > various views on how conservative and timelines for what to do at that point, but I believe most in this discussion are
                        > > OK with flag-day-based activation (given some level of care) if it becomes clear Taproot is supported by a vast majority
                        > > of Bitcoin users and is only not activating due to lagging miner upgrades.
                        >
                        >
                        > Okay, I am backing off this proposal to force the LOT=false/true decision on users, it was not particularly serious anyway (and was more a reaction to the request of Samson Mow to just release both versions, which to my mind is no different from such a thing).
                        >
                        >
                        > Nonetheless, as a thought experiment: the main issue is that some number of people run LOT=true when miners do not activate Taproot early for some reason and we decide to leave LOT=false for this particular bit until it times out.
                        > The issue is that those people will get forked off the network at the end of this particular deployment attempt.
                        >
                        > I suspect those people will still exist whether or not Bitcoin Core supports any kind of LOT=true mode.
                        > ("Never again" for some people)
                        >
                        > How do we convince them to go run LOT=false instead of getting themselves forked off?
                        > Or do we simply let them?
                        >
                        > (and how is that different from asking each user to decide on LOT=false/true right now?)
                        > ("reasonable default"?)
                        > (fundamentally speaking you still have to educate the users on the ramifications of accepting the default and changing it.)
                        >
                        >
                        > Another thought experiment: From the point of view of a user who strongly supports LOT=true, would dev consensus around releasing LOT=false be considered as "developers forcing their views on users"?
                        > Why or why not?
                        >
                        >
                        > Regards,
                        > ZmnSCPxj
                        >
                        > > Matt
                        > >
                        > > On 2/18/21 10:04, Keagan McClelland wrote:
                        > >
                        > > > Hi all,
                        > > > I think it's important for us to consider what is actually being considered for activation here.
                        > > > The designation of "soft fork" is accurate but I don't think it adequately conveys how non-intrusive a change like this
                        > > > is. All that taproot does (unless I'm completely missing something) is imbue a previously undefined script version with
                        > > > actual semantics. In order for a chain reorg to take place it would mean that someone would have to have a use case for
                        > > > that script version today. This is something I think that we can easily check by digging through the UTXO set or
                        > > > history. If anyone is using that script version, we absolutely should not be using it, but that doesn't mean that we
                        > > > can't switch to a script version that no one is actually using.
                        > > > If no one is even attempting to use the script version, then the change has no effect on whether a chain split occurs
                        > > > because there is simply no block that contains a transaction that only some of the network will accept.
                        > > > Furthermore, I don't know how Bitcoin can stand the test of time if we allow developers who rely on "undefined behavior"
                        > > > (which the taproot script version presently is) to exert tremendous influence over what code does or does not get run.
                        > > > This isn't a soft fork that makes some particular UTXO's unspendable. It isn't one that bans miners from collecting
                        > > > fees. It is a change that means that certain "always accept" transactions actually have real conditions you have to
                        > > > meet. I can't imagine a less intrusive change.
                        > > > On the other hand, choosing to let L=F be a somewhat final call sets a very real precedent that 10% of what I estimate
                        > > > to be 1% of bitcoin users can effectively block any change from here on forward. At that point we are saying that miners
                        > > > are in control of network consensus in ways they have not been up until now. I don't think this is a more desirable
                        > > > outcome to let ~0.1% of the network get to block /non-intrusive/ changes that the rest of the network wants.
                        > > > I can certainly live with an L=F attempt as a way to punt on the discussion, maybe the activation happens and this will
                        > > > all be fine. But if it doesn't, I hardly think that users of Bitcoin are just going to be like "well, guess that's it
                        > > > for Taproot". I have no idea what ensues at that point, but probably another community led UASF movement.
                        > > > I wasn't super well educated on this stuff back in '17 when Segwit went down, as I was new at that time, so if I'm
                        > > > missing something please say so. But from my point of view, we can't treat all soft forks as equal.
                        > > > Keagan
                        > > > On Thu, Feb 18, 2021 at 7:43 AM Matt Corallo via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org
                        > > > mailto:bitcoin-dev@lists•linuxfoundation.org> wrote:
                        > > >
                        > > >     We've had several softforks in Bitcoin which, through the course of their activation, had a several-block reorg. That
                        > > >     should be indication enough that we need to very carefully consider activation to ensure we reduce the risk of that as
                        > > >     much as absolutely possible. Again, while I think Taproot is a huge improvement and am looking forward to being able to
                        > > >     use it, getting unlucky and hitting a 4-block reorg that happens to include a double-spend and some PR around an
                        > > >     exchange losing millions would be worse than having Taproot is good.
                        > > >
                        > > >     Matt
                        > > >
                        > > >     On 2/18/21 09:26, Michael Folkson wrote:
                        > > >      > Thanks for your response Matt. It is a fair challenge. There is always going to be an element of risk with soft
                        > > >     forks,
                        > > >      > all we can do is attempt to minimize that risk. I would argue that risk has been minimized for Taproot.
                        > > >      >
                        > > >      > You know (better than I do in fact) that Bitcoin (and layers built on top of it) greatly benefit from upgrades
                        > > >     such as
                        > > >      > Taproot. To say we shouldn't do Taproot or any future soft forks because there is a small but real risk of chain
                        > > >     splits
                        > > >      > I think is shortsighted. Indeed I think even if we collectively decided not to do any future soft fork upgrades ever
                        > > >      > again on this mailing list that wouldn't stop soft fork attempts from other people in future.
                        > > >      >
                        > > >      > I don't think there is anything else we can do to minimize that risk for the Taproot soft fork at this point
                        > > >     though I'm
                        > > >      > open to ideas. To reiterate that risk will never be zero. I don't think I see Bitcoin as fragile as you seem to
                        > > >     (though
                        > > >      > admittedly you have a much better understanding than me of what happened in 2017).
                        > > >      >
                        > > >      > The likely scenario for the Taproot soft fork is LOT turns out to be entirely irrelevant and miners activate Taproot
                        > > >      > before it becomes relevant. And even the unlikely worst case scenario would only cause short term disruption and
                        > > >      > wouldn't kill Bitcoin long term.
                        > > >      >
                        > > >      > On Thu, Feb 18, 2021 at 2:01 PM Matt Corallo <lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo•com>
                        > > >     <mailto:lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo•com>>> wrote:
                        > > >      >
                        > > >      >     If the eventual outcome is that different implementations (that have material *transaction processing* userbases,
                        > > >      >     and I’m not sure to what extent that’s true with Knots) ship different consensus rules, we should stop here
                        > > >     and not
                        > > >      >     activate Taproot. Seriously.
                        > > >      >
                        > > >      >     Bitcoin is a consensus system. The absolute worst outcome at all possible is to have it fall out of consensus.
                        > > >      >
                        > > >      >     Matt
                        > > >      >
                        > > >      >>     On Feb 18, 2021, at 08:11, Michael Folkson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org
                        > > >     <mailto:bitcoin-dev@lists•linuxfoundation.org>
                        > > >      >>     <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>> wrote:
                        > > >      >>
                        > > >      >>     
                        > > >      >>     Right, that is one option. Personally I would prefer a Bitcoin Core release sets LOT=false (based on what I have
                        > > >      >>     heard from Bitcoin Core contributors) and a community effort releases a version with LOT=true. I don't think
                        > > >     users
                        > > >      >>     should be forced to choose something they may have no context on before they are allowed to use Bitcoin Core.
                        > > >      >>
                        > > >      >>     My current understanding is that roasbeef is planning to set LOT=false on btcd (an alternative protocol
                        > > >      >>     implementation to Bitcoin Core) and Luke Dashjr hasn't yet decided on Bitcoin Knots.
                        > > >      >>
                        > > >      >>
                        > > >      >>
                        > > >      >>     On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <ZmnSCPxj@protonmail•com <mailto:ZmnSCPxj@protonmail•com>
                        > > >     <mailto:ZmnSCPxj@protonmail•com <mailto:ZmnSCPxj@protonmail•com>>> wrote:
                        > > >      >>
                        > > >      >>         Good morning all,
                        > > >      >>
                        > > >      >>         > "An activation mechanism is a consensus change like any other change, can be contentious like any other
                        > > >      >>         change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline."
                        > > >      >>         >
                        > > >      >>         > Who's we here?
                        > > >      >>         >
                        > > >      >>         > Release both and let the network decide.
                        > > >      >>
                        > > >      >>         A thing that could be done, without mandating either LOT=true or LOT=false, would be to have a release that
                        > > >      >>         requires a `taprootlot=1` or `taprootlot=0` and refuses to start if the parameter is not set.
                        > > >      >>
                        > > >      >>         This assures everyone that neither choice is being forced on users, and instead what is being forced on
                        > > >     users,
                        > > >      >>         is for users to make that choice themselves.
                        > > >      >>
                        > > >      >>         Regards,
                        > > >      >>         ZmnSCPxj
                        > > >      >>
                        > > >      >>         >
                        > > >      >>         > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org
                        > > >     <mailto:bitcoin-dev@lists•linuxfoundation.org>
                        > > >      >>         <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>> wrote:
                        > > >      >>         >
                        > > >      >>         > > Thanks for your response Ariel. It would be useful if you responded to specific points I have made
                        > > >     in the
                        > > >      >>         mailing list post or at least quote these ephemeral "people" you speak of. I don't know if you're responding
                        > > >      >>         to conversation on the IRC channel or on social media etc.
                        > > >      >>         > >
                        > > >      >>         > > > The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted
                        > > >     into
                        > > >      >>         code. But in fact this isn't true and some voices in this discussion need to be more humble about what users
                        > > >      >>         must or must not run.
                        > > >      >>         > >
                        > > >      >>         > > I personally have never made this assumption. Of course users aren't forced to run any particular
                        > > >     software
                        > > >      >>         version, quite the opposite. Defaults set in software versions matter though as many users won't change
                        > > >     them.
                        > > >      >>         > >
                        > > >      >>         > > > Does no one realize that it is a very possible outcome that if LOT=true is released there may be
                        > > >     only a
                        > > >      >>         handful of people that begin running it while everyone else delays their upgrade (with the very good
                        > > >     reason of
                        > > >      >>         not getting involved in politics) and a year later those handful of people just become stuck at the
                        > > >     moment of
                        > > >      >>         MUST_SIGNAL, unable to mine new blocks?
                        > > >      >>         > >
                        > > >      >>         > > It is a possible outcome but the likely outcome is that miners activate Taproot before LOT is even
                        > > >      >>         relevant. I think it is prudent to prepare for the unlikely but possible outcome that miners fail to
                        > > >     activate
                        > > >      >>         and hence have this discussion now rather than be unprepared for that eventuality. If LOT is set to
                        > > >     false in a
                        > > >      >>         software release there is the possibility (T2 in
                        > > >      >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                        > > >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>
                        > > >      >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                        > > >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>>) of individuals or a
                        > > >      >>         proportion of the community changing LOT to true. In that sense setting LOT=false in a software release
                        > > >      >>         appears to be no more safe than LOT=true.
                        > > >      >>         > >
                        > > >      >>         > > > The result: a wasted year of waiting and a minority of people who didn't want to be lenient with
                        > > >     miners
                        > > >      >>         by default.
                        > > >      >>         > >
                        > > >      >>         > > There is the (unlikely but possible) possibility of a wasted year if LOT is set to false and miners fail
                        > > >      >>         to activate. I'm not convinced by this perception that LOT=true is antagonistic to miners. I actually
                        > > >     think it
                        > > >      >>         offers them clarity on what will happen over a year time period and removes the need for coordinated or
                        > > >      >>         uncoordinated community UASF efforts on top of LOT=false.
                        > > >      >>         > >
                        > > >      >>         > > > An activation mechanism is a consensus change like any other change, can be contentious like any other
                        > > >      >>         change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
                        > > >      >>         > >
                        > > >      >>         > > I don't know what you are recommending here to avoid "this darkest timeline". Open discussions have
                        > > >      >>         occurred and are continuing and in my mailing list post that you responded to **I recommended we propose
                        > > >      >>         LOT=false be set in protocol implementations such as Bitcoin Core**. I do think this apocalyptic language
                        > > >      >>         isn't particularly helpful. In an open consensus system discussion is healthy, we should prepare for bad or
                        > > >      >>         worst case scenarios in advance and doing so is not antagonistic or destructive. Mining pools have pledged
                        > > >      >>         support for Taproot but we don't build secure systems based on pledges of support, we build them to minimize
                        > > >      >>         trust in any human actors. We can be grateful that people like Alejandro have worked hard on
                        > > >      >> taprootactivation.com <http://taprootactivation.com> <http://taprootactivation.com
                        > > >     <http://taprootactivation.com>> (and this effort has informed the discussion) without
                        > > >      >>         taking pledges of support as cast iron guarantees.
                        > > >      >>         > >
                        > > >      >>         > > TL;DR It sounds like you agree with my recommendation to set LOT=false in protocol implementations in my
                        > > >      >>         email :)
                        > > >      >>         > >
                        > > >      >>         > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <arielluaces@gmail•com
                        > > >     <mailto:arielluaces@gmail•com>
                        > > >      >>         <mailto:arielluaces@gmail•com <mailto:arielluaces@gmail•com>>> wrote:
                        > > >      >>         > >
                        > > >      >>         > > > Something what strikes me about the conversation is the emotion surrounding the letters UASF.
                        > > >      >>         > > > It appears as if people discuss UASF as if it's a massive tidal wave of support that is
                        > > >     inevitable, like
                        > > >      >>         we saw during segwit activation. But the actual definition is "any activation that is not a MASF".
                        > > >      >>         > > > A UASF can consist of a single node, ten nodes, a thousand, half of all nodes, all business' nodes, or
                        > > >      >>         even all the non mining nodes. On another dimension it can have zero mining support, 51% support, 49%
                        > > >     support,
                        > > >      >>         or any support right up against a miner activation threshold.
                        > > >      >>         > > > Hell a UASF doesn't even need code or even a single node running as long as it exists as a possibility
                        > > >      >>         in people's minds.
                        > > >      >>         > > > The only thing a UASF doesn't have is miner support above an agreed activation threshold (some number
                        > > >      >>         above %51).
                        > > >      >>         > > > I say this because it strikes me when people say that they are for LOT=true with the logic that
                        > > >     since a
                        > > >      >>         UASF is guaranteed to happen then it's better to just make it default from the beginning. Words like
                        > > >      >>         coordination and safety are sometimes sprinkled into the argument.
                        > > >      >>         > > > The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted
                        > > >     into
                        > > >      >>         code. But in fact this isn't true and some voices in this discussion need to be more humble about what users
                        > > >      >>         must or must not run.
                        > > >      >>         > > > Does no one realize that it is a very possible outcome that if LOT=true is released there may be
                        > > >     only a
                        > > >      >>         handful of people that begin running it while everyone else delays their upgrade (with the very good
                        > > >     reason of
                        > > >      >>         not getting involved in politics) and a year later those handful of people just become stuck at the
                        > > >     moment of
                        > > >      >>         MUST_SIGNAL, unable to mine new blocks? Or attracting a minority of miners, activating, and forking off
                        > > >     into a
                        > > >      >>         minority fork. Then a lot=false could be started that ends up activating the feature now that the stubborn
                        > > >      >>         option has ran its course.
                        > > >      >>         > > > The result: a wasted year of waiting and a minority of people who didn't want to be lenient with
                        > > >     miners
                        > > >      >>         by default. The chains could be called BitcoinLenient and BitcoinStubborn.
                        > > >      >>         > > > How is that strictly safer or more coordinated?
                        > > >      >>         > > > I may be in the minority, or maybe a silent majority, or maybe a majority that just hasn't considered
                        > > >      >>         this as a choice but honestly if there is contention about whether we're going to be stubborn or lenient
                        > > >     with
                        > > >      >>         miners for Taproot and in the future then I prefer to just not activate anything at all. I'm fine for
                        > > >     calling
                        > > >      >>         bitcoin ossified, accepting that segwit is Bitcoin's last network upgrade. Taproot is amazing but no new
                        > > >      >>         feature is worth a network split down the middle.
                        > > >      >>         > > > Maybe in 10 or 20 years, when other blockchains implement features like Taproot and many more, we will
                        > > >      >>         become envious enough to put aside our differences on how to behave towards miners and finally activate
                        > > >     Taproot.
                        > > >      >>         > > > An activation mechanism is a consensus change like any other change, can be contentious like any other
                        > > >      >>         change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
                        > > >      >>         > > > Cheers
                        > > >      >>         > > > Ariel Lorenzo-Luaces
                        > > >      >>         > > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev
                        > > >     <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
                        > > >      >>         <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>> wrote:
                        > > >      >>         > > >
                        > > >      >>         > > > > Yesterday (February 16th) we held a second meeting on Taproot
                        > > >      >>         > > > > activation on IRC which again was open to all. Despite what appeared
                        > > >      >>         > > > > to be majority support for LOT=false over LOT=true in the first
                        > > >      >>         > > > > meeting I (and others) thought the arguments had not been explored in
                        > > >      >>         > > > > depth and that we should have a follow up meeting almost entirely
                        > > >      >>         > > > > focused on whether LOT (lockinontimeout) should be set to true or
                        > > >      >>         > > > > false.
                        > > >      >>         > > > >
                        > > >      >>         > > > > The meeting was announced here:
                        > > >      >>         > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                        > > >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>
                        > > >      >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
                        > > >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>>
                        > > >      >>         > > > >
                        > > >      >>         > > > > In that mailing list post I outlined the arguments for LOT=true (T1 to
                        > > >      >>         > > > > T6) and arguments for LOT=false (F1 to F6) in their strongest form I
                        > > >      >>         > > > > could. David Harding responded with an additional argument for
                        > > >      >>         > > > > LOT=false (F7) here:
                        > > >      >>         > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
                        > > >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html>
                        > > >      >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
                        > > >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html>>
                        > > >      >>         > > > >
                        > > >      >>         > > > > These meetings are very challenging given they are open to all, you
                        > > >      >>         > > > > don’t know who will attend and you don’t know most people’s views in
                        > > >      >>         > > > > advance. I tried to give time for both the LOT=true arguments and the
                        > > >      >>         > > > > LOT=false arguments to be discussed as I knew there was support for
                        > > >      >>         > > > > both. We only tried evaluating which had more support and which had
                        > > >      >>         > > > > more strong opposition towards the end of the meeting.
                        > > >      >>         > > > >
                        > > >      >>         > > > > The conversation log is here:
                        > > >      >>         > > > > http://gnusha.org/taproot-activation/2021-02-16.log
                        > > >     <http://gnusha.org/taproot-activation/2021-02-16.log> <http://gnusha.org/taproot-activation/2021-02-16.log
                        > > >     <http://gnusha.org/taproot-activation/2021-02-16.log>>
                        > > >      >>         > > > >
                        > > >      >>         > > > > (If you are so inclined you can watch a video of the meeting here.
                        > > >      >>         > > > > Thanks to the YouTube account “Bitcoin” for setting up the livestream:
                        > > >      >>         > > > > https://www.youtube.com/watch?v=vpl5q1ovMLM <https://www.youtube.com/watch?v=vpl5q1ovMLM>
                        > > >     <https://www.youtube.com/watch?v=vpl5q1ovMLM <https://www.youtube.com/watch?v=vpl5q1ovMLM>>)
                        > > >      >>         > > > >
                        > > >      >>         > > > > A summary of the meeting was provided by Luke Dashjr on Mastodon here:
                        > > >      >>         > > > > https://bitcoinhackers.org/@lukedashjr/105742918779234566
                        > > >     <https://bitcoinhackers.org/@lukedashjr/105742918779234566>
                        > > >      >>         <https://bitcoinhackers.org/@lukedashjr/105742918779234566
                        > > >     <https://bitcoinhackers.org/@lukedashjr/105742918779234566>>
                        > > >      >>         > > > >
                        > > >      >>         > > > > Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we
                        > > >      >>         > > > > did manage to come to consensus on everything but LockinOnTimeout.
                        > > >      >>         > > > >
                        > > >      >>         > > > > Activation height range: 693504-745920
                        > > >      >>         > > > >
                        > > >      >>         > > > > MASF threshold: 1815/2016 blocks (90%)
                        > > >      >>         > > > >
                        > > >      >>         > > > > Keep in mind only ~100 people showed for the meetings, hardly
                        > > >      >>         > > > > representative of the entire community.
                        > > >      >>         > > > >
                        > > >      >>         > > > > So, these details remain JUST a proposal for now.
                        > > >      >>         > > > >
                        > > >      >>         > > > > It seems inevitable that there won't be consensus on LOT.
                        > > >      >>         > > > >
                        > > >      >>         > > > > Everyone will have to choose for himself. :/
                        > > >      >>         > > > >
                        > > >      >>         > > > > Personally I agree with most of this. I agree that there wasn’t
                        > > >      >>         > > > > overwhelming consensus for either LOT=true or LOT=false. However, from
                        > > >      >>         > > > > my perspective there was clearly more strong opposition (what would
                        > > >      >>         > > > > usually be deemed a NACK in Bitcoin Core review terminology) from
                        > > >      >>         > > > > Bitcoin Core contributors, Lightning developers and other community
                        > > >      >>         > > > > members against LOT=true than there was for LOT=false. Andrew Chow
                        > > >      >>         > > > > tried to summarize views from the meeting in this analysis:
                        > > >      >>         > > > > https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
                        > > >     <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>
                        > > >      >>         <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
                        > > >     <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>>
                        > > >      >>         > > > >
                        > > >      >>         > > > > I am also aware of other current and previous Bitcoin Core
                        > > >      >>         > > > > contributors and Lightning developers who didn’t attend the meeting in
                        > > >      >>         > > > > person who are opposed to LOT=true. I don’t want to put them in the
                        > > >      >>         > > > > spotlight for no reason but if you go through the conversation logs of
                        > > >      >>         > > > > not only the meeting but the weeks of discussion prior to this meeting
                        > > >      >>         > > > > you will see their views evaluated on the ##taproot-activation
                        > > >      >>         > > > > channel. In addition, on taprootactivation.com <http://taprootactivation.com>
                        > > >     <http://taprootactivation.com <http://taprootactivation.com>> some mining pools
                        > > >      >>         > > > > expressed a preference for lot=false though I don’t know how strong
                        > > >      >>         > > > > that preference was.
                        > > >      >>         > > > >
                        > > >      >>         > > > > I am only one voice but it is my current assessment that if we are to
                        > > >      >>         > > > > attempt to finalize Taproot activation parameters and propose them to
                        > > >      >>         > > > > the community at this time our only option is to propose LOT=false.
                        > > >      >>         > > > > Any further delay appears to me counterproductive in our collective
                        > > >      >>         > > > > aim to get the Taproot soft fork activated as early as possible.
                        > > >      >>         > > > >
                        > > >      >>         > > > > Obviously others are free to disagree with that assessment and
                        > > >      >>         > > > > continue discussions but personally I will be attempting to avoid
                        > > >      >>         > > > > those discussions unless prominent new information comes to light or
                        > > >      >>         > > > > various specific individuals change their minds.
                        > > >      >>         > > > >
                        > > >      >>         > > > > Next week we are planning a code review of the Bitcoin Core PR #19573
                        > > >      >>         > > > > which was initially delayed because of this LOT discussion. As I’ve
                        > > >      >>         > > > > said previously that will be loosely following the format of the
                        > > >      >>         > > > > Bitcoin Core PR review club and will be lower level and more
                        > > >      >>         > > > > technical. That is planned for Tuesday February 23rd at 19:00 UTC on
                        > > >      >>         > > > > the IRC channel ##taproot-activation.
                        > > >      >>         > > > >
                        > > >      >>         > > > > Thanks to the meeting participants (and those who joined the
                        > > >      >>         > > > > discussion on the channel prior and post the meeting) for engaging
                        > > >      >>         > > > > productively and in good faith.
                        > > >      >>         > >
                        > > >      >>         > > --
                        > > >      >>         > > Michael Folkson
                        > > >      >>         > > Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com> <mailto:michaelfolkson@gmail•com
                        > > >     <mailto:michaelfolkson@gmail•com>>
                        > > >      >>         > > Keybase: michaelfolkson
                        > > >      >>         > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                        > > >      >>         > > _______________________________________________
                        > > >      >>         > > bitcoin-dev mailing list
                        > > >      >>         > > bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
                        > > >     <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>
                        > > >      >>         > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                        > > >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
                        > > >      >>         <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                        > > >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>>
                        > > >      >>
                        > > >      >>
                        > > >      >>
                        > > >      >>
                        > > >      >>     --
                        > > >      >>     Michael Folkson
                        > > >      >>     Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com> <mailto:michaelfolkson@gmail•com
                        > > >     <mailto:michaelfolkson@gmail•com>>
                        > > >      >>     Keybase: michaelfolkson
                        > > >      >>     PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                        > > >      >>     _______________________________________________
                        > > >      >>     bitcoin-dev mailing list
                        > > >      >> bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
                        > > >     <mailto:bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>
                        > > >      >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                        > > >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
                        > > >      >>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                        > > >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>>
                        > > >      >
                        > > >      >
                        > > >      >
                        > > >      > --
                        > > >      > Michael Folkson
                        > > >      > Email: michaelfolkson@gmail•com <mailto:michaelfolkson@gmail•com> <mailto:michaelfolkson@gmail•com
                        > > >     <mailto:michaelfolkson@gmail•com>>
                        > > >      > Keybase: michaelfolkson
                        > > >      > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
                        > > >     _______________________________________________
                        > > >     bitcoin-dev mailing list
                        > > >     bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
                        > > >     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                        > > >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
                        > > >
                        > >
                        > > bitcoin-dev mailing list
                        > > bitcoin-dev@lists•linuxfoundation.org
                        > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                        >
                        >
                        >
                        > _______________________________________________
                        > bitcoin-dev mailing list
                        > bitcoin-dev@lists•linuxfoundation.org
                        > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                        
                        
                        ^ permalink raw reply	[flat|nested] 42+ messages in thread

                      • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                            2021-02-19 12:05                       ` Adam Back
                          @ 2021-02-19 14:13                         ` Matt Corallo
                            2021-02-19 17:48                           ` Matt Corallo
                            0 siblings, 1 reply; 42+ messages in thread
                          From: Matt Corallo @ 2021-02-19 14:13 UTC (permalink / raw)
                            To: Adam Back; +Cc: Michael Folkson, Bitcoin Protocol Discussion
                          
                          (Also in response to ZMN...)
                          
                          Bitcoin Core has a long-standing policy of not shipping options which shoot yourself in the foot. I’d be very disappointed if that changed now. People are of course more than welcome to run such software themselves, but I anticipate the loud minority on Twitter and here aren’t processing enough transactions or throwing enough financial weight behind their decision for them to do anything but just switch back if they find themselves on a chain with no blocks.
                          
                          There’s nothing we can (or should) do to prevent people from threatening to (and possibly) forking themselves off of bitcoin, but that doesn’t mean we should encourage it either. The work Bitcoin Core maintainers and developers do is to recommend courses of action which they believe have reasonable levels of consensus and are technically sound. Luckily, there’s strong historical precedent for people deciding to run other software around forks, so misinterpretation is not very common (just like there’s strong historical precedent for miners not unilaterally deciding forks in the case of Segwit).
                          
                          Matt
                          
                          > On Feb 19, 2021, at 07:08, Adam Back <adam@cypherspace•org> wrote:
                          >> would dev consensus around releasing LOT=false be considered as "developers forcing their views on users"?
                          > 
                          > given there are clearly people of both views, or for now don't care
                          > but might later, it would minimally be friendly and useful if
                          > bitcoin-core has a LOT=true option - and that IMO goes some way to
                          > avoid the assumptive control via defaults.
                          
                          > Otherwise it could be read as saying "developers on average
                          > disapprove, but if you, the market disagree, go figure it out for
                          > yourself" which is not a good message for being defensive and avoiding
                          > mis-interpretation of code repositories or shipped defaults as
                          > "control".
                          
                          
                          
                          
                          ^ permalink raw reply	[flat|nested] 42+ messages in thread

                        • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                              2021-02-19 14:13                         ` Matt Corallo
                            @ 2021-02-19 17:48                           ` Matt Corallo
                              2021-02-20  2:55                             ` ZmnSCPxj
                              2021-02-22  5:16                             ` Anthony Towns
                              0 siblings, 2 replies; 42+ messages in thread
                            From: Matt Corallo @ 2021-02-19 17:48 UTC (permalink / raw)
                              To: Bitcoin Protocol Discussion, Adam Back, ZmnSCPxj; +Cc: Michael Folkson
                            
                            It was pointed out to me that this discussion is largely moot as the software complexity for Bitcoin Core to ship an 
                            option like this is likely not practical/what people would wish to see.
                            
                            Bitcoin Core does not have infrastructure to handle switching consensus rules with the same datadir - after running with 
                            uasf=true for some time, valid blocks will be marked as invalid, and additional development would need to occur to 
                            enable switching back to uasf=false. This is complex, critical code to get right, and the review and testing cycles 
                            needed seem to be not worth it.
                            
                            Instead, the only practical way to ship such an option would be to treat it as a separate chain (the same way regtest, 
                            testnet, and signet are treated), including its own separate datadir and the like.
                            
                            Matt
                            
                            On 2/19/21 09:13, Matt Corallo via bitcoin-dev wrote:
                            > (Also in response to ZMN...)
                            > 
                            > Bitcoin Core has a long-standing policy of not shipping options which shoot yourself in the foot. I’d be very disappointed if that changed now. People are of course more than welcome to run such software themselves, but I anticipate the loud minority on Twitter and here aren’t processing enough transactions or throwing enough financial weight behind their decision for them to do anything but just switch back if they find themselves on a chain with no blocks.
                            > 
                            > There’s nothing we can (or should) do to prevent people from threatening to (and possibly) forking themselves off of bitcoin, but that doesn’t mean we should encourage it either. The work Bitcoin Core maintainers and developers do is to recommend courses of action which they believe have reasonable levels of consensus and are technically sound. Luckily, there’s strong historical precedent for people deciding to run other software around forks, so misinterpretation is not very common (just like there’s strong historical precedent for miners not unilaterally deciding forks in the case of Segwit).
                            > 
                            > Matt
                            > 
                            >> On Feb 19, 2021, at 07:08, Adam Back <adam@cypherspace•org> wrote:
                            >>> would dev consensus around releasing LOT=false be considered as "developers forcing their views on users"?
                            >>
                            >> given there are clearly people of both views, or for now don't care
                            >> but might later, it would minimally be friendly and useful if
                            >> bitcoin-core has a LOT=true option - and that IMO goes some way to
                            >> avoid the assumptive control via defaults.
                            > 
                            >> Otherwise it could be read as saying "developers on average
                            >> disapprove, but if you, the market disagree, go figure it out for
                            >> yourself" which is not a good message for being defensive and avoiding
                            >> mis-interpretation of code repositories or shipped defaults as
                            >> "control".
                            > 
                            > 
                            > _______________________________________________
                            > bitcoin-dev mailing list
                            > bitcoin-dev@lists•linuxfoundation.org
                            > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                            > 
                            
                            
                            ^ permalink raw reply	[flat|nested] 42+ messages in thread

                          • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                                2021-02-19 17:48                           ` Matt Corallo
                              @ 2021-02-20  2:55                             ` ZmnSCPxj
                                2021-02-20 17:20                               ` Ariel Lorenzo-Luaces
                                2021-02-22  5:16                             ` Anthony Towns
                                1 sibling, 1 reply; 42+ messages in thread
                              From: ZmnSCPxj @ 2021-02-20  2:55 UTC (permalink / raw)
                                To: Matt Corallo; +Cc: Michael Folkson, Bitcoin Protocol Discussion
                              
                              Good morning list,
                              
                              > It was pointed out to me that this discussion is largely moot as the software complexity for Bitcoin Core to ship an
                              > option like this is likely not practical/what people would wish to see.
                              >
                              > Bitcoin Core does not have infrastructure to handle switching consensus rules with the same datadir - after running with
                              > uasf=true for some time, valid blocks will be marked as invalid, and additional development would need to occur to
                              > enable switching back to uasf=false. This is complex, critical code to get right, and the review and testing cycles
                              > needed seem to be not worth it.
                              
                              Without implying anything else, this can be worked around by a user maintaining two `datadir`s and running two clients.
                              This would have an "external" client running an LOT=X (where X is whatever the user prefers) and an "internal" client that is at most 0.21.0, which will not impose any LOT rules.
                              The internal client then uses `connect=` directive to connect locally to the external client and connects only to that client, using it as a firewall.
                              The external client can be run pruned in order to reduce diskspace resource usage (the internal client can remain unpruned if that is needed by the user, e.g. for LN implementation sthat need to look up arbitrary short-channel-ids).
                              Bandwidth usage should be same since the internal client only connects to the external client and the OS should optimize that case.
                              CPU usage is doubled, though.
                              
                              (the general idea came from gmax, just to be clear, though the below use is from me)
                              
                              Then the user can select LOT=C or LOT=!C (where C is whatever Bitcoin Core ultimately ships with) on the external client based on the user preferences.
                              
                              If Taproot is not MASF-activated and LOT=!U is what dominates later (where U is whatever the user decided on), the user can decide to just destroy the external node and connect the internal node directly to the network (optionally upgrading the internal node to LOT=!U) as a way to "change their mind in view of the economy".
                              The internal node will then follow the dominant chain.
                              
                              
                              Regards,
                              ZmnSCPxj
                              
                              >
                              > Instead, the only practical way to ship such an option would be to treat it as a separate chain (the same way regtest,
                              > testnet, and signet are treated), including its own separate datadir and the like.
                              >
                              > Matt
                              >
                              > On 2/19/21 09:13, Matt Corallo via bitcoin-dev wrote:
                              >
                              > > (Also in response to ZMN...)
                              > > Bitcoin Core has a long-standing policy of not shipping options which shoot yourself in the foot. I’d be very disappointed if that changed now. People are of course more than welcome to run such software themselves, but I anticipate the loud minority on Twitter and here aren’t processing enough transactions or throwing enough financial weight behind their decision for them to do anything but just switch back if they find themselves on a chain with no blocks.
                              > > There’s nothing we can (or should) do to prevent people from threatening to (and possibly) forking themselves off of bitcoin, but that doesn’t mean we should encourage it either. The work Bitcoin Core maintainers and developers do is to recommend courses of action which they believe have reasonable levels of consensus and are technically sound. Luckily, there’s strong historical precedent for people deciding to run other software around forks, so misinterpretation is not very common (just like there’s strong historical precedent for miners not unilaterally deciding forks in the case of Segwit).
                              > > Matt
                              > >
                              > > > On Feb 19, 2021, at 07:08, Adam Back adam@cypherspace•org wrote:
                              > > >
                              > > > > would dev consensus around releasing LOT=false be considered as "developers forcing their views on users"?
                              > > >
                              > > > given there are clearly people of both views, or for now don't care
                              > > > but might later, it would minimally be friendly and useful if
                              > > > bitcoin-core has a LOT=true option - and that IMO goes some way to
                              > > > avoid the assumptive control via defaults.
                              > >
                              > > > Otherwise it could be read as saying "developers on average
                              > > > disapprove, but if you, the market disagree, go figure it out for
                              > > > yourself" which is not a good message for being defensive and avoiding
                              > > > mis-interpretation of code repositories or shipped defaults as
                              > > > "control".
                              > >
                              > > bitcoin-dev mailing list
                              > > bitcoin-dev@lists•linuxfoundation.org
                              > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                              
                              
                              
                              
                              ^ permalink raw reply	[flat|nested] 42+ messages in thread

                            • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                                  2021-02-20  2:55                             ` ZmnSCPxj
                                @ 2021-02-20 17:20                               ` Ariel Lorenzo-Luaces
                                  2021-02-21 14:30                                 ` Matt Corallo
                                  0 siblings, 1 reply; 42+ messages in thread
                                From: Ariel Lorenzo-Luaces @ 2021-02-20 17:20 UTC (permalink / raw)
                                  To: ZmnSCPxj, Bitcoin Protocol Discussion, ZmnSCPxj
                                
                                [-- Attachment #1: Type: text/plain, Size: 5112 bytes --]
                                
                                What would be the tradeoffs of a BIP8(false, ∞) option? That would remove some of the concerns of having to coordinate a UASF with an approaching deadline.
                                
                                Cheers
                                Ariel Lorenzo-Luaces
                                ⁣​
                                
                                On Feb 19, 2021, 6:55 PM, at 6:55 PM, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
                                >Good morning list,
                                >
                                >> It was pointed out to me that this discussion is largely moot as the
                                >software complexity for Bitcoin Core to ship an
                                >> option like this is likely not practical/what people would wish to
                                >see.
                                >>
                                >> Bitcoin Core does not have infrastructure to handle switching
                                >consensus rules with the same datadir - after running with
                                >> uasf=true for some time, valid blocks will be marked as invalid, and
                                >additional development would need to occur to
                                >> enable switching back to uasf=false. This is complex, critical code
                                >to get right, and the review and testing cycles
                                >> needed seem to be not worth it.
                                >
                                >Without implying anything else, this can be worked around by a user
                                >maintaining two `datadir`s and running two clients.
                                >This would have an "external" client running an LOT=X (where X is
                                >whatever the user prefers) and an "internal" client that is at most
                                >0.21.0, which will not impose any LOT rules.
                                >The internal client then uses `connect=` directive to connect locally
                                >to the external client and connects only to that client, using it as a
                                >firewall.
                                >The external client can be run pruned in order to reduce diskspace
                                >resource usage (the internal client can remain unpruned if that is
                                >needed by the user, e.g. for LN implementation sthat need to look up
                                >arbitrary short-channel-ids).
                                >Bandwidth usage should be same since the internal client only connects
                                >to the external client and the OS should optimize that case.
                                >CPU usage is doubled, though.
                                >
                                >(the general idea came from gmax, just to be clear, though the below
                                >use is from me)
                                >
                                >Then the user can select LOT=C or LOT=!C (where C is whatever Bitcoin
                                >Core ultimately ships with) on the external client based on the user
                                >preferences.
                                >
                                >If Taproot is not MASF-activated and LOT=!U is what dominates later
                                >(where U is whatever the user decided on), the user can decide to just
                                >destroy the external node and connect the internal node directly to the
                                >network (optionally upgrading the internal node to LOT=!U) as a way to
                                >"change their mind in view of the economy".
                                >The internal node will then follow the dominant chain.
                                >
                                >
                                >Regards,
                                >ZmnSCPxj
                                >
                                >>
                                >> Instead, the only practical way to ship such an option would be to
                                >treat it as a separate chain (the same way regtest,
                                >> testnet, and signet are treated), including its own separate datadir
                                >and the like.
                                >>
                                >> Matt
                                >>
                                >> On 2/19/21 09:13, Matt Corallo via bitcoin-dev wrote:
                                >>
                                >> > (Also in response to ZMN...)
                                >> > Bitcoin Core has a long-standing policy of not shipping options
                                >which shoot yourself in the foot. I’d be very disappointed if that
                                >changed now. People are of course more than welcome to run such
                                >software themselves, but I anticipate the loud minority on Twitter and
                                >here aren’t processing enough transactions or throwing enough financial
                                >weight behind their decision for them to do anything but just switch
                                >back if they find themselves on a chain with no blocks.
                                >> > There’s nothing we can (or should) do to prevent people from
                                >threatening to (and possibly) forking themselves off of bitcoin, but
                                >that doesn’t mean we should encourage it either. The work Bitcoin Core
                                >maintainers and developers do is to recommend courses of action which
                                >they believe have reasonable levels of consensus and are technically
                                >sound. Luckily, there’s strong historical precedent for people deciding
                                >to run other software around forks, so misinterpretation is not very
                                >common (just like there’s strong historical precedent for miners not
                                >unilaterally deciding forks in the case of Segwit).
                                >> > Matt
                                >> >
                                >> > > On Feb 19, 2021, at 07:08, Adam Back adam@cypherspace•org wrote:
                                >> > >
                                >> > > > would dev consensus around releasing LOT=false be considered as
                                >"developers forcing their views on users"?
                                >> > >
                                >> > > given there are clearly people of both views, or for now don't
                                >care
                                >> > > but might later, it would minimally be friendly and useful if
                                >> > > bitcoin-core has a LOT=true option - and that IMO goes some way
                                >to
                                >> > > avoid the assumptive control via defaults.
                                >> >
                                >> > > Otherwise it could be read as saying "developers on average
                                >> > > disapprove, but if you, the market disagree, go figure it out for
                                >> > > yourself" which is not a good message for being defensive and
                                >avoiding
                                >> > > mis-interpretation of code repositories or shipped defaults as
                                >> > > "control".
                                >> >
                                >> > bitcoin-dev mailing list
                                >> > bitcoin-dev@lists•linuxfoundation.org
                                >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                                >
                                >
                                >_______________________________________________
                                >bitcoin-dev mailing list
                                >bitcoin-dev@lists•linuxfoundation.org
                                >https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                                
                                [-- Attachment #2: Type: text/html, Size: 6259 bytes --]
                                
                                ^ permalink raw reply	[flat|nested] 42+ messages in thread

                              • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                                    2021-02-20 17:20                               ` Ariel Lorenzo-Luaces
                                  @ 2021-02-21 14:30                                 ` Matt Corallo
                                    0 siblings, 0 replies; 42+ messages in thread
                                  From: Matt Corallo @ 2021-02-21 14:30 UTC (permalink / raw)
                                    To: Ariel Lorenzo-Luaces, Bitcoin Protocol Discussion
                                  
                                  [-- Attachment #1: Type: text/plain, Size: 6116 bytes --]
                                  
                                  I don’t think “some vocal users are going to threaten to fork themselves off” is good justification for technical decisions. It’s important to communicate and for everyone to agree/understand that a failed BIP 8/9 activation, in the scenario people are worried about, is not the end of the story for Taproot activation. If it is clear that Taproot has broad consensus but some miners failed to upgrade in time (as it presumably would be), a flag day activation seems merited and I’m not sure anyone has argued against this. That said, forced-signaling via a UASF/BIP8(true)-style fork carries material additional risk that a classic flag-day activation does not, so let’s not optimize for something like that.
                                  
                                  Matt
                                  
                                  > On Feb 21, 2021, at 08:26, Ariel Lorenzo-Luaces via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
                                  > 
                                  > 
                                  > What would be the tradeoffs of a BIP8(false, ∞) option? That would remove some of the concerns of having to coordinate a UASF with an approaching deadline.
                                  > 
                                  > Cheers
                                  > Ariel Lorenzo-Luaces
                                  >> On Feb 19, 2021, at 6:55 PM, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
                                  >> Good morning list,
                                  >> 
                                  >>>  It was pointed out to me that this discussion is largely moot as the software complexity for Bitcoin Core to ship an
                                  >>>  option like this is likely not practical/what people would wish to see.
                                  >>> 
                                  >>>  Bitcoin Core does not have infrastructure to handle switching consensus rules with the same datadir - after running with
                                  >>>  uasf=true for some time, valid blocks will be marked as invalid, and additional development would need to occur to
                                  >>>  enable switching back to uasf=false. This is complex, critical code to get right, and the review and testing cycles
                                  >>>  needed seem to be not worth it.
                                  >> 
                                  >> Without implying anything else, this can be worked around by a user maintaining two `datadir`s and running two clients.
                                  >> This would have an "external" client running an LOT=X (where X is whatever the user prefers) and an "internal" client that is at most 0.21.0, which will not impose any LOT rules.
                                  >> The internal client then uses `connect=` directive to connect locally to the external client and connects only to that client, using it as a firewall.
                                  >> The external client can be run pruned in order to reduce diskspace resource usage (the internal client can remain unpruned if that is needed by the user, e.g. for LN implementation sthat need to look up arbitrary short-channel-ids).
                                  >> Bandwidth usage should be same since the internal client only connects to the external client and the OS should optimize that case.
                                  >> CPU usage is doubled, though.
                                  >> 
                                  >> (the general idea came from gmax, just to be clear, though the below use is from me)
                                  >> 
                                  >> Then the user can select LOT=C or LOT=!C (where C is whatever Bitcoin Core ultimately ships with) on the external client based on the user preferences.
                                  >> 
                                  >> If Taproot is not MASF-activated and LOT=!U is what dominates later (where U is whatever the user decided on), the user can decide to just destroy the external node and connect the internal node directly to the network (optionally upgrading the internal node to LOT=!U) as a way to "change their mind in view of the economy".
                                  >> The internal node will then follow the dominant chain.
                                  >> 
                                  >> 
                                  >> Regards,
                                  >> ZmnSCPxj
                                  >> 
                                  >>> 
                                  >>>  Instead, the only practical way to ship such an option would be to treat it as a separate chain (the same way regtest,
                                  >>>  testnet, and signet are treated), including its own separate datadir and the like.
                                  >>> 
                                  >>>  Matt
                                  >>> 
                                  >>>>  On 2/19/21 09:13, Matt Corallo via bitcoin-dev wrote:
                                  >>>> 
                                  >>>>  (Also in response to ZMN...)
                                  >>>>  Bitcoin Core has a long-standing policy of not shipping options which shoot yourself in the foot. I’d be very disappointed if that changed now. People are of course more than welcome to run such software themselves, but I anticipate the loud minority on Twitter and here aren’t processing enough transactions or throwing enough financial weight behind their decision for them to do anything but just switch back if they find themselves on a chain with no blocks.
                                  >>>>  There’s nothing we can (or should) do to prevent people from threatening to (and possibly) forking themselves off of bitcoin, but that doesn’t mean we should encourage it either. The work Bitcoin Core maintainers and developers do is to recommend courses of action which they believe have reasonable levels of consensus and are technically sound. Luckily, there’s strong historical precedent for people deciding to run other software around forks, so misinterpretation is not very common (just like there’s strong historical precedent for miners not unilaterally deciding forks in the case of Segwit).
                                  >>>>  Matt
                                  >>>> 
                                  >>>>>>  On Feb 19, 2021, at 07:08, Adam Back adam@cypherspace•org wrote:
                                  >>>>>> 
                                  >>>>>>  would dev consensus around releasing LOT=false be considered as "developers forcing their views on users"?
                                  >>>>> 
                                  >>>>>  given there are clearly people of both views, or for now don't care
                                  >>>>>  but might later, it would minimally be friendly and useful if
                                  >>>>>  bitcoin-core has a LOT=true option - and that IMO goes some way to
                                  >>>>>  avoid the assumptive control via defaults.
                                  >>>> 
                                  >>>>>  Otherwise it could be read as saying "developers on average
                                  >>>>>  disapprove, but if you, the market disagree, go figure it out for
                                  >>>>>  yourself" which is not a good message for being defensive and avoiding
                                  >>>>>  mis-interpretation of code repositories or shipped defaults as
                                  >>>>>  "control".
                                  >>>> 
                                  >>>>  bitcoin-dev mailing list
                                  >>>>  bitcoin-dev@lists•linuxfoundation.org
                                  >>>>  https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                                  >> 
                                  >> 
                                  >> 
                                  >> bitcoin-dev mailing list
                                  >> bitcoin-dev@lists•linuxfoundation.org
                                  >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                                  > _______________________________________________
                                  > bitcoin-dev mailing list
                                  > bitcoin-dev@lists•linuxfoundation.org
                                  > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                                  
                                  [-- Attachment #2: Type: text/html, Size: 7613 bytes --]
                                  
                                  ^ permalink raw reply	[flat|nested] 42+ messages in thread

                            • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                                2021-02-19 17:48                           ` Matt Corallo
                                2021-02-20  2:55                             ` ZmnSCPxj
                              @ 2021-02-22  5:16                             ` Anthony Towns
                                2021-02-22  6:44                               ` Matt Corallo
                                1 sibling, 1 reply; 42+ messages in thread
                              From: Anthony Towns @ 2021-02-22  5:16 UTC (permalink / raw)
                                To: Matt Corallo, Bitcoin Protocol Discussion; +Cc: Michael Folkson
                              
                              On Fri, Feb 19, 2021 at 12:48:00PM -0500, Matt Corallo via bitcoin-dev wrote:
                              > It was pointed out to me that this discussion is largely moot as the
                              > software complexity for Bitcoin Core to ship an option like this is likely
                              > not practical/what people would wish to see.
                              > Bitcoin Core does not have infrastructure to handle switching consensus
                              > rules with the same datadir - after running with uasf=true for some time,
                              > valid blocks will be marked as invalid, 
                              
                              I don't think this is true? With the current proposed bip8 code,
                              lockinontimeout=true will cause headers to be marked as invalid, and
                              won't process the block further. If a node running lockinontimeout=true
                              accepts the header, then it will apply the same consensus rules as a
                              lockinontimeout=false node.
                              
                              I don't think an invalid header will be added to the block index at all,
                              so a node restart should always cleanly allow it to be reconsidered.
                              
                              The test case in
                              
                              https://github.com/bitcoin/bitcoin/pull/19573/commits/bd8517135fc839c3332fea4d9c8373b94c8c9de8
                              
                              tests that a node that had rejected a chain due to lockinontimeout=true
                              will reorg to that chain after being restarted as a byproduct of the way
                              it tests different cases (the nodes set a new startheight, but retain
                              their lockinontimeout settings).
                              
                              
                              (I think with the current bip8 code, if you switch from
                              lockinontimeout=false to lockinontimeout=true and the tip of the current
                              most work chain is after the timeoutheight and did not lockin, then you
                              will continue following that chain until a taproot-invalid transaction
                              is inclued, rather than immediately reorging to a shorter chain that
                              complies with the lockinontimeout=true rules)
                              
                              Cheers,
                              aj
                              
                              
                              
                              ^ permalink raw reply	[flat|nested] 42+ messages in thread

                            • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                                  2021-02-22  5:16                             ` Anthony Towns
                                @ 2021-02-22  6:44                               ` Matt Corallo
                                  2021-02-22 10:16                                 ` Anthony Towns
                                  0 siblings, 1 reply; 42+ messages in thread
                                From: Matt Corallo @ 2021-02-22  6:44 UTC (permalink / raw)
                                  To: Anthony Towns; +Cc: Michael Folkson, Bitcoin Protocol Discussion
                                
                                Hmm, indeed, I may have missed that you can skip the headers issues by not persisting them, though there are other follow-on effects that are concerning and I think still make my point valid.
                                
                                A node feeding you invalid headers (used to be) cause for a ban - is that information still persisted? More importantly, nodes on both sides of the fork need to find each other. There’s not a great way to do that without forking the address database, DNS seeds and defining a new protocol magic.
                                
                                Matt
                                
                                > On Feb 22, 2021, at 00:16, Anthony Towns <aj@erisian•com.au> wrote:
                                > 
                                > On Fri, Feb 19, 2021 at 12:48:00PM -0500, Matt Corallo via bitcoin-dev wrote:
                                >> It was pointed out to me that this discussion is largely moot as the
                                >> software complexity for Bitcoin Core to ship an option like this is likely
                                >> not practical/what people would wish to see.
                                >> Bitcoin Core does not have infrastructure to handle switching consensus
                                >> rules with the same datadir - after running with uasf=true for some time,
                                >> valid blocks will be marked as invalid, 
                                > 
                                > I don't think this is true? With the current proposed bip8 code,
                                > lockinontimeout=true will cause headers to be marked as invalid, and
                                > won't process the block further. If a node running lockinontimeout=true
                                > accepts the header, then it will apply the same consensus rules as a
                                > lockinontimeout=false node.
                                > 
                                > I don't think an invalid header will be added to the block index at all,
                                > so a node restart should always cleanly allow it to be reconsidered.
                                > 
                                > The test case in
                                > 
                                > https://github.com/bitcoin/bitcoin/pull/19573/commits/bd8517135fc839c3332fea4d9c8373b94c8c9de8
                                > 
                                > tests that a node that had rejected a chain due to lockinontimeout=true
                                > will reorg to that chain after being restarted as a byproduct of the way
                                > it tests different cases (the nodes set a new startheight, but retain
                                > their lockinontimeout settings).
                                > 
                                > 
                                > (I think with the current bip8 code, if you switch from
                                > lockinontimeout=false to lockinontimeout=true and the tip of the current
                                > most work chain is after the timeoutheight and did not lockin, then you
                                > will continue following that chain until a taproot-invalid transaction
                                > is inclued, rather than immediately reorging to a shorter chain that
                                > complies with the lockinontimeout=true rules)
                                > 
                                > Cheers,
                                > aj
                                > 
                                
                                
                                ^ permalink raw reply	[flat|nested] 42+ messages in thread

                              • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                                    2021-02-22  6:44                               ` Matt Corallo
                                  @ 2021-02-22 10:16                                 ` Anthony Towns
                                    2021-02-22 14:00                                   ` Matt Corallo
                                    0 siblings, 1 reply; 42+ messages in thread
                                  From: Anthony Towns @ 2021-02-22 10:16 UTC (permalink / raw)
                                    To: Matt Corallo; +Cc: Michael Folkson, Bitcoin Protocol Discussion
                                  
                                  On Mon, Feb 22, 2021 at 01:44:55AM -0500, Matt Corallo wrote:
                                  > A node feeding you invalid headers (used to be) cause for a ban [...]
                                  
                                  Headers that are invalid due to MUST_SIGNAL rules are marked as
                                  BLOCK_RECENT_CONSENSUS_CHANGE so don't directly result in a ban. If you're
                                  doing headers-first relay, I think that will also prevent hitting the
                                  BLOCK_MISSING_PREV case, which would result in a ban.
                                  
                                  If a lockinontimeout=true node is requesting compact blocks from a
                                  lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase,
                                  I think that could result in a ban.
                                  
                                  > More importantly, nodes on both sides of the fork need to find each other. 
                                  
                                  (If there was going to be an ongoing fork there'd be bigger things to
                                  worry about...)
                                  
                                  I think the important specific case of this is something like "if a chain
                                  where taproot is impossible to activate is temporarily the most work,
                                  miners with lockinontimeout=true need to be well connected so they don't
                                  end up competing with each other while they're catching back up".
                                  
                                  Actually, that same requirement might be more practically for a signet
                                  feature we were thinking about -- namely having "optional reorgs", ie
                                  every now and then we'd mine 1-6 blocks and then reorg them out; but
                                  also flag the soon-to-be-stale blocks in some way so that if you didn't
                                  want to have to deal with reorgs you could easily ignore them. Having
                                  it be possible for the "I want to see reorgs!" nodes to be able to find
                                  each other seems like it might be a similar problem (avoiding having the
                                  "don't-want-reorgs" nodes ban the "want-reorgs" nodes too perhaps).
                                  
                                  Cheers,
                                  aj
                                  
                                  
                                  
                                  ^ permalink raw reply	[flat|nested] 42+ messages in thread

                                • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                                      2021-02-22 10:16                                 ` Anthony Towns
                                    @ 2021-02-22 14:00                                   ` Matt Corallo
                                      2021-02-22 16:27                                     ` Anthony Towns
                                      2021-02-22 16:31                                     ` Jorge Timón
                                      0 siblings, 2 replies; 42+ messages in thread
                                    From: Matt Corallo @ 2021-02-22 14:00 UTC (permalink / raw)
                                      To: Anthony Towns; +Cc: Michael Folkson, Bitcoin Protocol Discussion
                                    
                                    [-- Attachment #1: Type: text/plain, Size: 1298 bytes --]
                                    
                                    
                                    
                                    > On Feb 22, 2021, at 05:16, Anthony Towns <aj@erisian•com.au> wrote:
                                    > 
                                    > If a lockinontimeout=true node is requesting compact blocks from a
                                    > lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase,
                                    > I think that could result in a ban.
                                    > 
                                    >> More importantly, nodes on both sides of the fork need to find each other. 
                                    > 
                                    > (If there was going to be an ongoing fork there'd be bigger things to
                                    > worry about...)
                                    
                                    I think it should be clear that a UASF-style command line option to allow consensus rule changes in the node in the short term, immediately before a fork carries some risk of a fork, even if I agree it may not persist over months. We can’t simply ignore that.
                                    
                                    > I think the important specific case of this is something like "if a chain
                                    > where taproot is impossible to activate is temporarily the most work,
                                    > miners with lockinontimeout=true need to be well connected so they don't
                                    > end up competing with each other while they're catching back up".
                                    
                                    Between this and your above point, I think we probably agree - there is material  technical complexity hiding behind a “change the consensus rules“ option. Given it’s not a critical feature by any means, putting resources into fixing these issues probably isn’t worth it.
                                    
                                    Matt
                                    
                                    [-- Attachment #2: Type: text/html, Size: 1968 bytes --]
                                    
                                    ^ permalink raw reply	[flat|nested] 42+ messages in thread

                                  • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                                        2021-02-22 14:00                                   ` Matt Corallo
                                      @ 2021-02-22 16:27                                     ` Anthony Towns
                                        2021-02-22 16:31                                     ` Jorge Timón
                                        1 sibling, 0 replies; 42+ messages in thread
                                      From: Anthony Towns @ 2021-02-22 16:27 UTC (permalink / raw)
                                        To: Matt Corallo; +Cc: Michael Folkson, Bitcoin Protocol Discussion
                                      
                                      On Mon, Feb 22, 2021 at 09:00:29AM -0500, Matt Corallo wrote:
                                      > I think it should be clear that a UASF-style command line option to allow
                                      > consensus rule changes in the node in the short term, immediately before a fork
                                      > carries some risk of a fork, even if I agree it may not persist over months. We
                                      > can’t simply ignore that.
                                      
                                      I don't think a "-set-bip8-lockinontimeout=taproot" option on its own
                                      would be very safe -- if we were sure it was safe, because we were sure
                                      that everyone would eventually set lockinontimeout=true, then we would
                                      set lockinontimeout=true from day one and not need an option. I haven't
                                      seen/had any good ideas on how to make the option safe, or at least make
                                      it obvious that you shouldn't be setting it if you don't really
                                      understand what you're getting yourself into. [0]
                                      
                                      And that's even if you assume that the code was perfectly capable of
                                      handling forks in some theoretically optimal way.
                                      
                                      So at least for the time being, I don't think a config param / command
                                      line option is a good idea for bip8. IMHO, YMMV, IANABDFL etc.
                                      
                                      >     I think the important specific case of this is something like "if a chain
                                      >     where taproot is impossible to activate is temporarily the most work,
                                      >     miners with lockinontimeout=true need to be well connected so they don't
                                      >     end up competing with each other while they're catching back up".
                                      > Between this and your above point, I think we probably agree - there is
                                      > material  technical complexity hiding behind a “change the consensus rules“
                                      > option. Given it’s not a critical feature by any means, putting resources into
                                      > fixing these issues probably isn’t worth it.
                                      
                                      For reference, the "preferentially peer with other UASF nodes" PR for
                                      the BIP148 client was
                                      
                                        https://github.com/UASF/bitcoin/pull/24
                                      
                                      List discussion was at
                                      
                                        https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014618.html
                                      
                                      I think I'll add playing around with that and reorgs on a signet to my
                                      todo list to see how it goes in cases other than ones that are (hopefully)
                                      vanishingly unlikely to ever happen in practice.
                                      
                                      Cheers,
                                      aj
                                      
                                      [0] In some sense, this is exactly the opposite sentiment compared to
                                          earonesty's comment:
                                      
                                          https://github.com/bitcoin/bitcoin/pull/10900#issuecomment-317333312
                                      
                                          I mean, I guess could solve the unsafe-now-but-maybe-safe-later
                                          problem generally with a signature:
                                      
                                            -authorise-dangerous-options-key=XXXX
                                            -lockinontimeout=taproot:YYYY
                                      
                                          where YYYY is a signature of "dangerous:lockinontimeout=taproot" or
                                          similar by the key XXXX, and XXXX defaults to some (multisig?) key
                                          controlled by some bitcoin people, who'll only sign that when
                                          there's clear evidence that it will be reasonably safe, and maybe to
                                          "cert-transparency" or something as well. So that allows having an
                                          option become available by publishing a signature, without having
                                          to recompile the code. And it could still be overriden by people who
                                          know what they're doing if the default key owners are being weird. And
                                          maybe the "dangerous" part is enough to prevent people from randomly
                                          cut-and-pasting it from a website into their bitcoin.conf.
                                      
                                          I dunno. No bad ideas when brainstorming...
                                      
                                      
                                      ^ permalink raw reply	[flat|nested] 42+ messages in thread

                                    • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                                        2021-02-22 14:00                                   ` Matt Corallo
                                        2021-02-22 16:27                                     ` Anthony Towns
                                      @ 2021-02-22 16:31                                     ` Jorge Timón
                                        2021-02-22 16:48                                       ` Jorge Timón
                                        1 sibling, 1 reply; 42+ messages in thread
                                      From: Jorge Timón @ 2021-02-22 16:31 UTC (permalink / raw)
                                        To: Matt Corallo, Bitcoin Protocol Discussion; +Cc: Michael Folkson
                                      
                                      Sorry, I haven't read everything. I just want to say what I think is
                                      the best option and why.
                                      Let's say something like 2 years in which miners can signal activation
                                      after which, the MUST signal it for their blocks to be valid (I think
                                      this is LOT=true, but I don't remember what LOT stands for).
                                      Some may argue than it's easier to move from LOT=false to LOT=true
                                      than viceversa (I think I'm getting this right), but either way
                                      different clients could interpret things more differently more easily
                                      and, you know, that's really bad.
                                      If anyone is against the consensus change itself, what they should do
                                      is run a client in which the must is turned into a MUST NOT. Whenever
                                      miners signal activation, blocks aren't valid so that it doesn't
                                      happen.
                                      That way both sides can be cleanly separated and both communities
                                      (assuming there's a community of users opposing the change) can stick
                                      together with their own in the same chain. That is, having only 2
                                      chains in total if there are users opposing the change or only one if
                                      not, but never 2 chains for people who want the change or 2 chains for
                                      pople who don't want it.
                                      
                                      Just my two sats, please nobody ask me "why would anyone oppose
                                      taproot?" or anything similar. Because I'm trying to generalize here,
                                      if we're talking about activation, I think the specifics of the change
                                      are kind of irrelevant.
                                      
                                      Separately: thanks to everyone who worked on taproot.
                                      
                                      
                                      On Mon, Feb 22, 2021 at 3:00 PM Matt Corallo via bitcoin-dev
                                      <bitcoin-dev@lists•linuxfoundation.org> wrote:
                                      >
                                      >
                                      >
                                      > On Feb 22, 2021, at 05:16, Anthony Towns <aj@erisian•com.au> wrote:
                                      >
                                      > If a lockinontimeout=true node is requesting compact blocks from a
                                      > lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase,
                                      > I think that could result in a ban.
                                      >
                                      > More importantly, nodes on both sides of the fork need to find each other.
                                      >
                                      >
                                      > (If there was going to be an ongoing fork there'd be bigger things to
                                      > worry about...)
                                      >
                                      >
                                      > I think it should be clear that a UASF-style command line option to allow consensus rule changes in the node in the short term, immediately before a fork carries some risk of a fork, even if I agree it may not persist over months. We can’t simply ignore that.
                                      >
                                      > I think the important specific case of this is something like "if a chain
                                      > where taproot is impossible to activate is temporarily the most work,
                                      > miners with lockinontimeout=true need to be well connected so they don't
                                      > end up competing with each other while they're catching back up".
                                      >
                                      >
                                      > Between this and your above point, I think we probably agree - there is material  technical complexity hiding behind a “change the consensus rules“ option. Given it’s not a critical feature by any means, putting resources into fixing these issues probably isn’t worth it.
                                      >
                                      > Matt
                                      > _______________________________________________
                                      > bitcoin-dev mailing list
                                      > bitcoin-dev@lists•linuxfoundation.org
                                      > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                                      
                                      
                                      ^ permalink raw reply	[flat|nested] 42+ messages in thread

                                    • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                                          2021-02-22 16:31                                     ` Jorge Timón
                                        @ 2021-02-22 16:48                                       ` Jorge Timón
                                          2021-02-23  2:10                                         ` Jeremy
                                          0 siblings, 1 reply; 42+ messages in thread
                                        From: Jorge Timón @ 2021-02-22 16:48 UTC (permalink / raw)
                                          To: Bitcoin Protocol Discussion
                                        
                                        Just to clarify, I'm not saying bitcoin core should maintain the
                                        "oppose proposal" part of the software. presumably people opposing the
                                        change don't want much of the recent software changes anyway.
                                        But perhaps it wouldn't be so bad, to oppose other proposals, perhaps.
                                        I don't expect anyone to want this, but if people want it I offer
                                        myself to code it,
                                        I mean, just imagine that a day after publishing a bitcoin core
                                        release with activation software for taproot some one, let's say in
                                        New York reach an Agreement to "just use the same activation
                                        mechanism, but for our 32 mb hardfork, it's about time, now computers
                                        are 64 bits anyway". How convenient would it be to just cancel that
                                        with 2 lines in bitcoin core?
                                        Not that I think it will be necessary, but perhaps we want it just in case.
                                        
                                        On Mon, Feb 22, 2021 at 5:31 PM Jorge Timón <jtimon@jtimon•cc> wrote:
                                        >
                                        > Sorry, I haven't read everything. I just want to say what I think is
                                        > the best option and why.
                                        > Let's say something like 2 years in which miners can signal activation
                                        > after which, the MUST signal it for their blocks to be valid (I think
                                        > this is LOT=true, but I don't remember what LOT stands for).
                                        > Some may argue than it's easier to move from LOT=false to LOT=true
                                        > than viceversa (I think I'm getting this right), but either way
                                        > different clients could interpret things more differently more easily
                                        > and, you know, that's really bad.
                                        > If anyone is against the consensus change itself, what they should do
                                        > is run a client in which the must is turned into a MUST NOT. Whenever
                                        > miners signal activation, blocks aren't valid so that it doesn't
                                        > happen.
                                        > That way both sides can be cleanly separated and both communities
                                        > (assuming there's a community of users opposing the change) can stick
                                        > together with their own in the same chain. That is, having only 2
                                        > chains in total if there are users opposing the change or only one if
                                        > not, but never 2 chains for people who want the change or 2 chains for
                                        > pople who don't want it.
                                        >
                                        > Just my two sats, please nobody ask me "why would anyone oppose
                                        > taproot?" or anything similar. Because I'm trying to generalize here,
                                        > if we're talking about activation, I think the specifics of the change
                                        > are kind of irrelevant.
                                        >
                                        > Separately: thanks to everyone who worked on taproot.
                                        >
                                        >
                                        > On Mon, Feb 22, 2021 at 3:00 PM Matt Corallo via bitcoin-dev
                                        > <bitcoin-dev@lists•linuxfoundation.org> wrote:
                                        > >
                                        > >
                                        > >
                                        > > On Feb 22, 2021, at 05:16, Anthony Towns <aj@erisian•com.au> wrote:
                                        > >
                                        > > If a lockinontimeout=true node is requesting compact blocks from a
                                        > > lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase,
                                        > > I think that could result in a ban.
                                        > >
                                        > > More importantly, nodes on both sides of the fork need to find each other.
                                        > >
                                        > >
                                        > > (If there was going to be an ongoing fork there'd be bigger things to
                                        > > worry about...)
                                        > >
                                        > >
                                        > > I think it should be clear that a UASF-style command line option to allow consensus rule changes in the node in the short term, immediately before a fork carries some risk of a fork, even if I agree it may not persist over months. We can’t simply ignore that.
                                        > >
                                        > > I think the important specific case of this is something like "if a chain
                                        > > where taproot is impossible to activate is temporarily the most work,
                                        > > miners with lockinontimeout=true need to be well connected so they don't
                                        > > end up competing with each other while they're catching back up".
                                        > >
                                        > >
                                        > > Between this and your above point, I think we probably agree - there is material  technical complexity hiding behind a “change the consensus rules“ option. Given it’s not a critical feature by any means, putting resources into fixing these issues probably isn’t worth it.
                                        > >
                                        > > Matt
                                        > > _______________________________________________
                                        > > bitcoin-dev mailing list
                                        > > bitcoin-dev@lists•linuxfoundation.org
                                        > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                                        
                                        
                                        ^ permalink raw reply	[flat|nested] 42+ messages in thread

                                      • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                                            2021-02-22 16:48                                       ` Jorge Timón
                                          @ 2021-02-23  2:10                                         ` Jeremy
                                            2021-02-23 19:33                                           ` Keagan McClelland
                                            2021-02-24  7:18                                           ` Anthony Towns
                                            0 siblings, 2 replies; 42+ messages in thread
                                          From: Jeremy @ 2021-02-23  2:10 UTC (permalink / raw)
                                            To: Bitcoin Protocol Discussion
                                          
                                          [-- Attachment #1: Type: text/plain, Size: 5577 bytes --]
                                          
                                          Not responding to anyone in particular, but it strikes me that one can
                                          think about the case where a small minority (let's say H = 20%?) of nodes
                                          select the opposite of what Core releases (LOT=false, LOT=true). I'm
                                          ignoring the case where a critical bug is discovered in Taproot for reasons
                                          I could expand on if anyone is interested (I don't think LOT=true/false has
                                          much of a diff in that regard).
                                          
                                          You'll note an asymmetry with LOT=true / false analysis. LOT=true nodes are
                                          clearly updated (or lying), LOT=false nodes may be un-upgraded (or however
                                          you want to interpret it).
                                          
                                          
                                          *# 80% on LOT=false, 20% LOT=True*
                                          
                                          - Case 1: Activates ahead of time anyways
                                          
                                          No issues.
                                          
                                          - Case 2: Fails to Activate before timeout...
                                          
                                          20% *may* fork off with LOT=true. Bitcoin hashrate reduced, chance of multi
                                          block reorgs at time of fork relatively high, especially if network does
                                          not partition.
                                          
                                          Implication is that activation % being 90%, then X% fewer than 70% of
                                          miners are signaling for Taproot at this time.  If X% is small the
                                          increased orphan rate caused by the LOT=true miners will cause it to
                                          activate anyways. If X% is larger, then there will be a consensus split.
                                          
                                          
                                          
                                          *# 80% on LOT=true, 20% LOT=False*
                                          - Case 1: Activates ahead of time Anyways
                                          
                                          No issues.
                                          
                                          - Case 2: Fails to Activate before timeout...
                                          
                                          A% + B% + C% = 20%
                                          
                                          A% (upgraded, signal activate) remain on majority chain with LOT=false,
                                          blocks mined universally valid.
                                          
                                          B% (upgraded, not signaling) succeeds in activating and maintaining
                                          consensus, blocks are temporarily lost during the final period, but
                                          consensus re-emerges.
                                          
                                          C% (not upgraded/not signalling) both fail to activate (not upgraded) and
                                          blocks are rejected (not signaling) during mandatory signalling.
                                          Essentially becomes an SPV miner, should still not select transactions
                                          improperly given mempool policy, but may mine a bad tip.
                                          
                                          (I argue that group B is irrational entirely, as in this case the majority
                                          has upgraded, inevitably winning, and is orphaning their blocks so B should
                                          effectively be 0% or can be combined with group C as being somehow not
                                          upgraded if they are unable to switch once it becomes clear after say the
                                          first 100 blocks in the period that LOT > 50%. The only difference in
                                          lumping B with C is that group C SPV mines after the fork and B should, in
                                          theory, have full validation.).
                                          
                                          
                                          
                                          Apologies if my base analysis is off -- happy to take corrections.
                                          
                                          
                                          My overall summary is thus:
                                          
                                          1) People care what Core releases because we assume the majority will
                                          likely run it. If core were a minority project, we wouldn't really care
                                          what core released.
                                          2) People are upset with LOT=true being suggested as release parameters
                                          because of the *narrative* that it puts devs in control.
                                          3) LOT=true having a sizeable minority running it presents major issues to
                                          majority LOT=false in terms of lost blocks during the final period and in
                                          terms of a longer term fork.
                                          4) Majority LOT=true has no long term instability on consensus (majority
                                          LOT=true means the final period always activates, any instability is short
                                          lived + irrational).
                                          5) On the balance, the safer parameter to release *seems* to be LOT=true.
                                          But because devs are sensitive to control narrative, LOT=false is preferred
                                          by devs.
                                          6) Almost paradoxically, choosing a *less safe* option for a narrative
                                          reason is more of a show of dev control than choosing a more safe option
                                          despite appearances.
                                          7) This all comes down to if we think that a reasonable number of important
                                          nodes will run LOT=true.
                                          8) This all doesn't matter *that much* because taproot will have many
                                          opportunities to activate before the brinksmanship period.
                                          
                                          As a plan of action, I think that means that either:
                                          
                                          A) Core should release LOT=true, as a less disruptive option given stated
                                          community intentions to do LOT=true
                                          B) Core  community should vehemently anti-advocate running LOT=true to
                                          ensure the % is as small as possible
                                          C) Do nothing
                                          D) Core community should release LOT=false and vehemently advocate manually
                                          changing to LOT=true to ensure the % is supermajority, but leaving it as a
                                          user choice.
                                          
                                          
                                          Overall, I worry that plan B has a mild Streissand effect and would result
                                          in boosting LOT=true (which could be OK, so long as LOT=true +
                                          LOT=false+signal yes becomes the large majority, but would be not fun for
                                          anyone if LOT=true + LOT=false+signal yes are a small majority). Plan C
                                          most likely ends up with some % doing LOT=true anyways. D feels a little
                                          silly, but maybe a good tradeoff.
                                          
                                          If I had to summarize the emotional dynamic among developers around
                                          LOT=true, I think devs wish it didn't exist because it is clear LOT=true
                                          *creates* the issues here. LOT=false would be fine if the LOT=true strategy
                                          didn't exist at all. But unfortunately the cat is out of the bag and cannot
                                          be put back in. To validate the emotions, I think it is fine to be angry
                                          about LOT=true and not like it, but we should either accept that it is most
                                          likely to create consensus OR we should find a new game theoretic
                                          activation strategy with better pro-social equilibriums.
                                          
                                          Personally, I think with either plan the ultimate risk of forking is low
                                          given probability to activate before timeout, so we should just pick
                                          something and move on, accepting that we aren't setting a precedent by
                                          which all future forks should abide. Given my understanding of the
                                          tradeoffs, I believe that the safest choice is LOT=true, but I wouldn't
                                          move to hold back a plan of LOT=false (but would probably take mitigative
                                          steps on community advocacy if it looks like there is non majority but non
                                          negligible LOT=true uptake).
                                          
                                          Cheers,
                                          
                                          Jeremy
                                          
                                          [-- Attachment #2: Type: text/html, Size: 13525 bytes --]
                                          
                                          ^ permalink raw reply	[flat|nested] 42+ messages in thread

                                        • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                                              2021-02-23  2:10                                         ` Jeremy
                                            @ 2021-02-23 19:33                                           ` Keagan McClelland
                                              2021-02-23 23:14                                             ` Ben Woosley
                                              2021-02-24 22:37                                             ` Ariel Luaces
                                              2021-02-24  7:18                                           ` Anthony Towns
                                              1 sibling, 2 replies; 42+ messages in thread
                                            From: Keagan McClelland @ 2021-02-23 19:33 UTC (permalink / raw)
                                              To: Jeremy, Bitcoin Protocol Discussion
                                            
                                            [-- Attachment #1: Type: text/plain, Size: 10012 bytes --]
                                            
                                            I wanted to follow up on what Jeremy and others are saying regards finding
                                            consensus on LOT. I've seen a few other opinions saying that finding
                                            consensus on the LOT value is far more important than what the LOT value
                                            actually is. This makes sense because if 100% of economic activity is
                                            running the same rule set, there is no divergence, regardless of which
                                            value is picked.
                                            
                                            It is my understanding that those who oppose LOT=true are mostly opposed on
                                            the grounds of it *appearing* "unnecessarily coercive" and that this lack
                                            of consensus can precipitate a chain split at the "brinksmanship period" as
                                            Jeremy refers to it. I don't think that we can say that LOT=true is
                                            coercive at all unless there is some opposition to Taproot itself.
                                            Opposition on the grounds that it *may* be opposed by others and Core does
                                            not want to assert control over the protocol is a conservative view but
                                            ultimately contingent upon opposition to Taproot for more fundamental
                                            reasons. If no one opposes it, then by definition you have consensus, and
                                            in that case I also don't think that the LOT=true (or false) in that regard
                                            sets meaningful precedent, as I would expect precedents to only be
                                            meaningful if they were established during a contentious scenario. As it
                                            stands we have precedents for both MASF's and UASF's to execute soft forks
                                            in Bitcoin.
                                            
                                            Of course it seems intractable to ascertain the views of ~100% of the
                                            Bitcoin constituency, and therefore it gives credibility to the argument
                                            that by coming to consensus on LOT=false among those who *are* speaking up
                                            is safer with the embedded assumptions that modifying consensus beyond what
                                            core ships is an active choice, presumably by those who know what they are
                                            doing. However, the simple act of Core choosing to ship an unconfigurable
                                            LOT=false value does not *prevent* the forking and creation of a UASF
                                            client. As Jeremy points out, the LOT=true possibility always exists here,
                                            and we have multiple high profile people saying they will be running that
                                            regardless of how things turn out. It seems to me that in this scenario,
                                            LOT=false does less to prevent a chain split.
                                            
                                            In regards to precedent, there may be good reasons to force that minority
                                            to fork themselves off the network, as would be the case if a hypothetical
                                            soft fork was a consensus action to blacklist some UTXO's or something else
                                            that weaponizes consensus against some subset of Bitcoin's user base, but I
                                            haven't heard a single person who advocates for LOT=false on the grounds
                                            that they *themselves* oppose the consensus change that is being proposed
                                            here. So if the goal is to prevent a chain split, and the soft fork is
                                            benign and essentially "annexing unoccupied territory" with respect to
                                            script versions, and no one actually has opposed Taproot itself, then I
                                            fail to see how LOT=false is safer in the presence of a grenade defense by
                                            the LOT=true crowd.
                                            
                                            I personally *prefer* LOT=true for these reasons, but I am NOT going to be
                                            joining the ranks of the intolerant minority if Core ultimately ships
                                            LOT=false. I think it is more important to stay in consensus, and as a
                                            result I am able to be convinced that false is the right answer. My
                                            question to everyone else (true AND false advocates) is this: what would
                                            you have to observe, in order to change your mind or is it immutably made
                                            up? If we have a significant portion of the community that is immutably
                                            made up to go false, and another portion that is going to go true, the
                                            asymmetry of the fork almost *requires* that those of us whose opinions are
                                            malleable to break for true.
                                            
                                            If social consensus is what drives technical consensus and not the other
                                            way around it seems as if there cannot exist a valid (rational?) reason to
                                            oppose Taproot itself, and then by extension with the arguments laid out
                                            above, LOT=true seems to be the logical conclusion of all of this, even if
                                            Core ships LOT=false at the outset.
                                            
                                            Where am I wrong here?
                                            
                                            Keagan
                                            
                                            On Mon, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev <
                                            bitcoin-dev@lists•linuxfoundation.org> wrote:
                                            
                                            > Not responding to anyone in particular, but it strikes me that one can
                                            > think about the case where a small minority (let's say H = 20%?) of nodes
                                            > select the opposite of what Core releases (LOT=false, LOT=true). I'm
                                            > ignoring the case where a critical bug is discovered in Taproot for reasons
                                            > I could expand on if anyone is interested (I don't think LOT=true/false has
                                            > much of a diff in that regard).
                                            >
                                            > You'll note an asymmetry with LOT=true / false analysis. LOT=true nodes
                                            > are clearly updated (or lying), LOT=false nodes may be un-upgraded (or
                                            > however you want to interpret it).
                                            >
                                            >
                                            > *# 80% on LOT=false, 20% LOT=True*
                                            >
                                            > - Case 1: Activates ahead of time anyways
                                            >
                                            > No issues.
                                            >
                                            > - Case 2: Fails to Activate before timeout...
                                            >
                                            > 20% *may* fork off with LOT=true. Bitcoin hashrate reduced, chance of
                                            > multi block reorgs at time of fork relatively high, especially if network
                                            > does not partition.
                                            >
                                            > Implication is that activation % being 90%, then X% fewer than 70% of
                                            > miners are signaling for Taproot at this time.  If X% is small the
                                            > increased orphan rate caused by the LOT=true miners will cause it to
                                            > activate anyways. If X% is larger, then there will be a consensus split.
                                            >
                                            >
                                            >
                                            > *# 80% on LOT=true, 20% LOT=False*
                                            > - Case 1: Activates ahead of time Anyways
                                            >
                                            > No issues.
                                            >
                                            > - Case 2: Fails to Activate before timeout...
                                            >
                                            > A% + B% + C% = 20%
                                            >
                                            > A% (upgraded, signal activate) remain on majority chain with LOT=false,
                                            > blocks mined universally valid.
                                            >
                                            > B% (upgraded, not signaling) succeeds in activating and maintaining
                                            > consensus, blocks are temporarily lost during the final period, but
                                            > consensus re-emerges.
                                            >
                                            > C% (not upgraded/not signalling) both fail to activate (not upgraded) and
                                            > blocks are rejected (not signaling) during mandatory signalling.
                                            > Essentially becomes an SPV miner, should still not select transactions
                                            > improperly given mempool policy, but may mine a bad tip.
                                            >
                                            > (I argue that group B is irrational entirely, as in this case the majority
                                            > has upgraded, inevitably winning, and is orphaning their blocks so B should
                                            > effectively be 0% or can be combined with group C as being somehow not
                                            > upgraded if they are unable to switch once it becomes clear after say the
                                            > first 100 blocks in the period that LOT > 50%. The only difference in
                                            > lumping B with C is that group C SPV mines after the fork and B should, in
                                            > theory, have full validation.).
                                            >
                                            >
                                            >
                                            > Apologies if my base analysis is off -- happy to take corrections.
                                            >
                                            >
                                            > My overall summary is thus:
                                            >
                                            > 1) People care what Core releases because we assume the majority will
                                            > likely run it. If core were a minority project, we wouldn't really care
                                            > what core released.
                                            > 2) People are upset with LOT=true being suggested as release parameters
                                            > because of the *narrative* that it puts devs in control.
                                            > 3) LOT=true having a sizeable minority running it presents major issues to
                                            > majority LOT=false in terms of lost blocks during the final period and in
                                            > terms of a longer term fork.
                                            > 4) Majority LOT=true has no long term instability on consensus (majority
                                            > LOT=true means the final period always activates, any instability is short
                                            > lived + irrational).
                                            > 5) On the balance, the safer parameter to release *seems* to be LOT=true.
                                            > But because devs are sensitive to control narrative, LOT=false is preferred
                                            > by devs.
                                            > 6) Almost paradoxically, choosing a *less safe* option for a narrative
                                            > reason is more of a show of dev control than choosing a more safe option
                                            > despite appearances.
                                            > 7) This all comes down to if we think that a reasonable number of
                                            > important nodes will run LOT=true.
                                            > 8) This all doesn't matter *that much* because taproot will have many
                                            > opportunities to activate before the brinksmanship period.
                                            >
                                            > As a plan of action, I think that means that either:
                                            >
                                            > A) Core should release LOT=true, as a less disruptive option given stated
                                            > community intentions to do LOT=true
                                            > B) Core  community should vehemently anti-advocate running LOT=true to
                                            > ensure the % is as small as possible
                                            > C) Do nothing
                                            > D) Core community should release LOT=false and vehemently advocate
                                            > manually changing to LOT=true to ensure the % is supermajority, but leaving
                                            > it as a user choice.
                                            >
                                            >
                                            > Overall, I worry that plan B has a mild Streissand effect and would result
                                            > in boosting LOT=true (which could be OK, so long as LOT=true +
                                            > LOT=false+signal yes becomes the large majority, but would be not fun for
                                            > anyone if LOT=true + LOT=false+signal yes are a small majority). Plan C
                                            > most likely ends up with some % doing LOT=true anyways. D feels a little
                                            > silly, but maybe a good tradeoff.
                                            >
                                            > If I had to summarize the emotional dynamic among developers around
                                            > LOT=true, I think devs wish it didn't exist because it is clear LOT=true
                                            > *creates* the issues here. LOT=false would be fine if the LOT=true strategy
                                            > didn't exist at all. But unfortunately the cat is out of the bag and cannot
                                            > be put back in. To validate the emotions, I think it is fine to be angry
                                            > about LOT=true and not like it, but we should either accept that it is most
                                            > likely to create consensus OR we should find a new game theoretic
                                            > activation strategy with better pro-social equilibriums.
                                            >
                                            > Personally, I think with either plan the ultimate risk of forking is low
                                            > given probability to activate before timeout, so we should just pick
                                            > something and move on, accepting that we aren't setting a precedent by
                                            > which all future forks should abide. Given my understanding of the
                                            > tradeoffs, I believe that the safest choice is LOT=true, but I wouldn't
                                            > move to hold back a plan of LOT=false (but would probably take mitigative
                                            > steps on community advocacy if it looks like there is non majority but non
                                            > negligible LOT=true uptake).
                                            >
                                            > Cheers,
                                            >
                                            > Jeremy
                                            >
                                            >
                                            > _______________________________________________
                                            > bitcoin-dev mailing list
                                            > bitcoin-dev@lists•linuxfoundation.org
                                            > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                                            >
                                            
                                            [-- Attachment #2: Type: text/html, Size: 17051 bytes --]
                                            
                                            ^ permalink raw reply	[flat|nested] 42+ messages in thread

                                          • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                                                2021-02-23 19:33                                           ` Keagan McClelland
                                              @ 2021-02-23 23:14                                             ` Ben Woosley
                                                2021-02-24 22:37                                             ` Ariel Luaces
                                                1 sibling, 0 replies; 42+ messages in thread
                                              From: Ben Woosley @ 2021-02-23 23:14 UTC (permalink / raw)
                                                To: Keagan McClelland, Jeremy; +Cc: Bitcoin Protocol Discussion
                                              
                                              [-- Attachment #1: Type: text/plain, Size: 12574 bytes --]
                                              
                                              Relative to your arguments, Keagan and Jeremy, and speaking in favor of
                                              LOT=false, from my limited perspective:
                                              
                                              > As Jeremy points out, the LOT=true possibility always exists here, and we
                                              have multiple high profile people saying they will be running that
                                              regardless of how things turn out. It seems to me that in this scenario,
                                              LOT=false does less to prevent a chain split.
                                              > So if the goal is to prevent a chain split, and the soft fork is benign
                                              and essentially "annexing unoccupied territory" with respect to script
                                              versions, and no one actually has opposed Taproot itself, then I fail to
                                              see how LOT=false is safer in the presence of a grenade defense by the
                                              LOT=true crowd.
                                              
                                              I don't believe the goal is to avoid a chain split, nor to activate
                                              Taproot. Over the long term it will not have been important when exactly
                                              Taproot activated, or whether a minority forked off, but what culture and
                                              norms we adopted in putting forward this change. A culture of deference to
                                              the network makes Core worthy of remaining the reference implementation of
                                              Bitcoin.
                                              
                                              Given Core's special position in the client ecosystem, I see these outcomes
                                              are asymmetric:
                                              a) If an intolerant minority signals LOT=true in contradiction to core,
                                              they are splitting consensus / forking off consensus, which is their right
                                              to do in our open ecosystem.
                                              b) If Core ships LOT=true, we are in fact imposing a change on the network.
                                              This may be justified in the end, but it should be used with discretion.
                                              
                                              If LOT=false fails to activate, then the failure will have revealed
                                              information about sentiments and elements of the network, and we will have
                                              an opportunity then to address that information before proceeding with
                                              LOT=true.
                                              
                                              To adopt b) as a pre-emptive defense against a) is to express will without
                                              evidence of necessity or opportunity for justification.
                                              
                                              Finally, as others have said, I think this option is likely to be moot -
                                              let's not act defensively out of SEGWIT trauma, but with trust in the
                                              network.
                                              
                                              Best,
                                              Ben
                                              
                                              On Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev <
                                              bitcoin-dev@lists•linuxfoundation.org> wrote:
                                              
                                              > I wanted to follow up on what Jeremy and others are saying regards finding
                                              > consensus on LOT. I've seen a few other opinions saying that finding
                                              > consensus on the LOT value is far more important than what the LOT value
                                              > actually is. This makes sense because if 100% of economic activity is
                                              > running the same rule set, there is no divergence, regardless of which
                                              > value is picked.
                                              >
                                              > It is my understanding that those who oppose LOT=true are mostly opposed
                                              > on the grounds of it *appearing* "unnecessarily coercive" and that this
                                              > lack of consensus can precipitate a chain split at the
                                              > "brinksmanship period" as Jeremy refers to it. I don't think that we can
                                              > say that LOT=true is coercive at all unless there is some opposition to
                                              > Taproot itself. Opposition on the grounds that it *may* be opposed by
                                              > others and Core does not want to assert control over the protocol is a
                                              > conservative view but ultimately contingent upon opposition to Taproot for
                                              > more fundamental reasons. If no one opposes it, then by definition you have
                                              > consensus, and in that case I also don't think that the LOT=true (or false)
                                              > in that regard sets meaningful precedent, as I would expect precedents to
                                              > only be meaningful if they were established during a contentious scenario.
                                              > As it stands we have precedents for both MASF's and UASF's to execute soft
                                              > forks in Bitcoin.
                                              >
                                              > Of course it seems intractable to ascertain the views of ~100% of the
                                              > Bitcoin constituency, and therefore it gives credibility to the argument
                                              > that by coming to consensus on LOT=false among those who *are* speaking
                                              > up is safer with the embedded assumptions that modifying consensus beyond
                                              > what core ships is an active choice, presumably by those who know what they
                                              > are doing. However, the simple act of Core choosing to ship an
                                              > unconfigurable LOT=false value does not *prevent* the forking and
                                              > creation of a UASF client. As Jeremy points out, the LOT=true possibility
                                              > always exists here, and we have multiple high profile people saying they
                                              > will be running that regardless of how things turn out. It seems to me that
                                              > in this scenario, LOT=false does less to prevent a chain split.
                                              >
                                              > In regards to precedent, there may be good reasons to force that minority
                                              > to fork themselves off the network, as would be the case if a hypothetical
                                              > soft fork was a consensus action to blacklist some UTXO's or something else
                                              > that weaponizes consensus against some subset of Bitcoin's user base, but I
                                              > haven't heard a single person who advocates for LOT=false on the grounds
                                              > that they *themselves* oppose the consensus change that is being proposed
                                              > here. So if the goal is to prevent a chain split, and the soft fork is
                                              > benign and essentially "annexing unoccupied territory" with respect to
                                              > script versions, and no one actually has opposed Taproot itself, then I
                                              > fail to see how LOT=false is safer in the presence of a grenade defense by
                                              > the LOT=true crowd.
                                              >
                                              > I personally *prefer* LOT=true for these reasons, but I am NOT going to
                                              > be joining the ranks of the intolerant minority if Core ultimately ships
                                              > LOT=false. I think it is more important to stay in consensus, and as a
                                              > result I am able to be convinced that false is the right answer. My
                                              > question to everyone else (true AND false advocates) is this: what would
                                              > you have to observe, in order to change your mind or is it immutably made
                                              > up? If we have a significant portion of the community that is immutably
                                              > made up to go false, and another portion that is going to go true, the
                                              > asymmetry of the fork almost *requires* that those of us whose opinions
                                              > are malleable to break for true.
                                              >
                                              > If social consensus is what drives technical consensus and not the other
                                              > way around it seems as if there cannot exist a valid (rational?) reason to
                                              > oppose Taproot itself, and then by extension with the arguments laid out
                                              > above, LOT=true seems to be the logical conclusion of all of this, even if
                                              > Core ships LOT=false at the outset.
                                              >
                                              > Where am I wrong here?
                                              >
                                              > Keagan
                                              >
                                              > On Mon, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev <
                                              > bitcoin-dev@lists•linuxfoundation.org> wrote:
                                              >
                                              >> Not responding to anyone in particular, but it strikes me that one can
                                              >> think about the case where a small minority (let's say H = 20%?) of nodes
                                              >> select the opposite of what Core releases (LOT=false, LOT=true). I'm
                                              >> ignoring the case where a critical bug is discovered in Taproot for reasons
                                              >> I could expand on if anyone is interested (I don't think LOT=true/false has
                                              >> much of a diff in that regard).
                                              >>
                                              >> You'll note an asymmetry with LOT=true / false analysis. LOT=true nodes
                                              >> are clearly updated (or lying), LOT=false nodes may be un-upgraded (or
                                              >> however you want to interpret it).
                                              >>
                                              >>
                                              >> *# 80% on LOT=false, 20% LOT=True*
                                              >>
                                              >> - Case 1: Activates ahead of time anyways
                                              >>
                                              >> No issues.
                                              >>
                                              >> - Case 2: Fails to Activate before timeout...
                                              >>
                                              >> 20% *may* fork off with LOT=true. Bitcoin hashrate reduced, chance of
                                              >> multi block reorgs at time of fork relatively high, especially if network
                                              >> does not partition.
                                              >>
                                              >> Implication is that activation % being 90%, then X% fewer than 70% of
                                              >> miners are signaling for Taproot at this time.  If X% is small the
                                              >> increased orphan rate caused by the LOT=true miners will cause it to
                                              >> activate anyways. If X% is larger, then there will be a consensus split.
                                              >>
                                              >>
                                              >>
                                              >> *# 80% on LOT=true, 20% LOT=False*
                                              >> - Case 1: Activates ahead of time Anyways
                                              >>
                                              >> No issues.
                                              >>
                                              >> - Case 2: Fails to Activate before timeout...
                                              >>
                                              >> A% + B% + C% = 20%
                                              >>
                                              >> A% (upgraded, signal activate) remain on majority chain with LOT=false,
                                              >> blocks mined universally valid.
                                              >>
                                              >> B% (upgraded, not signaling) succeeds in activating and maintaining
                                              >> consensus, blocks are temporarily lost during the final period, but
                                              >> consensus re-emerges.
                                              >>
                                              >> C% (not upgraded/not signalling) both fail to activate (not upgraded) and
                                              >> blocks are rejected (not signaling) during mandatory signalling.
                                              >> Essentially becomes an SPV miner, should still not select transactions
                                              >> improperly given mempool policy, but may mine a bad tip.
                                              >>
                                              >> (I argue that group B is irrational entirely, as in this case the
                                              >> majority has upgraded, inevitably winning, and is orphaning their blocks so
                                              >> B should effectively be 0% or can be combined with group C as being somehow
                                              >> not upgraded if they are unable to switch once it becomes clear after say
                                              >> the first 100 blocks in the period that LOT > 50%. The only difference in
                                              >> lumping B with C is that group C SPV mines after the fork and B should, in
                                              >> theory, have full validation.).
                                              >>
                                              >>
                                              >>
                                              >> Apologies if my base analysis is off -- happy to take corrections.
                                              >>
                                              >>
                                              >> My overall summary is thus:
                                              >>
                                              >> 1) People care what Core releases because we assume the majority will
                                              >> likely run it. If core were a minority project, we wouldn't really care
                                              >> what core released.
                                              >> 2) People are upset with LOT=true being suggested as release parameters
                                              >> because of the *narrative* that it puts devs in control.
                                              >> 3) LOT=true having a sizeable minority running it presents major issues
                                              >> to majority LOT=false in terms of lost blocks during the final period and
                                              >> in terms of a longer term fork.
                                              >> 4) Majority LOT=true has no long term instability on consensus (majority
                                              >> LOT=true means the final period always activates, any instability is short
                                              >> lived + irrational).
                                              >> 5) On the balance, the safer parameter to release *seems* to be LOT=true.
                                              >> But because devs are sensitive to control narrative, LOT=false is preferred
                                              >> by devs.
                                              >> 6) Almost paradoxically, choosing a *less safe* option for a narrative
                                              >> reason is more of a show of dev control than choosing a more safe option
                                              >> despite appearances.
                                              >> 7) This all comes down to if we think that a reasonable number of
                                              >> important nodes will run LOT=true.
                                              >> 8) This all doesn't matter *that much* because taproot will have many
                                              >> opportunities to activate before the brinksmanship period.
                                              >>
                                              >> As a plan of action, I think that means that either:
                                              >>
                                              >> A) Core should release LOT=true, as a less disruptive option given stated
                                              >> community intentions to do LOT=true
                                              >> B) Core  community should vehemently anti-advocate running LOT=true to
                                              >> ensure the % is as small as possible
                                              >> C) Do nothing
                                              >> D) Core community should release LOT=false and vehemently advocate
                                              >> manually changing to LOT=true to ensure the % is supermajority, but leaving
                                              >> it as a user choice.
                                              >>
                                              >>
                                              >> Overall, I worry that plan B has a mild Streissand effect and would
                                              >> result in boosting LOT=true (which could be OK, so long as LOT=true +
                                              >> LOT=false+signal yes becomes the large majority, but would be not fun for
                                              >> anyone if LOT=true + LOT=false+signal yes are a small majority). Plan C
                                              >> most likely ends up with some % doing LOT=true anyways. D feels a little
                                              >> silly, but maybe a good tradeoff.
                                              >>
                                              >> If I had to summarize the emotional dynamic among developers around
                                              >> LOT=true, I think devs wish it didn't exist because it is clear LOT=true
                                              >> *creates* the issues here. LOT=false would be fine if the LOT=true strategy
                                              >> didn't exist at all. But unfortunately the cat is out of the bag and cannot
                                              >> be put back in. To validate the emotions, I think it is fine to be angry
                                              >> about LOT=true and not like it, but we should either accept that it is most
                                              >> likely to create consensus OR we should find a new game theoretic
                                              >> activation strategy with better pro-social equilibriums.
                                              >>
                                              >> Personally, I think with either plan the ultimate risk of forking is low
                                              >> given probability to activate before timeout, so we should just pick
                                              >> something and move on, accepting that we aren't setting a precedent by
                                              >> which all future forks should abide. Given my understanding of the
                                              >> tradeoffs, I believe that the safest choice is LOT=true, but I wouldn't
                                              >> move to hold back a plan of LOT=false (but would probably take mitigative
                                              >> steps on community advocacy if it looks like there is non majority but non
                                              >> negligible LOT=true uptake).
                                              >>
                                              >> Cheers,
                                              >>
                                              >> Jeremy
                                              >>
                                              >>
                                              >> _______________________________________________
                                              >> bitcoin-dev mailing list
                                              >> bitcoin-dev@lists•linuxfoundation.org
                                              >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                                              >>
                                              > _______________________________________________
                                              > bitcoin-dev mailing list
                                              > bitcoin-dev@lists•linuxfoundation.org
                                              > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                                              >
                                              
                                              [-- Attachment #2: Type: text/html, Size: 20078 bytes --]
                                              
                                              ^ permalink raw reply	[flat|nested] 42+ messages in thread

                                            • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                                                2021-02-23 19:33                                           ` Keagan McClelland
                                                2021-02-23 23:14                                             ` Ben Woosley
                                              @ 2021-02-24 22:37                                             ` Ariel Luaces
                                                2021-03-01 13:54                                               ` Erik Aronesty
                                                1 sibling, 1 reply; 42+ messages in thread
                                              From: Ariel Luaces @ 2021-02-24 22:37 UTC (permalink / raw)
                                                To: Keagan McClelland, Bitcoin Protocol Discussion
                                              
                                              On Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev
                                              <bitcoin-dev@lists•linuxfoundation.org> wrote:
                                              >
                                              > If social consensus is what drives technical consensus and not the other way around it seems as if there cannot exist a valid (rational?) reason to oppose Taproot itself, and then by extension with the arguments laid out above, LOT=true seems to be the logical conclusion of all of this, even if Core ships LOT=false at the outset.
                                              >
                                              > Where am I wrong here?
                                              >
                                              > Keagan
                                              >
                                              > On Mon, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
                                              >>
                                              >> Personally, I think with either plan the ultimate risk of forking is low given probability to activate before timeout, so we should just pick something and move on, accepting that we aren't setting a precedent by which all future forks should abide. Given my understanding of the tradeoffs, I believe that the safest choice is LOT=true, but I wouldn't move to hold back a plan of LOT=false (but would probably take mitigative steps on community advocacy if it looks like there is non majority but non negligible LOT=true uptake).
                                              >>
                                              >> Cheers,
                                              >>
                                              >> Jeremy
                                              >>
                                              >>
                                              >> _______________________________________________
                                              >> bitcoin-dev mailing list
                                              >> bitcoin-dev@lists•linuxfoundation.org
                                              >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                                              >
                                              > _______________________________________________
                                              > bitcoin-dev mailing list
                                              > bitcoin-dev@lists•linuxfoundation.org
                                              > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                                              
                                              To favor LOT=true because it seems like the inevitable result is like
                                              playing the prisoner's dilemma and never cooperating instead of using
                                              the most optimal strategy which is tit-for-tat (cooperating at first
                                              and then cheating once for every time your counterparty cheats).
                                              
                                              During segwit users started by cooperating (BIP9, or "LOT=false"),
                                              then a minority of
                                              miners didn't cooperate (small veto but remember the majority of
                                              miners cooperated), then users stopped cooperating in response (UASF),
                                              then miners
                                              reverted to cooperating (MASF while intolerant miners forked off).
                                              Today users should start cooperating again to continue using the
                                              optimal strategy.
                                              
                                              Cheers
                                              Ariel Lorenzo-Luaces
                                              
                                              
                                              ^ permalink raw reply	[flat|nested] 42+ messages in thread

                                            • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                                                  2021-02-24 22:37                                             ` Ariel Luaces
                                                @ 2021-03-01 13:54                                               ` Erik Aronesty
                                                  2021-03-02 18:32                                                 ` Ariel Lorenzo-Luaces
                                                  0 siblings, 1 reply; 42+ messages in thread
                                                From: Erik Aronesty @ 2021-03-01 13:54 UTC (permalink / raw)
                                                  To: Ariel Luaces, Bitcoin Protocol Discussion
                                                
                                                > Today users should start cooperating again to continue using the
                                                > optimal strategy.
                                                
                                                the "gradual" method of reducing the % of miners required for lock-in
                                                as time goes on seems to encode this optimal strategy.
                                                
                                                On Thu, Feb 25, 2021 at 6:43 AM Ariel Luaces via bitcoin-dev
                                                <bitcoin-dev@lists•linuxfoundation.org> wrote:
                                                >
                                                > On Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev
                                                > <bitcoin-dev@lists•linuxfoundation.org> wrote:
                                                > >
                                                > > If social consensus is what drives technical consensus and not the other way around it seems as if there cannot exist a valid (rational?) reason to oppose Taproot itself, and then by extension with the arguments laid out above, LOT=true seems to be the logical conclusion of all of this, even if Core ships LOT=false at the outset.
                                                > >
                                                > > Where am I wrong here?
                                                > >
                                                > > Keagan
                                                > >
                                                > > On Mon, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
                                                > >>
                                                > >> Personally, I think with either plan the ultimate risk of forking is low given probability to activate before timeout, so we should just pick something and move on, accepting that we aren't setting a precedent by which all future forks should abide. Given my understanding of the tradeoffs, I believe that the safest choice is LOT=true, but I wouldn't move to hold back a plan of LOT=false (but would probably take mitigative steps on community advocacy if it looks like there is non majority but non negligible LOT=true uptake).
                                                > >>
                                                > >> Cheers,
                                                > >>
                                                > >> Jeremy
                                                > >>
                                                > >>
                                                > >> _______________________________________________
                                                > >> bitcoin-dev mailing list
                                                > >> bitcoin-dev@lists•linuxfoundation.org
                                                > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                                                > >
                                                > > _______________________________________________
                                                > > bitcoin-dev mailing list
                                                > > bitcoin-dev@lists•linuxfoundation.org
                                                > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                                                >
                                                > To favor LOT=true because it seems like the inevitable result is like
                                                > playing the prisoner's dilemma and never cooperating instead of using
                                                > the most optimal strategy which is tit-for-tat (cooperating at first
                                                > and then cheating once for every time your counterparty cheats).
                                                >
                                                > During segwit users started by cooperating (BIP9, or "LOT=false"),
                                                > then a minority of
                                                > miners didn't cooperate (small veto but remember the majority of
                                                > miners cooperated), then users stopped cooperating in response (UASF),
                                                > then miners
                                                > reverted to cooperating (MASF while intolerant miners forked off).
                                                > Today users should start cooperating again to continue using the
                                                > optimal strategy.
                                                >
                                                > Cheers
                                                > Ariel Lorenzo-Luaces
                                                > _______________________________________________
                                                > bitcoin-dev mailing list
                                                > bitcoin-dev@lists•linuxfoundation.org
                                                > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                                                
                                                
                                                ^ permalink raw reply	[flat|nested] 42+ messages in thread

                                              • • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                                                    2021-03-01 13:54                                               ` Erik Aronesty
                                                  @ 2021-03-02 18:32                                                 ` Ariel Lorenzo-Luaces
                                                    0 siblings, 0 replies; 42+ messages in thread
                                                  From: Ariel Lorenzo-Luaces @ 2021-03-02 18:32 UTC (permalink / raw)
                                                    To: Erik Aronesty; +Cc: Bitcoin Protocol Discussion
                                                  
                                                  [-- Attachment #1: Type: text/plain, Size: 3560 bytes --]
                                                  
                                                  I agree.
                                                  
                                                  Thank you Erik for proposing it. It's a pretty good idea.
                                                  
                                                  P.S. I wouldn't want a chain split of a low percentage of users though. The minority will be at the mercy of massive PoW swings and the chain will lose friends so it's not good for anyone. I recommend changing the final percentage to %50 because that's the hurdle where non-upgraded users *must* activate to avoid the risk of being reorged. The number of running users will quickly jump to 90%+ if it ever gets near 50%.
                                                  
                                                  Cheers
                                                  Ariel Lorenzo-Luaces
                                                  
                                                  
                                                  
                                                  On Mar 1, 2021, 5:54 AM, at 5:54 AM, Erik Aronesty <erik@q32•com> wrote:
                                                  >> Today users should start cooperating again to continue using the
                                                  >> optimal strategy.
                                                  >
                                                  >the "gradual" method of reducing the % of miners required for lock-in
                                                  >as time goes on seems to encode this optimal strategy.
                                                  >
                                                  >On Thu, Feb 25, 2021 at 6:43 AM Ariel Luaces via bitcoin-dev
                                                  ><bitcoin-dev@lists•linuxfoundation.org> wrote:
                                                  >>
                                                  >> On Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev
                                                  >> <bitcoin-dev@lists•linuxfoundation.org> wrote:
                                                  >> >
                                                  >> > If social consensus is what drives technical consensus and not the
                                                  >other way around it seems as if there cannot exist a valid (rational?)
                                                  >reason to oppose Taproot itself, and then by extension with the
                                                  >arguments laid out above, LOT=true seems to be the logical conclusion
                                                  >of all of this, even if Core ships LOT=false at the outset.
                                                  >> >
                                                  >> > Where am I wrong here?
                                                  >> >
                                                  >> > Keagan
                                                  >> >
                                                  >> > On Mon, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev
                                                  ><bitcoin-dev@lists•linuxfoundation.org> wrote:
                                                  >> >>
                                                  >> >> Personally, I think with either plan the ultimate risk of forking
                                                  >is low given probability to activate before timeout, so we should just
                                                  >pick something and move on, accepting that we aren't setting a
                                                  >precedent by which all future forks should abide. Given my
                                                  >understanding of the tradeoffs, I believe that the safest choice is
                                                  >LOT=true, but I wouldn't move to hold back a plan of LOT=false (but
                                                  >would probably take mitigative steps on community advocacy if it looks
                                                  >like there is non majority but non negligible LOT=true uptake).
                                                  >> >>
                                                  >> >> Cheers,
                                                  >> >>
                                                  >> >> Jeremy
                                                  >> >>
                                                  >> >>
                                                  >> >> _______________________________________________
                                                  >> >> bitcoin-dev mailing list
                                                  >> >> bitcoin-dev@lists•linuxfoundation.org
                                                  >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                                                  >> >
                                                  >> > _______________________________________________
                                                  >> > bitcoin-dev mailing list
                                                  >> > bitcoin-dev@lists•linuxfoundation.org
                                                  >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                                                  >>
                                                  >> To favor LOT=true because it seems like the inevitable result is like
                                                  >> playing the prisoner's dilemma and never cooperating instead of using
                                                  >> the most optimal strategy which is tit-for-tat (cooperating at first
                                                  >> and then cheating once for every time your counterparty cheats).
                                                  >>
                                                  >> During segwit users started by cooperating (BIP9, or "LOT=false"),
                                                  >> then a minority of
                                                  >> miners didn't cooperate (small veto but remember the majority of
                                                  >> miners cooperated), then users stopped cooperating in response
                                                  >(UASF),
                                                  >> then miners
                                                  >> reverted to cooperating (MASF while intolerant miners forked off).
                                                  >> Today users should start cooperating again to continue using the
                                                  >> optimal strategy.
                                                  >>
                                                  >> Cheers
                                                  >> Ariel Lorenzo-Luaces
                                                  >> _______________________________________________
                                                  >> bitcoin-dev mailing list
                                                  >> bitcoin-dev@lists•linuxfoundation.org
                                                  >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                                                  
                                                  [-- Attachment #2: Type: text/html, Size: 4537 bytes --]
                                                  
                                                  ^ permalink raw reply	[flat|nested] 42+ messages in thread

                                          • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
                                              2021-02-23  2:10                                         ` Jeremy
                                              2021-02-23 19:33                                           ` Keagan McClelland
                                            @ 2021-02-24  7:18                                           ` Anthony Towns
                                              1 sibling, 0 replies; 42+ messages in thread
                                            From: Anthony Towns @ 2021-02-24  7:18 UTC (permalink / raw)
                                              To: Jeremy, Bitcoin Protocol Discussion
                                            
                                            On Mon, Feb 22, 2021 at 06:10:34PM -0800, Jeremy via bitcoin-dev wrote:
                                            > Not responding to anyone in particular, but it strikes me that one can think
                                            > about the case where a small minority (let's say H = 20%?) of nodes
                                            
                                            I don't think that's a good way to try to look at things -- number of
                                            nodes has some impacts, but they're relatively minor (pun deflected).
                                            
                                            I think the things to look at are (from most to least important):
                                            
                                             (1) what the price indicates / what people buying/selling BTC want
                                             (2) what hashpower does
                                             (3) what nodes do
                                            
                                            Here's a concrete example to help justify that ordering. Suppose
                                            that for whatever reason nobody is particularly interested in running
                                            lockinontimeout=true -- only 0.1% of nodes are doing it and they're not
                                            the "economic majority" in any way. In addition, 15% of hashpower have
                                            spent almost the entire signalling period not bothering to upgrade and
                                            thus haven't been signalling and have been blocking activation.
                                            
                                            Suppose further that there are futures/prediction markets setup so that
                                            people can bet on taproot activation (eg the bitfinex chain split tokens,
                                            or some sort of DeFi contracts), and the result is that there's some
                                            decent profits to be made if it does activate, enough to tempt >55%
                                            of hashpower into running with lockinontimeout=true. That way those
                                            miners can be confident it will activate, take up contracts in the
                                            futures/predictions markets, and be confident they'll win and get a
                                            big payday. (Note that this means the people on the other side of those
                                            contracts are betting that taproot *doesn't* activate)
                                            
                                            Once a majority of hashpower is running lockinontimeout=true, it then
                                            makes sense for the remaining hashpower to both signal for activation
                                            and also run lockinontimeout=true -- otherwise they risk their blocks
                                            being orphaned if too many blocks don't signal, and they build on top
                                            of one.  Figuring out that a majority of hashpower is/will be running
                                            lockinontimeout=true can be done either by a coinbase message or by
                                            bip91-style signalling.
                                            
                                            In that scenario, you end up with >90% of hashpower running with
                                            lockinontimeout=true, even if only a token number of nodes in the wild
                                            are doing the same.
                                            
                                            
                                            
                                            It's possible to do estimates of what happens if a majority of miners
                                            are using lockinontimeout=true, and the numbers end up pretty wild.
                                            
                                            With 90% of miners signalling and running lockinontimeout=true, if the
                                            remaining 10% don't signal, they can expect to lose around 3% of revenue
                                            ($2M) due to blocks getting orphaned. If the numbers are 85% running
                                            lockinontimeout=true, and 15% not signalling, the non-signallers can
                                            expect to lose about 37% of revenue ($38M) during the retarget period
                                            prior to timeout. If 60% of miners are doing spy-mining for up to 90s,
                                            they would expect to lose 0.9% of their spy-mining revenue ($2.5M). If
                                            60% of hashpower is running lockinontimeout=true, while 40% don't
                                            signal, the non-signallers will forego ~83% of revenue ($320M) due to
                                            their blocks being orphaned, and if 60% of miners spy-mine for 90s, they
                                            should expect to lose 5% of revenue ($10M) over the same period. Dollar
                                            figures based on 6.25BTC/block at $50k per BTC.
                                            
                                            https://gist.github.com/ajtowns/fbcf30ed9d0e1708fdc98a876a04ff69#file-forced_signalling_chaos_cost_sim-py
                                            
                                            Note that if miners simply accept those losses and don't take any
                                            action to prevent it, very long reorgs are to be expected -- in the 15%
                                            non-signalling scenario, you'd expect to see a 5-block reorg; in the 40%
                                            non-signalling scenario, you'd get reorgs of 60+ blocks. (Only people
                                            not running lockinontimeout=true would see the blocks being reorged out,
                                            of course)
                                            
                                            
                                            So I think focussing on how many nodes have a particular lockinontimeout
                                            setting can be pretty misleading.
                                            
                                            > # 80% on LOT=false, 20% LOT=True
                                            > - Case 1: Activates ahead of time anyways
                                            
                                            That's the case where >90% of hashpower is signalling, and everything
                                            works fine.
                                            
                                            > - Case 2: Fails to Activate before timeout...
                                            > 20% *may* fork off with LOT=true.
                                            
                                            Anyone running with lockinontimeout=true will refuse to follow a chain
                                            where lockin hasn't been reached by the timeout height; so if the most
                                            work chain meets that condition, lockinontimeout=true nodes will refuse
                                            to follow it; either getting stuck with no confirmations at all, or
                                            following a lower work chain that does (or can) reach lockin by timeout
                                            height.
                                            
                                            > Bitcoin hashrate reduced, chance of multi
                                            > block reorgs at time of fork relatively high, especially if network does not
                                            > partition.
                                            
                                            If the most-work chain fails to activate, and only a minority of
                                            hashrate is running lockinontimeout=true, the chance of multiblock
                                            reorgs is actually pretty low. The way it would play out in detail,
                                            with say 20% of hashpower not signalling and 40% of hashpower running
                                            lockinontimeout=true:
                                            
                                              * the chain reaches the last retarget period; lockinontimeout=false
                                                nodes stay in STARTED, lockinontimeout=true nodes switch to
                                                MUST_SIGNAL
                                            
                                              * for the first ~1009 blocks, everyone stays in sync, but block ~1010
                                                becomes the 202nd non-signalling block, meaning that the 60% of
                                                hashpower on lockinontimeout=false is now one block ahead of the 40%
                                                of hashpower on lockinontimeout=true
                                            
                                              * it's possible that the 40% have a lucky run and get ahead of the 60%
                                                chain causing a reorg. But in that case the within about 5 blocks,
                                                another non-signalling block will be mined and the 60% will be ahead
                                                again. So the 40% of lockinontimeout=true hashpower has to keep with
                                                with miners that have 150% of their hashrate for ~1000 blocks in
                                                order for everyone to end up on a locked in chain, which is
                                                vanishingly unlike.
                                            
                                            Even if you set the percentage not signalling to 11% and the percent of
                                            hashpower running lockinontimeout=true to 48%, by my count you only get
                                            about a 27% chance of ending up reaching lockin on the most work chain.
                                            With the 40%/20% figures above it's a flat 0.0%.
                                            
                                            https://gist.github.com/ajtowns/fbcf30ed9d0e1708fdc98a876a04ff69#file-test_disaster-py
                                            
                                            It's possible that the 60% will take some action to prevent their blocks
                                            being reorged out if the 40% do get lucky. One option would be for them
                                            to set lockinontimeout=true -- then we quickly get back to the "almost
                                            all hashpower ends up running lockinontimeout=true" and activation is
                                            certain. But they could just as easily decide that one getblockchaininfo
                                            reports a softfork isn't possible, they won't reorg to a chain where it
                                            is possible unless it's 2 or 4 or 6 or whatever blocks longer.
                                            
                                            > # 80% on LOT=true, 20% LOT=False
                                            > - Case 1: Activates ahead of time Anyways
                                            > No issues.
                                            
                                            This is same case where there's plenty of signalling and it's irrelevant
                                            what the setting for lockinontimeout is...
                                            
                                            > - Case 2: Fails to Activate before timeout...
                                            
                                            I'm not sure what you mean by "before timeout" here -- if you mean
                                            it reaches the MUST_SIGNAL phase, with 80% of hashpower running
                                            lockinontimeout=true, then things work out okay: even assuming that all
                                            20% that are not running lockinontimeout=true are also not signalling,
                                            then the miners who don't signal will lose up to 56% of their revenue for
                                            the MUST_SIGNAL period (~$80M) , and if some of the lockinontimeout=true
                                            miners do spy-mining and build on top of non-signalling blocks, they
                                            may lose something like 1.7% of their revenue as well. In addition we
                                            might see reorgs of up to ~10 blocks as this resolves itself. That's a
                                            significant loss for the miners who are out of consensus, and the
                                            liklihood of large reorgs will make doing business with bitcoin harder,
                                            but that at least is all able to be coped with.
                                            
                                            But if you mean the most work chain reaches the timeout height without
                                            achieving locked in state, because the majority of miners aren't running
                                            lockinontimeout=true, then the 80% of nodes running lockinontimeout=true
                                            will be stalled, and unable to process transactions, until they downgrade.
                                            
                                            If that ever occurred, it would be an astounding disaster, and I hope
                                            the first thing people would do is decide never to run any software by
                                            whoever proposed, ACKed or merged the PR that resulted in 80% of nodes
                                            running with lockinontimeout=true.
                                            
                                            *Because* it would be such a disaster to effectively run a
                                            denial-of-service attack on 80% of nodes, it's plausible that price
                                            signals would indicate to miners that it will be much more profitable to
                                            run lockinontimeout=true, preventing that from occuring. But people can
                                            make profits out of disasters too -- it might be that people will figure
                                            "oh, the price will crash if this happens, so it'll be a chance to get
                                            some cheap bitcoins, and maybe put competing miners out of business so
                                            I can buy their ASICs off them for cheap too!"
                                            
                                            > My overall summary is thus:
                                            > 1) People care what Core releases because we assume the majority will likely
                                            > run it. If core were a minority project, we wouldn't really care what core
                                            > released.
                                            
                                            That seems very backwards to me. I'd put it as: people run core because
                                            it makes good, conservative decisions on what features to add. If
                                            "choose your own consensus rules" were what the market wanted, then
                                            Bitcoin Unlimited or similar would be what everyone was running.
                                            
                                            If core were to change that policy and push risky changes, I'd hope
                                            that users would be able to recognise this, and would switch to an
                                            implementation that continues to emphasise safe, conservative policies.
                                            
                                            > 2) People are upset with LOT=true being suggested as release parameters because
                                            > of the narrative that it puts devs in control.
                                            
                                            If users will just run whatever core devs release, even if it involves
                                            contentious changes to consensus rules, then the core devs are in control.
                                            
                                            > 3) LOT=true having a sizeable minority running it presents major issues to
                                            > majority LOT=false in terms of lost blocks during the final period and in terms
                                            > of a longer term fork.
                                            
                                            As above, I think this scenario is easy to avoid if it were to
                                            eventuate.
                                            
                                            > 4) Majority LOT=true has no long term instability on consensus (majority LOT=
                                            > true means the final period always activates, any instability is short lived +
                                            > irrational).
                                            
                                            The instability occurs if the lockinontimeout=true chain stalls or is
                                            overtaken by a more-work non-activating chain, then users running nodes
                                            with that parameter set will stop their nodes, and reinstall/reconfigure
                                            it to set lockinontimeout=false.
                                            
                                            > 5) On the balance, the safer parameter to release *seems* to be LOT=true. But
                                            > because devs are sensitive to control narrative, LOT=false is preferred by
                                            > devs.
                                            
                                            I think that conclusion is based on a few shakey assumptions; particularly
                                            that people won't downgrade/reinstall back to lockinontimeout=false
                                            and that miners will be be pretty naive about allowing their blocks to
                                            be orphaned.
                                            
                                            > 6) Almost paradoxically, choosing a less safe option for a narrative reason is
                                            > more of a show of dev control than choosing a more safe option despite
                                            > appearances.
                                            
                                            Going all-in on a bluff can be a good bet 9 times out of 10, while still
                                            being a net negative because of the 1 time out of 10 when you lose. In
                                            the examples above, the "80% of nodes running the default client can no
                                            longer follow the blockchain without manual intervention" is the "lose
                                            it all scenario", even if "taproot" is probably one of the 9/10 cases,
                                            not the 1/10 case.
                                            
                                            > 7) This all comes down to if we think that a reasonable number of important
                                            > nodes will run LOT=true.
                                            
                                            What nodes run (as compared to hashpower, or as compared to what people
                                            want to buy/sell) is the least important factor in working out what's
                                            going to happen.
                                            
                                            > As a plan of action, I think that means that either:
                                            > A) Core should release LOT=true, as a less disruptive option given stated
                                            > community intentions to do LOT=true
                                            > B) Core  community should vehemently anti-advocate running LOT=true to ensure
                                            > the % is as small as possible
                                            > C) Do nothing
                                            > D) Core community should release LOT=false and vehemently advocate manually
                                            > changing to LOT=true to ensure the % is supermajority, but leaving it as a user
                                            > choice.
                                            
                                            I think these are all a bit terrible as plans of action -- "core should
                                            release X, then advocate Y" is really not playing to core's strengths.
                                            Far better for devs to focus on writing/debugging code, analysing the
                                            way things work, making tests, and adding mitigations for risks.
                                            
                                            Better for bloggers and podcasters and the twitterati to do the advocacy,
                                            and core to stick to working on code and saying "no, there are significant
                                            technical risks to doing that that we don't yet have mitigations for"
                                            when people advocate for risky things.
                                            
                                            My view is more along the lines of:
                                            
                                             - the setting for lockinontimeout will not matter until around July 2022,
                                               (though maybe as early as May 2022 if blocks come really fast) either
                                               technically or even as a game theory incentive
                                            
                                             - lockinontimeout=true has consensus implications, and depending on
                                               the response by miners can cause network interruptions like long
                                               chains of reorgs. At best, it hasn't had the same level of review as
                                               taproot, and some experienced developers aren't comfortable with it
                                               as it stands. Those seem like pretty good reasons not to deploy it
                                               immediately, IMO.
                                            
                                             - the lockinontimeout=true code we've got doesn't do (at least) two
                                               things that the bip148 client did that help avoid bad cases:
                                                 - ensure preferential connections to other nodes setting
                                                   lockinontimeout=true to prevent network splits if the
                                                   non-activating chain is longer during/after the MUST_SIGNAL phase
                                                 - cope with rewinding the chain to the best lockinontimeout=true valid
                                                   block, in the event a node is upgraded to lockinontimeout=true
                                                   from either lockinontimeout=false or a version of bitcoind that
                                                   doesn't have activation parameters set at all
                                            
                                            I think it makes more sense to:
                                            
                                             1) release lockinontimeout=false code with a view to reconsidering it
                                                at about ~6 months (so prior to the 23.0 release)
                                            
                                             2) do more review of lockinontimeout=true code to ensure everyone
                                                understands what behaviours are likely
                                            
                                             3) add support for the features from the bip148 client, along with
                                                any other mitigations we think of, assuming we can do so in a way
                                                that's safe and sane
                                            
                                             4) work with miners and mining pools to ensure that if
                                                lockinontimeout=true does get used they know how to minimise
                                                disruption and losses due to orphaning, etc.
                                            
                                            That gives us about 6 months work on (2) and (3), and probably 9-12
                                            months to work on (4), and it's all technical rather than advocacy and
                                            popularity contests. Six, nine or twelve months should be plenty of time
                                            to get pretty clear indications of what both the market in general
                                            thinks about things, and what miners are thinking.
                                            
                                            I think if lockinontimeout=true weren't new code, and devs, miners and
                                            users widely understood its potential behaviours and risks, and we didn't
                                            have safety features that were still on the todo list, then there'd be
                                            a good argument for doing lockinontimeout=true from day 1. I could see
                                            that being the case for the next soft-fork, assuming it gets a similar
                                            amount of review prior to deployment as taproot has had, eg. But, to me,
                                            taking a more cautious approach seems more sensible today.
                                            
                                            > If I had to summarize the emotional dynamic among developers [...]
                                            
                                            (Fortunately, you don't have to do that...)
                                            
                                            Cheers,
                                            aj
                                            
                                            
                                            
                                            ^ permalink raw reply	[flat|nested] 42+ messages in thread

        • * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
            2021-02-18 11:52       ` ZmnSCPxj
            2021-02-18 12:20         ` Michael Folkson
          @ 2021-02-18 13:59         ` Matt Corallo
            1 sibling, 0 replies; 42+ messages in thread
          From: Matt Corallo @ 2021-02-18 13:59 UTC (permalink / raw)
            To: ZmnSCPxj, Bitcoin Protocol Discussion; +Cc: Michael Folkson
          
          Bitcoin is a consensus system. Please let’s not jump to (or even consider) options that discourage consensus. We all laughed at (and later academics researched showed severe deficiencies in) Bitcoin XT’s “emergent consensus” nonsense, why should we start doing things along that line in Bitcoin?
          
          (Resent from the correct email)
          
          Matt
          
          > On Feb 18, 2021, at 06:52, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
          > 
          > Good morning all,
          > 
          >> "An activation mechanism is a consensus change like any other change, can be contentious like any other change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline."
          >> 
          >> Who's we here?
          >> 
          >> Release both and let the network decide.
          > 
          > A thing that could be done, without mandating either LOT=true or LOT=false, would be to have a release that requires a `taprootlot=1` or `taprootlot=0` and refuses to start if the parameter is not set.
          > 
          > This assures everyone that neither choice is being forced on users, and instead what is being forced on users, is for users to make that choice themselves.
          > 
          > Regards,
          > ZmnSCPxj
          > 
          >> 
          >>> On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
          >>> 
          >>> Thanks for your response Ariel. It would be useful if you responded to specific points I have made in the mailing list post or at least quote these ephemeral "people" you speak of. I don't know if you're responding to conversation on the IRC channel or on social media etc.
          >>> 
          >>>> The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted into code. But in fact this isn't true and some voices in this discussion need to be more humble about what users must or must not run.
          >>> 
          >>> I personally have never made this assumption. Of course users aren't forced to run any particular software version, quite the opposite. Defaults set in software versions matter though as many users won't change them.
          >>> 
          >>>> Does no one realize that it is a very possible outcome that if LOT=true is released there may be only a handful of people that begin running it while everyone else delays their upgrade (with the very good reason of not getting involved in politics) and a year later those handful of people just become stuck at the moment of MUST_SIGNAL, unable to mine new blocks?
          >>> 
          >>> It is a possible outcome but the likely outcome is that miners activate Taproot before LOT is even relevant. I think it is prudent to prepare for the unlikely but possible outcome that miners fail to activate and hence have this discussion now rather than be unprepared for that eventuality. If LOT is set to false in a software release there is the possibility (T2 in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html) of individuals or a proportion of the community changing LOT to true. In that sense setting LOT=false in a software release appears to be no more safe than LOT=true.
          >>> 
          >>>> The result: a wasted year of waiting and a minority of people who didn't want to be lenient with miners by default.
          >>> 
          >>> There is the (unlikely but possible) possibility of a wasted year if LOT is set to false and miners fail to activate. I'm not convinced by this perception that LOT=true is antagonistic to miners. I actually think it offers them clarity on what will happen over a year time period and removes the need for coordinated or uncoordinated community UASF efforts on top of LOT=false.
          >>> 
          >>>> An activation mechanism is a consensus change like any other change, can be contentious like any other change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
          >>> 
          >>> I don't know what you are recommending here to avoid "this darkest timeline". Open discussions have occurred and are continuing and in my mailing list post that you responded to **I recommended we propose LOT=false be set in protocol implementations such as Bitcoin Core**. I do think this apocalyptic language isn't particularly helpful. In an open consensus system discussion is healthy, we should prepare for bad or worst case scenarios in advance and doing so is not antagonistic or destructive. Mining pools have pledged support for Taproot but we don't build secure systems based on pledges of support, we build them to minimize trust in any human actors. We can be grateful that people like Alejandro have worked hard on taprootactivation.com (and this effort has informed the discussion) without taking pledges of support as cast iron guarantees.
          >>> 
          >>> TL;DR It sounds like you agree with my recommendation to set LOT=false in protocol implementations in my email :)
          >>> 
          >>>> On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <arielluaces@gmail•com> wrote:
          >>> 
          >>>> Something what strikes me about the conversation is the emotion surrounding the letters UASF.
          >>>> It appears as if people discuss UASF as if it's a massive tidal wave of support that is inevitable, like we saw during segwit activation. But the actual definition is "any activation that is not a MASF".
          >>>> A UASF can consist of a single node, ten nodes, a thousand, half of all nodes, all business' nodes, or even all the non mining nodes. On another dimension it can have zero mining support, 51% support, 49% support, or any support right up against a miner activation threshold.
          >>>> Hell a UASF doesn't even need code or even a single node running as long as it exists as a possibility in people's minds.
          >>>> The only thing a UASF doesn't have is miner support above an agreed activation threshold (some number above %51).
          >>>> I say this because it strikes me when people say that they are for LOT=true with the logic that since a UASF is guaranteed to happen then it's better to just make it default from the beginning. Words like coordination and safety are sometimes sprinkled into the argument.
          >>>> The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted into code. But in fact this isn't true and some voices in this discussion need to be more humble about what users must or must not run.
          >>>> Does no one realize that it is a very possible outcome that if LOT=true is released there may be only a handful of people that begin running it while everyone else delays their upgrade (with the very good reason of not getting involved in politics) and a year later those handful of people just become stuck at the moment of MUST_SIGNAL, unable to mine new blocks? Or attracting a minority of miners, activating, and forking off into a minority fork. Then a lot=false could be started that ends up activating the feature now that the stubborn option has ran its course.
          >>>> The result: a wasted year of waiting and a minority of people who didn't want to be lenient with miners by default. The chains could be called BitcoinLenient and BitcoinStubborn.
          >>>> How is that strictly safer or more coordinated?
          >>>> I may be in the minority, or maybe a silent majority, or maybe a majority that just hasn't considered this as a choice but honestly if there is contention about whether we're going to be stubborn or lenient with miners for Taproot and in the future then I prefer to just not activate anything at all. I'm fine for calling bitcoin ossified, accepting that segwit is Bitcoin's last network upgrade. Taproot is amazing but no new feature is worth a network split down the middle.
          >>>> Maybe in 10 or 20 years, when other blockchains implement features like Taproot and many more, we will become envious enough to put aside our differences on how to behave towards miners and finally activate Taproot.
          >>>> An activation mechanism is a consensus change like any other change, can be contentious like any other change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
          >>>> Cheers
          >>>> Ariel Lorenzo-Luaces
          >>>> On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
          >>>> 
          >>>>> Yesterday (February 16th) we held a second meeting on Taproot
          >>>>> activation on IRC which again was open to all. Despite what appeared
          >>>>> to be majority support for LOT=false over LOT=true in the first
          >>>>> meeting I (and others) thought the arguments had not been explored in
          >>>>> depth and that we should have a follow up meeting almost entirely
          >>>>> focused on whether LOT (lockinontimeout) should be set to true or
          >>>>> false.
          >>>>> 
          >>>>> The meeting was announced here:
          >>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
          >>>>> 
          >>>>> In that mailing list post I outlined the arguments for LOT=true (T1 to
          >>>>> T6) and arguments for LOT=false (F1 to F6) in their strongest form I
          >>>>> could. David Harding responded with an additional argument for
          >>>>> LOT=false (F7) here:
          >>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
          >>>>> 
          >>>>> These meetings are very challenging given they are open to all, you
          >>>>> don’t know who will attend and you don’t know most people’s views in
          >>>>> advance. I tried to give time for both the LOT=true arguments and the
          >>>>> LOT=false arguments to be discussed as I knew there was support for
          >>>>> both. We only tried evaluating which had more support and which had
          >>>>> more strong opposition towards the end of the meeting.
          >>>>> 
          >>>>> The conversation log is here:
          >>>>> http://gnusha.org/taproot-activation/2021-02-16.log
          >>>>> 
          >>>>> (If you are so inclined you can watch a video of the meeting here.
          >>>>> Thanks to the YouTube account “Bitcoin” for setting up the livestream:
          >>>>> https://www.youtube.com/watch?v=vpl5q1ovMLM)
          >>>>> 
          >>>>> A summary of the meeting was provided by Luke Dashjr on Mastodon here:
          >>>>> https://bitcoinhackers.org/@lukedashjr/105742918779234566
          >>>>> 
          >>>>> Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we
          >>>>> did manage to come to consensus on everything but LockinOnTimeout.
          >>>>> 
          >>>>> Activation height range: 693504-745920
          >>>>> 
          >>>>> MASF threshold: 1815/2016 blocks (90%)
          >>>>> 
          >>>>> Keep in mind only ~100 people showed for the meetings, hardly
          >>>>> representative of the entire community.
          >>>>> 
          >>>>> So, these details remain JUST a proposal for now.
          >>>>> 
          >>>>> It seems inevitable that there won't be consensus on LOT.
          >>>>> 
          >>>>> Everyone will have to choose for himself. :/
          >>>>> 
          >>>>> Personally I agree with most of this. I agree that there wasn’t
          >>>>> overwhelming consensus for either LOT=true or LOT=false. However, from
          >>>>> my perspective there was clearly more strong opposition (what would
          >>>>> usually be deemed a NACK in Bitcoin Core review terminology) from
          >>>>> Bitcoin Core contributors, Lightning developers and other community
          >>>>> members against LOT=true than there was for LOT=false. Andrew Chow
          >>>>> tried to summarize views from the meeting in this analysis:
          >>>>> https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
          >>>>> 
          >>>>> I am also aware of other current and previous Bitcoin Core
          >>>>> contributors and Lightning developers who didn’t attend the meeting in
          >>>>> person who are opposed to LOT=true. I don’t want to put them in the
          >>>>> spotlight for no reason but if you go through the conversation logs of
          >>>>> not only the meeting but the weeks of discussion prior to this meeting
          >>>>> you will see their views evaluated on the ##taproot-activation
          >>>>> channel. In addition, on taprootactivation.com some mining pools
          >>>>> expressed a preference for lot=false though I don’t know how strong
          >>>>> that preference was.
          >>>>> 
          >>>>> I am only one voice but it is my current assessment that if we are to
          >>>>> attempt to finalize Taproot activation parameters and propose them to
          >>>>> the community at this time our only option is to propose LOT=false.
          >>>>> Any further delay appears to me counterproductive in our collective
          >>>>> aim to get the Taproot soft fork activated as early as possible.
          >>>>> 
          >>>>> Obviously others are free to disagree with that assessment and
          >>>>> continue discussions but personally I will be attempting to avoid
          >>>>> those discussions unless prominent new information comes to light or
          >>>>> various specific individuals change their minds.
          >>>>> 
          >>>>> Next week we are planning a code review of the Bitcoin Core PR #19573
          >>>>> which was initially delayed because of this LOT discussion. As I’ve
          >>>>> said previously that will be loosely following the format of the
          >>>>> Bitcoin Core PR review club and will be lower level and more
          >>>>> technical. That is planned for Tuesday February 23rd at 19:00 UTC on
          >>>>> the IRC channel ##taproot-activation.
          >>>>> 
          >>>>> Thanks to the meeting participants (and those who joined the
          >>>>> discussion on the channel prior and post the meeting) for engaging
          >>>>> productively and in good faith.
          >>> 
          >>> --
          >>> Michael Folkson
          >>> Email: michaelfolkson@gmail•com
          >>> Keybase: michaelfolkson
          >>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
          >>> _______________________________________________
          >>> bitcoin-dev mailing list
          >>> bitcoin-dev@lists•linuxfoundation.org
          >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
          > 
          > 
          > _______________________________________________
          > bitcoin-dev mailing list
          > bitcoin-dev@lists•linuxfoundation.org
          > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
          
          
          ^ permalink raw reply	[flat|nested] 42+ messages in thread

• * Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
    2021-02-17 12:51 Michael Folkson
    2021-02-18  5:43 ` Ariel Lorenzo-Luaces
  @ 2021-02-21 16:21 ` Erik Aronesty
    1 sibling, 0 replies; 42+ messages in thread
  From: Erik Aronesty @ 2021-02-21 16:21 UTC (permalink / raw)
    To: Michael Folkson, Bitcoin Protocol Discussion
  
  [-- Attachment #1: Type: text/plain, Size: 5523 bytes --]
  
  I think the most important thing is that the configuration setting is
  advertised if somebody were to query the node for its capabilities.
  
  Is this the case?
  
  That way the default value isn't really the important thing.
  
  There are longstanding and well-known nodes, for example.  Community
  support and visibility for a UASF is the most important aspect.
  
  I looked over the threads and I don't think I saw the broadcast nature of
  this setting clearly discussed.
  
  
  
  
  
  On Wed, Feb 17, 2021, 10:10 AM Michael Folkson via bitcoin-dev <
  bitcoin-dev@lists•linuxfoundation.org> wrote:
  
  > Yesterday (February 16th) we held a second meeting on Taproot
  > activation on IRC which again was open to all. Despite what appeared
  > to be majority support for LOT=false over LOT=true in the first
  > meeting I (and others) thought the arguments had not been explored in
  > depth and that we should have a follow up meeting almost entirely
  > focused on whether LOT (lockinontimeout) should be set to true or
  > false.
  >
  > The meeting was announced here:
  >
  > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
  >
  > In that mailing list post I outlined the arguments for LOT=true (T1 to
  > T6) and arguments for LOT=false (F1 to F6) in their strongest form I
  > could. David Harding responded with an additional argument for
  > LOT=false (F7) here:
  >
  > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
  >
  > These meetings are very challenging given they are open to all, you
  > don’t know who will attend and you don’t know most people’s views in
  > advance. I tried to give time for both the LOT=true arguments and the
  > LOT=false arguments to be discussed as I knew there was support for
  > both. We only tried evaluating which had more support and which had
  > more strong opposition towards the end of the meeting.
  >
  > The conversation log is here:
  > http://gnusha.org/taproot-activation/2021-02-16.log
  >
  > (If you are so inclined you can watch a video of the meeting here.
  > Thanks to the YouTube account “Bitcoin” for setting up the livestream:
  > https://www.youtube.com/watch?v=vpl5q1ovMLM)
  >
  > A summary of the meeting was provided by Luke Dashjr on Mastodon here:
  > https://bitcoinhackers.org/@lukedashjr/105742918779234566
  >
  > Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we
  > did manage to come to consensus on everything but LockinOnTimeout.
  >
  > Activation height range: 693504-745920
  >
  > MASF threshold: 1815/2016 blocks (90%)
  >
  > Keep in mind only ~100 people showed for the meetings, hardly
  > representative of the entire community.
  >
  > So, these details remain JUST a proposal for now.
  >
  > It seems inevitable that there won't be consensus on LOT.
  >
  > Everyone will have to choose for himself. :/
  >
  > Personally I agree with most of this. I agree that there wasn’t
  > overwhelming consensus for either LOT=true or LOT=false. However, from
  > my perspective there was clearly more strong opposition (what would
  > usually be deemed a NACK in Bitcoin Core review terminology) from
  > Bitcoin Core contributors, Lightning developers and other community
  > members against LOT=true than there was for LOT=false. Andrew Chow
  > tried to summarize views from the meeting in this analysis:
  > https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
  >
  > I am also aware of other current and previous Bitcoin Core
  > contributors and Lightning developers who didn’t attend the meeting in
  > person who are opposed to LOT=true. I don’t want to put them in the
  > spotlight for no reason but if you go through the conversation logs of
  > not only the meeting but the weeks of discussion prior to this meeting
  > you will see their views evaluated on the ##taproot-activation
  > channel. In addition, on taprootactivation.com some mining pools
  > expressed a preference for lot=false though I don’t know how strong
  > that preference was.
  >
  > I am only one voice but it is my current assessment that if we are to
  > attempt to finalize Taproot activation parameters and propose them to
  > the community at this time our only option is to propose LOT=false.
  > Any further delay appears to me counterproductive in our collective
  > aim to get the Taproot soft fork activated as early as possible.
  >
  > Obviously others are free to disagree with that assessment and
  > continue discussions but personally I will be attempting to avoid
  > those discussions unless prominent new information comes to light or
  > various specific individuals change their minds.
  >
  > Next week we are planning a code review of the Bitcoin Core PR #19573
  > which was initially delayed because of this LOT discussion. As I’ve
  > said previously that will be loosely following the format of the
  > Bitcoin Core PR review club and will be lower level and more
  > technical. That is planned for Tuesday February 23rd at 19:00 UTC on
  > the IRC channel ##taproot-activation.
  >
  > Thanks to the meeting participants (and those who joined the
  > discussion on the channel prior and post the meeting) for engaging
  > productively and in good faith.
  >
  > --
  > Michael Folkson
  > Email: michaelfolkson@gmail•com
  > Keybase: michaelfolkson
  > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
  > _______________________________________________
  > bitcoin-dev mailing list
  > bitcoin-dev@lists•linuxfoundation.org
  > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
  >
  
  [-- Attachment #2: Type: text/html, Size: 7427 bytes --]
  
  ^ permalink raw reply	[flat|nested] 42+ messages in thread

end of thread, other threads:[~2021-03-02 18:32 UTC | newest]

Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-21 10:10 [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) Prayank
  -- strict thread matches above, loose matches on Subject: below --
2021-02-19 22:12 Matt Hill
2021-02-19 23:30 ` Matt Corallo
2021-02-19 23:42   ` Bryan Bishop
2021-02-17 12:51 Michael Folkson
2021-02-18  5:43 ` Ariel Lorenzo-Luaces
2021-02-18 11:01   ` Michael Folkson
2021-02-18 11:11     ` Samson Mow
2021-02-18 11:52       ` ZmnSCPxj
2021-02-18 12:20         ` Michael Folkson
2021-02-18 14:01           ` Matt Corallo
2021-02-18 14:26             ` Michael Folkson
2021-02-18 14:42               ` Matt Corallo
2021-02-18 14:51                 ` Michael Folkson
2021-02-18 14:53                   ` Matt Corallo
2021-02-18 15:01                     ` Matt Corallo
2021-02-18 15:04                 ` Keagan McClelland
2021-02-18 15:18                   ` Matt Corallo
2021-02-19  2:20                     ` Ariel Luaces
2021-02-19 11:30                     ` ZmnSCPxj
2021-02-19 12:05                       ` Adam Back
2021-02-19 14:13                         ` Matt Corallo
2021-02-19 17:48                           ` Matt Corallo
2021-02-20  2:55                             ` ZmnSCPxj
2021-02-20 17:20                               ` Ariel Lorenzo-Luaces
2021-02-21 14:30                                 ` Matt Corallo
2021-02-22  5:16                             ` Anthony Towns
2021-02-22  6:44                               ` Matt Corallo
2021-02-22 10:16                                 ` Anthony Towns
2021-02-22 14:00                                   ` Matt Corallo
2021-02-22 16:27                                     ` Anthony Towns
2021-02-22 16:31                                     ` Jorge Timón
2021-02-22 16:48                                       ` Jorge Timón
2021-02-23  2:10                                         ` Jeremy
2021-02-23 19:33                                           ` Keagan McClelland
2021-02-23 23:14                                             ` Ben Woosley
2021-02-24 22:37                                             ` Ariel Luaces
2021-03-01 13:54                                               ` Erik Aronesty
2021-03-02 18:32                                                 ` Ariel Lorenzo-Luaces
2021-02-24  7:18                                           ` Anthony Towns
2021-02-18 13:59         ` Matt Corallo
2021-02-21 16:21 ` Erik Aronesty

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox