path: root/88/f4f026682e9fa2255d64e55c6e9b31e74320ab

Return-Path: <arielluaces@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4B9DBC000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Feb 2021 02:20:58 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 1BE7760650
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Feb 2021 02:20:58 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id OFwQI0njKQOQ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Feb 2021 02:20:55 +0000 (UTC)
Received: by smtp3.osuosl.org (Postfix, from userid 1001)
 id 6CE0560675; Fri, 19 Feb 2021 02:20:55 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com
 [209.85.208.174])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 74B1C60650
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Feb 2021 02:20:51 +0000 (UTC)
Received: by mail-lj1-f174.google.com with SMTP id c17so11288192ljn.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 18:20:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :content-transfer-encoding;
 bh=Gc8/CP6Zmq9FCRlKjXKZbNL/64B3I0jMcCMzH0BqIEw=;
 b=TFrN1M6jjclHfrUT/xlu8MAqWpSmyxxaUMqnkvrmeSB9oaAKo+gq/94T9XVVemqFki
 lDvXum8UQUB5BY+lvH8Me/SCZ/x5LkeFQ5cC+NZ6LUDzkSYZgfYM4MAjpq3uukUo1LC0
 VbUD26T4w+574b9CxsGeygO3JmHhoW0OIUn9/V3ciQKMTe2YDOFRzzXMTKPPpvqE9NVF
 mHIZsBdevpY7gUU4XiWIDFvvAW2Vf8+AcB1nT54Z6uO67JXsrBJZCpMvIhNRyEh4YpwO
 ORmiGAtGtHfkXesjQ7kjawVpCV9NNwBhiRmzrrE1+B3lPzPL9KcJaOBapd4lSA2xetMB
 k+bQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:content-transfer-encoding;
 bh=Gc8/CP6Zmq9FCRlKjXKZbNL/64B3I0jMcCMzH0BqIEw=;
 b=b/V1QpNfjXtyhylChFRxw+1oCWtuk8LVNX0TjvOrsiptfcsfHcFmkjelhlR8x532dm
 N+gD7JVE1ZkwYRVh0gZaiw/wdhOXcXfvSg1exPoLS51fBan2Z5SFUgJR4SIJdmVPKVbN
 W4mjBhVL5rF7qYyz5mFqe8fxdcs+O2bRhQ02dkzDn72//z/7bup77gdxNX6TjSXZ85Ia
 d6kF4jEJaftmwPWHP/4pc+k1i969BgjseKSw7cOseGzvPvxWcvBODYkmh69yNZFQMmC8
 yieXgiYGcp42jf5wESn/OsPEQRQObw/+mWzadcTMBdqNq48rXJ1KDZ25ALcBe0PinH6q
 DOsw==
X-Gm-Message-State: AOAM530bcOkV9H6xNzgLdOC4/23oZx7NWckJ0TyVYAwocfkkdhDACODw
 p4yF2M7mB4grUmPLa8XC3vPpWtp6d8Qdww9zq+oY/8Q9qr8=
X-Google-Smtp-Source: ABdhPJxNOp1AxDU0a7863sjKZbTqTlkiaahdllnQWPzLkVk1XavpeFs9rBN3tPqqv+otvtwgu9R5UZ9pc9dWBZg9Ic0=
X-Received: by 2002:a19:7b12:: with SMTP id w18mr4119159lfc.548.1613701248750; 
 Thu, 18 Feb 2021 18:20:48 -0800 (PST)
MIME-Version: 1.0
References: <CAFvNmHSHu0gqVgWxOCJnSTf5mxpWsMF9FrMQ+_X+uyR3P4QCsg@mail.gmail.com>
 <8591CF93-E574-4C23-90D5-FA410637DECD@mattcorallo.com>
 <CAFvNmHSwRGEy-kE8OA4mcDJ+fJjO7J1ckThWY=wqv4yge-MA1Q@mail.gmail.com>
 <7b8543c3-8ff2-3a6a-b2d4-f4a6cf150d78@mattcorallo.com>
 <CALeFGL1e+q2mrCox99sUOAXYu3qcC7Xce7AfkuKuLPmxh1oSiA@mail.gmail.com>
 <a1ae49f7-049f-cda5-19af-e02a8952e5a4@mattcorallo.com>
In-Reply-To: <a1ae49f7-049f-cda5-19af-e02a8952e5a4@mattcorallo.com>
From: Ariel Luaces <arielluaces@gmail.com>
Date: Thu, 18 Feb 2021 18:20:37 -0800
Message-ID: <CAOv1Tnh2wZ84kn_bCPxbjztuQhSmNOdUEhkkwXXPX8TfQLYeFQ@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 19 Feb 2021 12:42:43 +0000
Subject: Re: [bitcoin-dev] Yesterday's Taproot activation meeting on
 lockinontimeout (LOT)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Feb 2021 02:20:58 -0000

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 sp=
ecific 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 conve=
rsation on the IRC channel or on social media etc.
> > The argument comes from a naive assumption that users MUST upgrade to t=
he 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 forc=
ed 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=3Dtrue does not split the chain. It strictly reduces the
liklihood of that."
- 11:06: "LOT=3Dfalse has chainsplit risks, not LOT=3Dtrue"
- 08:59 "I guess it would be helpful to hear miners' answers to that questi=
on."
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=3Dtrue 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=3Dtrue regardless of the default,
so it will be safer if LOT=3Dtrue is made the default"
- 11:18 "With LOT=3Dtrue, attempted UASFs are not necessary"
- 11:18 "why give them the ability to act maliciously in the first place?"
Response:11:18"LOT=3Dfalse does not; people choosing to run software
that will enforce taproot under some reasonable circumstances provides
the information.  LOT=3Dfalse just reduces the risk of unexpected
results from resulting in danger."
Response: 11:18 "LOT=3Dfalse strictly increases the risks though.."
Response: 11:18 "please stop saying that, there are tradeoffs both ways."
- 11:11 "LOT=3Dfalse gives miners the ability to decide [in response to
someone saying that LOT=3Dfalse gives everyone else in the community the
ability to decide]"
This quote is a bit more nuanced because the implication is that
LOT=3Dtrue 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=3Dtrue 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=3Dtrue doesn't guarantee anything.
- 11:17 "The LOT=3DTrue 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 perc=
eption that LOT=3Dtrue is antagonistic to miners. I actually think it offer=
s 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=
=3Dfalse.
If you look at https://taprootactivation.com/ no miners seem to be
expressing any support at all for lot=3Dtrue. 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=3Dtrue.
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=3Dtrue 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=3Dtrue 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=3Dtrue 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 T=
aproot before LOT is even relevant. I think it is prudent to prepare for th=
e 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 http=
s://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.ht=
ml) of individuals or a proportion of the community changing LOT to true. I=
n that sense setting LOT=3Dfalse in a software release appears to be no mor=
e safe than LOT=3Dtrue.
If a LOT=3Dtrue 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=3Dtrue.
It's true that some will stubbornly run LOT=3Dtrue 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=3Dfalse =
in protocol implementations in my email :)
Yes I do agree with the recommendation of LOT=3Dfalse. 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 othe=
r 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=3Dtrue kind of spoils the LOT=3Dfalse choice
(only if LOT=3Dtrue manages to gather support) because running LOT=3Dfalse
is being complicit/tolerant of the aggressive attitude of LOT=3Dtrue.
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=3Dtrue. 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 itse=
lf is consensus code which executes as a part
> of a fork, and one which deserves as much scrutiny as anything else. Whil=
e taproot is a model of how a soft-fork should
> be designed, this doesn't imply anything about the consensus code which r=
epresents the activation thereof.
>
> Hence all the debate around activation - ultimately its also defining a f=
ork, 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 po=
int, but I believe most in this discussion are
> OK with flag-day-based activation (given some level of care) if it become=
s 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 consid=
ered for activation here.
> >
> > The designation of "soft fork" is accurate but I don't think it adequat=
ely 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 mea=
n 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 n=
ot 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 inf=
luence over what code does or does not get run.
> > This isn't a soft fork that makes some particular UTXO's unspendable. I=
t isn't one that bans miners from collecting
> > fees. It is a change that means that certain "always accept" transactio=
ns actually have real conditions you have to
> > meet. I can't imagine a less intrusive change.
> >
> > On the other hand, choosing to let L=3DF 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/ change=
s that the rest of the network wants.
> >
> > I can certainly live with an L=3DF attempt as a way to punt on the disc=
ussion, maybe the activation happens and this will
> > all be fine. But if it doesn't, I hardly think that users of Bitcoin ar=
e just going to be like "well, guess that's it
> > for Taproot". I have no idea what ensues at that point, but probably an=
other 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 tr=
eat all soft forks as equal.
> >
> > Keagan
> >
> > On Thu, Feb 18, 2021 at 7:43 AM Matt Corallo via bitcoin-dev <bitcoin-d=
ev@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 th=
at risk has been minimized for Taproot.
> >      >
> >      > You know (better than I do in fact) that Bitcoin (and layers bui=
lt 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 t=
o be entirely irrelevant and miners activate Taproot
> >      > before it becomes relevant. And even the unlikely worst case sce=
nario 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@mattcoral=
lo.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 (t=
hat have material *transaction processing* userbases,
> >      >     and I=E2=80=99m not sure to what extent that=E2=80=99s 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:bitco=
in-dev@lists.linuxfoundation.org>>> wrote:
> >      >>
> >      >>     =EF=BB=BF
> >      >>     Right, that is one option. Personally I would prefer a Bitc=
oin Core release sets LOT=3Dfalse (based on what I have
> >      >>     heard from Bitcoin Core contributors) and a community effor=
t releases a version with LOT=3Dtrue. I don't think
> >     users
> >      >>     should be forced to choose something they may have no conte=
xt on before they are allowed to use Bitcoin Core.
> >      >>
> >      >>     My current understanding is that roasbeef is planning to se=
t LOT=3Dfalse 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@protonm=
ail.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 a=
ny other change, can be contentious like any other
> >      >>         change, and we must resolve it like any other change. O=
therwise 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 LO=
T=3Dtrue or LOT=3Dfalse, would be to have a release that
> >      >>         requires a `taprootlot=3D1` or `taprootlot=3D0` and ref=
uses to start if the parameter is not set.
> >      >>
> >      >>         This assures everyone that neither choice is being forc=
ed 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 b=
itcoin-dev <bitcoin-dev@lists.linuxfoundation.org
> >     <mailto:bitcoin-dev@lists.linuxfoundation.org>
> >      >>         <mailto:bitcoin-dev@lists.linuxfoundation.org <mailto:b=
itcoin-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 "pe=
ople" you speak of. I don't know if you're responding
> >      >>         to conversation on the IRC channel or on social media e=
tc.
> >      >>         > >
> >      >>         > > > The argument comes from a naive assumption that u=
sers MUST upgrade to the choice that is submitted
> >     into
> >      >>         code. But in fact this isn't true and some voices in th=
is discussion need to be more humble about what users
> >      >>         must or must not run.
> >      >>         > >
> >      >>         > > I personally have never made this assumption. Of co=
urse users aren't forced to run any particular
> >     software
> >      >>         version, quite the opposite. Defaults set in software v=
ersions matter though as many users won't change
> >     them.
> >      >>         > >
> >      >>         > > > Does no one realize that it is a very possible ou=
tcome that if LOT=3Dtrue 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 thos=
e 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 unli=
kely but possible outcome that miners fail to
> >     activate
> >      >>         and hence have this discussion now rather than be unpre=
pared 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-Fe=
bruary/018380.html
> >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Febru=
ary/018380.html>
> >      >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2021-February/018380.html
> >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Febru=
ary/018380.html>>) of individuals or a
> >      >>         proportion of the community changing LOT to true. In th=
at sense setting LOT=3Dfalse in a software release
> >      >>         appears to be no more safe than LOT=3Dtrue.
> >      >>         > >
> >      >>         > > > The result: a wasted year of waiting and a minori=
ty 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=3Dtrue is antagonistic to miners. I actually
> >     think it
> >      >>         offers them clarity on what will happen over a year tim=
e period and removes the need for coordinated or
> >      >>         uncoordinated community UASF efforts on top of LOT=3Dfa=
lse.
> >      >>         > >
> >      >>         > > > An activation mechanism is a consensus change lik=
e any other change, can be contentious like any other
> >      >>         change, and we must resolve it like any other change. O=
therwise we risk arriving at the darkest timeline.
> >      >>         > >
> >      >>         > > I don't know what you are recommending here to avoi=
d "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=3Dfalse 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 ant=
agonistic or destructive. Mining pools have pledged
> >      >>         support for Taproot but we don't build secure systems b=
ased on pledges of support, we build them to minimize
> >      >>         trust in any human actors. We can be grateful that peop=
le like Alejandro have worked hard on
> >      >> taprootactivation.com <http://taprootactivation.com> <http://ta=
prootactivation.com
> >     <http://taprootactivation.com>> (and this effort has informed the d=
iscussion) without
> >      >>         taking pledges of support as cast iron guarantees.
> >      >>         > >
> >      >>         > > TL;DR It sounds like you agree with my recommendati=
on to set LOT=3Dfalse in protocol implementations in my
> >      >>         email :)
> >      >>         > >
> >      >>         > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luace=
s <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 definit=
ion 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 thre=
shold.
> >      >>         > > > Hell a UASF doesn't even need code or even a sing=
le node running as long as it exists as a possibility
> >      >>         in people's minds.
> >      >>         > > > The only thing a UASF doesn't have is miner suppo=
rt above an agreed activation threshold (some number
> >      >>         above %51).
> >      >>         > > > I say this because it strikes me when people say =
that they are for LOT=3Dtrue with the logic that
> >     since a
> >      >>         UASF is guaranteed to happen then it's better to just m=
ake it default from the beginning. Words like
> >      >>         coordination and safety are sometimes sprinkled into th=
e argument.
> >      >>         > > > The argument comes from a naive assumption that u=
sers MUST upgrade to the choice that is submitted
> >     into
> >      >>         code. But in fact this isn't true and some voices in th=
is discussion need to be more humble about what users
> >      >>         must or must not run.
> >      >>         > > > Does no one realize that it is a very possible ou=
tcome that if LOT=3Dtrue 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 thos=
e 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=3Dfalse 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 minori=
ty of people who didn't want to be lenient with
> >     miners
> >      >>         by default. The chains could be called BitcoinLenient a=
nd BitcoinStubborn.
> >      >>         > > > How is that strictly safer or more coordinated?
> >      >>         > > > I may be in the minority, or maybe a silent major=
ity, or maybe a majority that just hasn't considered
> >      >>         this as a choice but honestly if there is contention ab=
out whether we're going to be stubborn or lenient
> >     with
> >      >>         miners for Taproot and in the future then I prefer to j=
ust not activate anything at all. I'm fine for
> >     calling
> >      >>         bitcoin ossified, accepting that segwit is Bitcoin's la=
st 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 i=
mplement features like Taproot and many more, we will
> >      >>         become envious enough to put aside our differences on h=
ow to behave towards miners and finally activate
> >     Taproot.
> >      >>         > > > An activation mechanism is a consensus change lik=
e any other change, can be contentious like any other
> >      >>         change, and we must resolve it like any other change. O=
therwise 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.li=
nuxfoundation.org>
> >      >>         <mailto:bitcoin-dev@lists.linuxfoundation.org <mailto:b=
itcoin-dev@lists.linuxfoundation.org>>> wrote:
> >      >>         > > >
> >      >>         > > > > Yesterday (February 16th) we held a second meet=
ing on Taproot
> >      >>         > > > > activation on IRC which again was open to all. =
Despite what appeared
> >      >>         > > > > to be majority support for LOT=3Dfalse over LOT=
=3Dtrue in the first
> >      >>         > > > > meeting I (and others) thought the arguments ha=
d not been explored in
> >      >>         > > > > depth and that we should have a follow up meeti=
ng almost entirely
> >      >>         > > > > focused on whether LOT (lockinontimeout) should=
 be set to true or
