diff options
| author | Matt Corallo <lf-lists@mattcorallo.com> | 2021-02-18 08:59:34 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-02-18 13:59:41 +0000 |
| commit | 4f6db37d1237b84c702a6a9186fd28f40da379bb (patch) | |
| tree | b39267d9e4424f00c0114d472eef77f08371e4a1 | |
| parent | 89f21473e61c4c9c878c039acf5620af7df22a1d (diff) | |
| download | pi-bitcoindev-4f6db37d1237b84c702a6a9186fd28f40da379bb.tar.gz pi-bitcoindev-4f6db37d1237b84c702a6a9186fd28f40da379bb.zip | |
Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
| -rw-r--r-- | 5c/5810b66f3ef6a10e0b014d448e83d3f801f306 | 338 |
1 files changed, 338 insertions, 0 deletions
diff --git a/5c/5810b66f3ef6a10e0b014d448e83d3f801f306 b/5c/5810b66f3ef6a10e0b014d448e83d3f801f306 new file mode 100644 index 000000000..4ae5c33ee --- /dev/null +++ b/5c/5810b66f3ef6a10e0b014d448e83d3f801f306 @@ -0,0 +1,338 @@ +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 + |