path: root/6a/b011f4870928af78f269eaa20d4e56f69ca60f

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 12163C000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 11:52:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 0E66786E15
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 11:52:18 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id XoJsZeJIumAv
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 11:52:15 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch
 [185.70.40.132])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 4953D86322
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 11:52:14 +0000 (UTC)
Date: Thu, 18 Feb 2021 11:52:05 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail; t=1613649131;
 bh=vBHGVwZCN+hasX/UJap8m5uvGLj9e7+UjziG1DlZiCM=;
 h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
 b=QbFPe1g100cnebQAls2YjCR7+8wxMtp18h9EAmGLgTZysL+AL8qvEFhJY8dnBOSwX
 /LxrJ2nd8kr5NRL++MFPf/v5YIrqNZGbAlUHFdgQRvlhvtv8FAIEDFOEV48Nve6P1+
 qEBCOj+hnmDuM9hZ0QKEJSVIgeRna6z6oIH7eOZw=
To: Samson Mow <samson.mow@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <vMdhML4Coj8h6x3LS3kWrMXcINOLKmWOyVzElVr5TZ-nf4FkzDjmQsSaoyYcxL_f74rEI3NUX7JAmXprBSxqOzGi7ZNRhwluA_5f1oqa5oM=@protonmail.com>
In-Reply-To: <CAAWeQ5fH+pbEx32uEc4gs_arQC7o+GS+HpVeAZGsKr8i6ewL5w@mail.gmail.com>
References: <CAFvNmHTGkQJnsp7J8q0W3rf2j_djO0J0GNFzrhTpdAvN1GihEA@mail.gmail.com>
 <8231ddff-aaa4-4ee0-b25f-40ba9a540aab@gmail.com>
 <CAFvNmHSiZhJQ455=RkUVU00ZqagimjGPg_fhC-8oJV=WwM_o=Q@mail.gmail.com>
 <CAAWeQ5fH+pbEx32uEc4gs_arQC7o+GS+HpVeAZGsKr8i6ewL5w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Michael Folkson <michaelfolkson@gmail.com>
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: Thu, 18 Feb 2021 11:52:18 -0000

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 othe=
r 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=3Dtrue or LOT=3Dfa=
lse, would be to have a release that requires a `taprootlot=3D1` or `taproo=
tlot=3D0` and refuses to start if the parameter is not set.

This assures everyone that neither choice is being forced on users, and ins=
tead what is being forced on users, is for users to make that choice themse=
lves.

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 thes=
e ephemeral "people" you speak of. I don't know if you're responding to con=
versation 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 so=
me voices in this discussion need to be more humble about what users must o=
r must not run.
> >
> > I personally have never made this assumption. Of course users aren't fo=
rced to run any particular software version, quite the opposite. Defaults s=
et 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=3D=
true is released there may be only a handful of people that begin running i=
t while everyone else delays their upgrade (with the very good reason of no=
t getting involved in politics) and a year later those handful of people ju=
st 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 ha=
ve this discussion now rather than be unprepared for that eventuality. If L=
OT is set to false in a software release there is the possibility (T2 in=
=C2=A0https://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=3Dfalse in a software release appears to=
 be no more safe than LOT=3Dtrue.
> >
> > > The result: a wasted year of waiting and a minority of people who did=
n't want to be lenient with miners by default.
> >
> > There is the (unlikely but possible) possibility of a wasted year if LO=
T is set to false and miners fail to activate. I'm not convinced by this pe=
rception that LOT=3Dtrue is antagonistic to miners. I actually think it off=
ers them clarity on what will happen over a year time period and removes th=
e need for coordinated or uncoordinated community UASF efforts on top of LO=
T=3Dfalse.
> >
> > > 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 o=
ther change. Otherwise we risk arriving at the darkest timeline.
> >
> > I don't know what you are recommending here to avoid "this darkest time=
line". Open discussions have occurred and are continuing and in my mailing =
list post that you responded to **I recommended we propose LOT=3Dfalse be s=
et in protocol implementations such as Bitcoin Core**. I do think this apoc=
alyptic language isn't particularly helpful. In an open consensus system di=
scussion is healthy, we should prepare for bad or worst case scenarios in a=
dvance and doing so is not antagonistic or destructive. Mining pools=C2=
=A0have 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 taproot=
activation.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=3Dfals=
e 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 surro=
unding 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 th=
e actual definition is "any activation that is not a MASF".
> > > A UASF can consist of a single node, ten nodes, a thousand, half of a=
ll 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 an=
y support right up against a miner activation threshold.
> > > Hell a UASF doesn't even need code or even a single node running as l=
ong as it exists as a possibility in people's minds.
> > > The only thing a UASF doesn't have is miner support above an agreed a=
ctivation threshold (some number above %51).
> > > I say this because it strikes me when people say that they are for LO=
T=3Dtrue 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 so=
me voices in this discussion need to be more humble about what users must o=
r must not run.
> > > Does no one realize that it is a very possible outcome that if LOT=3D=
true is released there may be only a handful of people that begin running i=
t while everyone else delays their upgrade (with the very good reason of no=
t getting involved in politics) and a year later those handful of people ju=
st 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 minori=
ty fork. Then a lot=3Dfalse could be started that ends up activating the fe=
ature now that the stubborn option has ran its course.
> > > The result: a wasted year of waiting and a minority of people who did=
n't want to be lenient with miners by default. The chains could be called B=
itcoinLenient and BitcoinStubborn.
> > > How is that strictly safer or more coordinated?
> > > I may be in the minority, or maybe a silent majority, or maybe a majo=
rity 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 a=
t all. I'm fine for calling bitcoin ossified, accepting that segwit is Bitc=
oin'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 li=
ke Taproot and many more, we will become envious enough to put aside our di=
fferences 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 o=
ther 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 appeare=
d
> > > > to be majority support for LOT=3Dfalse over LOT=3Dtrue 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-Februa=
ry/018380.html
> > > >
> > > > In that mailing list post I outlined the arguments for LOT=3Dtrue (=
T1 to
> > > > T6) and arguments for LOT=3Dfalse (F1 to F6) in their strongest for=
m I
> > > > could. David Harding responded with an additional argument for
> > > > LOT=3Dfalse (F7) here:
> > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Februa=
ry/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 f=
or
> > > > 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 =E2=80=9CBitcoin=E2=80=9D for setting=
 up the livestream:
> > > > https://www.youtube.com/watch?v=3Dvpl5q1ovMLM)
> > > >
> > > > A summary of the meeting was provided by Luke Dashjr on Mastodon he=
re:
> > > > 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=
=E2=80=99t
> > > > overwhelming consensus for either LOT=3Dtrue or LOT=3Dfalse. Howeve=
r, 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=3Dtrue than there was for LOT=3Dfalse. Andrew C=
how
> > > > 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=E2=80=99t attend the=
 meeting in
> > > > person who are opposed to LOT=3Dtrue. I don=E2=80=99t want to put t=
hem 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 meet=
ing
> > > > you will see their views evaluated on the ##taproot-activation
> > > > channel. In addition, on 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 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=3Dfals=
e.
> > > > 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 o=
r
> > > > various specific individuals change their minds.
> > > >
> > > > Next week we are planning a code review of the Bitcoin Core PR #195=
73
> > > > 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 level and more
> > > > technical. That is planned for Tuesday February 23rd at 19:00 UTC o=
n
> > > > 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:=C2=A0michaelfolkson@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