> >      >>         > > > > false.
> >      >>         > > > >
> >      >>         > > > > The meeting was announced here:
> >      >>         > > > > https://lists.linuxfoundation.org/pipermail/bit=
coin-dev/2021-February/018380.html
> >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Febru=
ary/018380.html>
> >      >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2021-February/018380.html
> >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Febru=
ary/018380.html>>
> >      >>         > > > >
> >      >>         > > > > In that mailing list post I outlined the argume=
nts for LOT=3Dtrue (T1 to
> >      >>         > > > > T6) and arguments for LOT=3Dfalse (F1 to F6) in=
 their strongest form I
> >      >>         > > > > could. David Harding responded with an addition=
al argument for
> >      >>         > > > > LOT=3Dfalse (F7) here:
> >      >>         > > > > https://lists.linuxfoundation.org/pipermail/bit=
coin-dev/2021-February/018415.html
> >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Febru=
ary/018415.html>
> >      >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2021-February/018415.html
> >     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Febru=
ary/018415.html>>
> >      >>         > > > >
> >      >>         > > > > These meetings are very challenging given they =
are open to all, you
> >      >>         > > > > don=E2=80=99t know who will attend and you don=
=E2=80=99t know most people=E2=80=99s views in
> >      >>         > > > > advance. I tried to give time for both the LOT=
=3Dtrue arguments and the
> >      >>         > > > > LOT=3Dfalse arguments to be discussed as I knew=
 there was support for
