path: root/5c/5810b66f3ef6a10e0b014d448e83d3f801f306

Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 126EEC000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 13:59:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id E6C2C60067
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 13:59:40 +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 OyJB_UUwjfeq
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 13:59:39 +0000 (UTC)
Received: by smtp3.osuosl.org (Postfix, from userid 1001)
 id 1645B605FE; Thu, 18 Feb 2021 13:59:39 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 5700C605EF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 13:59:36 +0000 (UTC)
Received: by mail.as397444.net (Postfix) with ESMTPSA id B96E04A389A;
 Thu, 18 Feb 2021 13:59:34 +0000 (UTC)
X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com;
 s=1613654463; t=1613656774;
 bh=K9+ZlO+CmdPG66sDJZk6TajCH6OqmZP/8b3Uzt92aOs=;
 h=From:Subject:Date:References:Cc:In-Reply-To:To:From;
 b=FXs5Q3z1WFvMbN0cwhChQpbASUupXGk/LqSjQWRR8CbLTUmH3jnG/qbCt2n/bqFab
 XeMhmWa6b04zygvBaFIrwnyT5KNweAULj8HK5PnmlxM9eVCJezrnirRjsYoLOgjFkE
 raLWytnkmTzzmTbVw4CgZMxl5MyzKP5oBodET4+yqkseuNNOwAQVM9GXq58jVaWKhx
 LcQ6eP7ZWQ5bSDfkYhshQH8A3wP3ku5gWi3m+w23hAjC7T1+nu1i+O2J94H4OZIFG1
 mm8sgtiSNRdDuRvvK/uWm3N3WCgfKJEcGSRG9RxHf3foUu5+LkcrEo9arFncq6mvAh
 s0O/zpKRecOsQ==
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Matt Corallo <lf-lists@mattcorallo.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 18 Feb 2021 08:59:34 -0500
Message-Id: <9C0CDEF6-E77D-496F-BC38-8A0241B5E046@mattcorallo.com>
References: <vMdhML4Coj8h6x3LS3kWrMXcINOLKmWOyVzElVr5TZ-nf4FkzDjmQsSaoyYcxL_f74rEI3NUX7JAmXprBSxqOzGi7ZNRhwluA_5f1oqa5oM=@protonmail.com>
In-Reply-To: <vMdhML4Coj8h6x3LS3kWrMXcINOLKmWOyVzElVr5TZ-nf4FkzDjmQsSaoyYcxL_f74rEI3NUX7JAmXprBSxqOzGi7ZNRhwluA_5f1oqa5oM=@protonmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 13:59:41 -0000

Bitcoin is a consensus system. Please let=E2=80=99s not jump to (or even con=
sider) options that discourage consensus. We all laughed at (and later acade=
mics researched showed severe deficiencies in) Bitcoin XT=E2=80=99s =E2=80=9C=
emergent consensus=E2=80=9D 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.lin=
uxfoundation.org> wrote:
>=20
> =EF=BB=BFGood morning all,
>=20
>> "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."
>>=20
>> Who's we here?
>>=20
>> Release both and let the network decide.
>=20
> A thing that could be done, without mandating either LOT=3Dtrue or LOT=3Df=
alse, 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.
>=20
> This assures everyone that neither choice is being forced on users, and in=
stead what is being forced on users, is for users to make that choice themse=
lves.
>=20
> Regards,
> ZmnSCPxj
>=20
>>=20
>>> On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <bitcoin=
-dev@lists.linuxfoundation.org> wrote:
>>>=20
>>> Thanks for your response Ariel. It would be useful if you responded to s=
pecific points I have made in the mailing list post or at least quote these e=
phemeral "people" you speak of. I don't know if you're responding to convers=
ation on the IRC channel or on social media etc.
>>>=20
>>>> 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 v=
oices in this discussion need to be more humble about what users must or mus=
t not run.
>>>=20
>>> I personally have never made this assumption. Of course users aren't for=
ced to run any particular software version, quite the opposite. Defaults set=
 in software versions matter though as many users won't change them.
>>>=20
>>>> Does no one realize that it is a very possible outcome that if LOT=3Dtr=
ue is released there may be only a handful of people that begin running it w=
hile everyone else delays their upgrade (with the very good reason of not ge=
tting involved in politics) and a year later those handful of people just be=
come stuck at the moment of MUST_SIGNAL, unable to mine new blocks?
>>>=20
>>> 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 the=
 unlikely but possible outcome that miners fail to activate and hence have t=
his 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) o=
f 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 t=
han LOT=3Dtrue.
>>>=20
>>>> The result: a wasted year of waiting and a minority of people who didn'=
t want to be lenient with miners by default.
>>>=20
>>> 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 offers=
 them clarity on what will happen over a year time period and removes the ne=
ed for coordinated or uncoordinated community UASF efforts on top of LOT=3Df=
alse.
>>>=20
>>>> An activation mechanism is a consensus change like any other change, ca=
n be contentious like any other change, and we must resolve it like any othe=
r change. Otherwise we risk arriving at the darkest timeline.
>>>=20
>>> I don't know what you are recommending here to avoid "this darkest timel=
ine". Open discussions have occurred and are continuing and in my mailing li=
st post that you responded to **I recommended we propose LOT=3Dfalse be set i=
n protocol implementations such as Bitcoin Core**. I do think this apocalypt=
ic language isn't particularly helpful. In an open consensus system discussi=
on is healthy, we should prepare for bad or worst case scenarios in advance a=
nd doing so is not antagonistic or destructive. Mining pools have pledged su=
pport for Taproot but we don't build secure systems based on pledges of supp=
ort, 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 t=
his effort has informed the discussion) without taking pledges of support as=
 cast iron guarantees.