> >      >>         > > > > both. We only tried evaluating which had more s=
upport and which had
> >      >>         > > > > more strong opposition towards the end of the m=
eeting.
> >      >>         > > > >
> >      >>         > > > > The conversation log is here:
> >      >>         > > > > http://gnusha.org/taproot-activation/2021-02-16=
.log
> >     <http://gnusha.org/taproot-activation/2021-02-16.log> <http://gnush=
a.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 o=
f the meeting here.
> >      >>         > > > > Thanks to the YouTube account =E2=80=9CBitcoin=
=E2=80=9D for setting up the livestream:
> >      >>         > > > > https://www.youtube.com/watch?v=3Dvpl5q1ovMLM <=
https://www.youtube.com/watch?v=3Dvpl5q1ovMLM>
> >     <https://www.youtube.com/watch?v=3Dvpl5q1ovMLM <https://www.youtube=
.com/watch?v=3Dvpl5q1ovMLM>>)
> >      >>         > > > >
> >      >>         > > > > A summary of the meeting was provided by Luke D=
ashjr on Mastodon here:
> >      >>         > > > > https://bitcoinhackers.org/@lukedashjr/10574291=
8779234566
> >     <https://bitcoinhackers.org/@lukedashjr/105742918779234566>
> >      >>         <https://bitcoinhackers.org/@lukedashjr/105742918779234=
566
> >     <https://bitcoinhackers.org/@lukedashjr/105742918779234566>>
> >      >>         > > > >
> >      >>         > > > > Today's #Bitcoin #Taproot meeting was IMO large=
ly unproductive, but we
> >      >>         > > > > did manage to come to consensus on everything b=
ut LockinOnTimeout.
> >      >>         > > > >
> >      >>         > > > > Activation height range: 693504-745920
> >      >>         > > > >
> >      >>         > > > > MASF threshold: 1815/2016 blocks (90%)
> >      >>         > > > >
> >      >>         > > > > Keep in mind only ~100 people showed for the me=
etings, hardly
> >      >>         > > > > representative of the entire community.
> >      >>         > > > >
> >      >>         > > > > So, these details remain JUST a proposal for no=
w.
> >      >>         > > > >
> >      >>         > > > > It seems inevitable that there won't be consens=
us on LOT.
> >      >>         > > > >
> >      >>         > > > > Everyone will have to choose for himself. :/
> >      >>         > > > >
> >      >>         > > > > Personally I agree with most of this. I agree t=
hat there wasn=E2=80=99t
> >      >>         > > > > overwhelming consensus for either LOT=3Dtrue or=
 LOT=3Dfalse. However, from
> >      >>         > > > > my perspective there was clearly more strong op=
position (what would
> >      >>         > > > > usually be deemed a NACK in Bitcoin Core review=
 terminology) from
> >      >>         > > > > Bitcoin Core contributors, Lightning developers=
 and other community
> >      >>         > > > > members against LOT=3Dtrue than there was for L=
OT=3Dfalse. Andrew Chow
> >      >>         > > > > tried to summarize views from the meeting in th=
is analysis:
> >      >>         > > > > https://gist.github.com/achow101/3e179501290abb=
7049de198d46894c7c
> >     <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>
> >      >>         <https://gist.github.com/achow101/3e179501290abb7049de1=
98d46894c7c
> >     <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>=
>
> >      >>         > > > >
> >      >>         > > > > I am also aware of other current and previous B=
itcoin Core
> >      >>         > > > > contributors and Lightning developers who didn=
=E2=80=99t attend the meeting in
> >      >>         > > > > person who are opposed to LOT=3Dtrue. I don=E2=
=80=99t want to put them in the
> >      >>         > > > > spotlight for no reason but if you go through t=
he conversation logs of
> >      >>         > > > > not only the meeting but the weeks of discussio=
n prior to this meeting
> >      >>         > > > > you will see their views evaluated on the ##tap=
root-activation
> >      >>         > > > > channel. In addition, on taprootactivation.com =
<http://taprootactivation.com>
> >     <http://taprootactivation.com <http://taprootactivation.com>> some =
mining pools
> >      >>         > > > > expressed a preference for lot=3Dfalse though I=
 don=E2=80=99t know how strong
> >      >>         > > > > that preference was.
> >      >>         > > > >
> >      >>         > > > > I am only one voice but it is my current assess=
ment that if we are to
> >      >>         > > > > attempt to finalize Taproot activation paramete=
rs and propose them to
> >      >>         > > > > the community at this time our only option is t=
o propose LOT=3Dfalse.
> >      >>         > > > > Any further delay appears to me counterproducti=
ve in our collective
> >      >>         > > > > aim to get the Taproot soft fork activated as e=
arly as possible.
> >      >>         > > > >
> >      >>         > > > > Obviously others are free to disagree with that=
 assessment and
> >      >>         > > > > continue discussions but personally I will be a=
ttempting to avoid
> >      >>         > > > > those discussions unless prominent new informat=
ion 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=E2=80=99ve
> >      >>         > > > > said previously that will be loosely following =
the format of the
> >      >>         > > > > Bitcoin Core PR review club and will be lower l=
evel 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 w=
ho joined the
> >      >>         > > > > discussion on the channel prior and post the me=
eting) for engaging
> >      >>         > > > > productively and in good faith.
> >      >>         > >
> >      >>         > > --
> >      >>         > > Michael Folkson
> >      >>         > > Email: michaelfolkson@gmail.com <mailto:michaelfolk=
son@gmail.com> <mailto:michaelfolkson@gmail.com
> >     <mailto:michaelfolkson@gmail.com>>
> >      >>         > > Keybase: michaelfolkson
> >      >>         > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C F=
EE3
> >      >>         > > _______________________________________________
> >      >>         > > bitcoin-dev mailing list
> >      >>         > > bitcoin-dev@lists.linuxfoundation.org <mailto:bitco=
in-dev@lists.linuxfoundation.org>
> >     <mailto:bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@l=
ists.linuxfoundation.org>>
> >      >>         > > https://lists.linuxfoundation.org/mailman/listinfo/=
bitcoin-dev
> >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> >      >>         <https://lists.linuxfoundation.org/mailman/listinfo/bit=
coin-dev
> >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>>
> >      >>
> >      >>
> >      >>
> >      >>
> >      >>     --
> >      >>     Michael Folkson
> >      >>     Email: michaelfolkson@gmail.com <mailto:michaelfolkson@gmai=
l.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@l=
ists.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.lin=
uxfoundation.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