>>>=20
>>> TL;DR It sounds like you agree with my recommendation to set LOT=3Dfalse=
 in protocol implementations in my email :)
>>>=20
>>>> On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <arielluaces@gmail=
.com> wrote:
>>>=20
>>>> Something what strikes me about the conversation is the emotion surroun=
ding 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 a=
ctual 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 di=
mension it can have zero mining support, 51% support, 49% support, or any su=
pport right up against a miner activation threshold.
>>>> Hell a UASF doesn't even need code or even a single node running as lon=
g as it exists as a possibility in people's minds.
>>>> The only thing a UASF doesn't have is miner support above an agreed act=
ivation threshold (some number above %51).
>>>> I say this because it strikes me when people say that they are for LOT=3D=
true with the logic that since a UASF is guaranteed to happen then it's bett=
er to just make it default from the beginning. Words like coordination and s=
afety are sometimes sprinkled into the argument.
>>>> 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 v=
oices in this discussion need to be more humble about what users must or mus=
t not run.
>>>> Does no one realize that it is a very possible outcome that if LOT=3Dtr=
ue is released there may be only a handful of people that begin running it w=
hile everyone else delays their upgrade (with the very good reason of not ge=
tting involved in politics) and a year later those handful of people just be=
come stuck at the moment of MUST_SIGNAL, unable to mine new blocks? Or attra=
cting 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 no=
w 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 Bitc=
oinLenient and BitcoinStubborn.
>>>> How is that strictly safer or more coordinated?
>>>> I may be in the minority, or maybe a silent majority, or maybe a majori=
ty that just hasn't considered this as a choice but honestly if there is con=
tention about whether we're going to be stubborn or lenient with miners for T=
aproot 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 l=
ast network upgrade. Taproot is amazing but no new feature is worth a networ=
k 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 diffe=
rences on how to behave towards miners and finally activate Taproot.
>>>> An activation mechanism is a consensus change like any other change, ca=
n be contentious like any other change, and we must resolve it like any othe=
r 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-d=
ev@lists.linuxfoundation.org> wrote:
>>>>=20
>>>>> 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=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.
>>>>>=20
>>>>> The meeting was announced here:
>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/=
018380.html
>>>>>=20
>>>>> In that mailing list post I outlined the arguments for LOT=3Dtrue (T1 t=
o
>>>>> T6) and arguments for LOT=3Dfalse (F1 to F6) in their strongest form I=

>>>>> could. David Harding responded with an additional argument for
>>>>> LOT=3Dfalse (F7) here:
>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/=
018415.html
>>>>>=20
>>>>> 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 peo=
ple=E2=80=99s views in
>>>>> advance. I tried to give time for both the LOT=3Dtrue arguments and th=
e
>>>>> LOT=3Dfalse 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.
>>>>>=20
>>>>> The conversation log is here:
>>>>> http://gnusha.org/taproot-activation/2021-02-16.log
>>>>>=20
>>>>> (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)
>>>>>=20
>>>>> A summary of the meeting was provided by Luke Dashjr on Mastodon here:=

>>>>> https://bitcoinhackers.org/@lukedashjr/105742918779234566
>>>>>=20
>>>>> Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we=

>>>>> did manage to come to consensus on everything but LockinOnTimeout.
>>>>>=20
>>>>> Activation height range: 693504-745920
>>>>>=20
>>>>> MASF threshold: 1815/2016 blocks (90%)
>>>>>=20
>>>>> Keep in mind only ~100 people showed for the meetings, hardly
>>>>> representative of the entire community.
>>>>>=20
>>>>> So, these details remain JUST a proposal for now.
>>>>>=20
>>>>> It seems inevitable that there won't be consensus on LOT.
>>>>>=20
>>>>> Everyone will have to choose for himself. :/
>>>>>=20
>>>>> Personally I agree with most of this. I agree that there wasn=E2=80=99=
t
>>>>> overwhelming consensus for either LOT=3Dtrue or LOT=3Dfalse. However, f=
rom
>>>>> 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 Chow=

>>>>> tried to summarize views from the meeting in this analysis:
>>>>> https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
>>>>>=20
>>>>> I am also aware of other current and previous Bitcoin Core
>>>>> contributors and Lightning developers who didn=E2=80=99t attend the me=
eting 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 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=3Dfalse though I don=E2=80=99t know how=
 strong
>>>>> that preference was.
>>>>>=20
>>>>> 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=3Dfalse.
>>>>> Any further delay appears to me counterproductive in our collective
>>>>> aim to get the Taproot soft fork activated as early as possible.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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 level and more
>>>>> technical. That is planned for Tuesday February 23rd at 19:00 UTC on
>>>>> the IRC channel ##taproot-activation.
>>>>>=20
>>>>> 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.
>>>=20
>>> --
>>> 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
>=20
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev