diff options
| author | Michael Folkson <michaelfolkson@gmail.com> | 2021-02-18 12:20:14 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-02-18 12:20:28 +0000 |
| commit | 89f21473e61c4c9c878c039acf5620af7df22a1d (patch) | |
| tree | 10e093482848ae0e4d7bc673100ad9b9c870240a | |
| parent | a8876d77b2fd8b27c89a7afaffee681d47d7eb6c (diff) | |
| download | pi-bitcoindev-89f21473e61c4c9c878c039acf5620af7df22a1d.tar.gz pi-bitcoindev-89f21473e61c4c9c878c039acf5620af7df22a1d.zip | |
Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
| -rw-r--r-- | 63/9af22220cd150ba48625e99d6673c6490166b3 | 782 |
1 files changed, 782 insertions, 0 deletions
diff --git a/63/9af22220cd150ba48625e99d6673c6490166b3 b/63/9af22220cd150ba48625e99d6673c6490166b3 new file mode 100644 index 000000000..9d5408682 --- /dev/null +++ b/63/9af22220cd150ba48625e99d6673c6490166b3 @@ -0,0 +1,782 @@ +Return-Path: <michaelfolkson@gmail.com> +Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id AA9BEC000D + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 18 Feb 2021 12:20:28 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by hemlock.osuosl.org (Postfix) with ESMTP id 98AF787315 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 18 Feb 2021 12:20:28 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +Received: from hemlock.osuosl.org ([127.0.0.1]) + by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id Wx7pj2e-7j8a + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 18 Feb 2021 12:20:26 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from mail-oi1-f177.google.com (mail-oi1-f177.google.com + [209.85.167.177]) + by hemlock.osuosl.org (Postfix) with ESMTPS id D9C2D872F3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 18 Feb 2021 12:20:25 +0000 (UTC) +Received: by mail-oi1-f177.google.com with SMTP id l19so1735106oih.6 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 18 Feb 2021 04:20:25 -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 + :cc; bh=jjwK7/YaRBPqQsr8eAeUWC/r9lmoOjnV8m/oDUzoDEA=; + b=NZZuAIPepS41GQkoXFiZ2LuiLNrY86Na3x2XtI9SfwlidP2iTWRCQ6mIrIr4kOhrCY + tIIVtLH9jdllXI8C4JSID3ZrYxjfxamdr6jigu6OBybSsu3nQkoziHyKyZhay2njNKT7 + L2EyZJCq8Eh7clkNbjw6HUa3t+8/7mJc8t+TChWskj4QVyCZYmlZOATjW9Ch4nwdwUOd + SZ36/7h3nUVUHTilGDPM2aw1w/DI0s6ncxuEotXWZfe3ddMQMk+NXSjlhNJjm6rQabEr + bxu1sC8womdklOxFQkQEbqPsnCryUQh19eYmM2zPRyWpxDuJs4eG4QkMAwt3v1ql4mTN + sbLg== +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:cc; + bh=jjwK7/YaRBPqQsr8eAeUWC/r9lmoOjnV8m/oDUzoDEA=; + b=AT8klVjbM/dfD54Nx4DrGAZDrYUXKmUaTxr0DpGXtV8x6teRGnWDpwkTg7oRB4+s2d + YsoH6TJDrFyxXoYklTrSCuTCJKcaCJaon4MobrVpguAZLHivz4a9Ph+v8GeF2sAw1PB8 + 0nXrmKx1ANKrIs3bAlMpzWD27Lq/DNb1vxy8yhAmQrIlOtBftTy2U8TvQJJT3UR8wyFl + isGZoS5ge2bqWmCqf0q27lhNP9t+m8Bdg79B9lIhimdoQkJuOjB7yVkwiCoMi2fLb4ak + 2hea+5xu9G2o7gfqoqmfO/oD2n8XI1DRJn57a1VFpgAJYESYMElKGTCtfNIP/oKCgVaz + xCvA== +X-Gm-Message-State: AOAM531P6hHV9lMQk58LVuPXXoALMyFxBlBAzOmabJUJ+8l/6cr+6Lx0 + 9C3qkUin0ti0R86eNvPNDX+wKeEkQxgKXF7dOKQ= +X-Google-Smtp-Source: ABdhPJxf0aCgWlJxmuA9EcTQjhxFfNXciws5S07g7HgWtlcKmwUDURsGJFjzNInUmQ48xumIi1G9mU07wV2VZsfktI4= +X-Received: by 2002:aca:af91:: with SMTP id y139mr2543998oie.88.1613650825003; + Thu, 18 Feb 2021 04:20:25 -0800 (PST) +MIME-Version: 1.0 +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> + <vMdhML4Coj8h6x3LS3kWrMXcINOLKmWOyVzElVr5TZ-nf4FkzDjmQsSaoyYcxL_f74rEI3NUX7JAmXprBSxqOzGi7ZNRhwluA_5f1oqa5oM=@protonmail.com> +In-Reply-To: <vMdhML4Coj8h6x3LS3kWrMXcINOLKmWOyVzElVr5TZ-nf4FkzDjmQsSaoyYcxL_f74rEI3NUX7JAmXprBSxqOzGi7ZNRhwluA_5f1oqa5oM=@protonmail.com> +From: Michael Folkson <michaelfolkson@gmail.com> +Date: Thu, 18 Feb 2021 12:20:14 +0000 +Message-ID: <CAFvNmHSHu0gqVgWxOCJnSTf5mxpWsMF9FrMQ+_X+uyR3P4QCsg@mail.gmail.com> +To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Content-Type: multipart/alternative; boundary="00000000000037447705bb9b5ce9" +X-Mailman-Approved-At: Thu, 18 Feb 2021 13:10:47 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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 12:20:28 -0000 + +--00000000000037447705bb9b5ce9 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Right, that is one option. Personally I would prefer a Bitcoin Core release +sets LOT=3Dfalse (based on what I have heard from Bitcoin Core contributors= +) +and a community effort releases a version with LOT=3Dtrue. I don't think +users should be forced to choose something they may have no context on +before they are allowed to use Bitcoin Core. + +My current understanding is that roasbeef is planning to set LOT=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@protonmail.com> wrote: + +> Good morning all, +> +> > "An activation mechanism is a consensus change like any other change, +> can be contentious like any other change, and we must resolve it like any +> other change. Otherwise we risk arriving at the darkest timeline." +> > +> > Who's we here? +> > +> > Release both and let the network decide. +> +> A thing that could be done, without mandating either LOT=3Dtrue or +> LOT=3Dfalse, would be to have a release that requires a `taprootlot=3D1` = +or +> `taprootlot=3D0` and refuses to start if the parameter is not set. +> +> This assures everyone that neither choice is being forced on users, and +> instead what is being forced on users, is for users to make that choice +> themselves. +> +> Regards, +> ZmnSCPxj +> +> > +> > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev < +> bitcoin-dev@lists.linuxfoundation.org> wrote: +> > +> > > Thanks for your response Ariel. It would be useful if you responded t= +o +> specific points I have made in the mailing list post or at least quote +> these ephemeral "people" you speak of. I don't know if you're responding = +to +> conversation on the IRC channel or on social media etc. +> > > +> > > > The argument comes from a naive assumption that users MUST upgrade +> to the choice that is submitted into code. But in fact this isn't true an= +d +> some voices in this discussion need to be more humble about what users mu= +st +> or must not run. +> > > +> > > I personally have never made this assumption. Of course users aren't +> forced to run any particular software version, quite the opposite. Defaul= +ts +> set in software versions matter though as many users won't change them. +> > > +> > > > Does no one realize that it is a very possible outcome that if +> LOT=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 those handfu= +l +> of people just become stuck at the moment of MUST_SIGNAL, unable to mine +> new blocks? +> > > +> > > It is a possible outcome but the likely outcome is that miners +> activate Taproot before LOT is even relevant. I think it is prudent to +> prepare for the unlikely but possible outcome that miners fail to activat= +e +> and hence have this discussion now rather than be unprepared for that +> eventuality. If LOT is set to false in a software release there is the +> possibility (T2 in +> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018= +380.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 mor= +e +> safe than LOT=3Dtrue. +> > > +> > > > The result: a wasted year of waiting and a minority of people who +> didn't want to be lenient with miners by default. +> > > +> > > There is the (unlikely but possible) possibility of a wasted year if +> LOT is set to false and miners fail to activate. I'm not convinced by thi= +s +> perception that LOT=3Dtrue is antagonistic to miners. I actually think it +> offers them clarity on what will happen over a year time period and remov= +es +> the need for coordinated or uncoordinated community UASF efforts on top o= +f +> LOT=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 +> other change. Otherwise we risk arriving at the darkest timeline. +> > > +> > > I don't know what you are recommending here to avoid "this darkest +> timeline". Open discussions have occurred and are continuing and in my +> mailing list post that you responded to **I recommended we propose +> LOT=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 wors= +t +> case scenarios in advance and doing so is not antagonistic or destructive= +. +> Mining pools have pledged support for Taproot but we don't build secure +> systems based on pledges of support, we build them to minimize trust in a= +ny +> human actors. We can be grateful that people like Alejandro have worked +> hard on taprootactivation.com (and this effort has informed the +> discussion) without taking pledges of support as cast iron guarantees. +> > > +> > > TL;DR It sounds like you agree with my recommendation to set LOT=3Dfa= +lse +> in protocol implementations in my email :) +> > > +> > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces < +> arielluaces@gmail.com> wrote: +> > > +> > > > Something what strikes me about the conversation is the emotion +> surrounding the letters UASF. +> > > > It appears as if people discuss UASF as if it's a massive tidal wav= +e +> of support that is inevitable, like we saw during segwit activation. But +> the actual definition is "any activation that is not a MASF". +> > > > A UASF can consist of a single node, ten nodes, a thousand, half of +> all nodes, all business' nodes, or even all the non mining nodes. On +> another dimension it can have zero mining support, 51% support, 49% +> support, or any support right up against a miner activation threshold. +> > > > Hell a UASF doesn't even need code or even a single node running as +> long as it exists as a possibility in people's minds. +> > > > The only thing a UASF doesn't have is miner support above an agreed +> activation threshold (some number above %51). +> > > > I say this because it strikes me when people say that they are for +> LOT=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 coordinatio= +n +> 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 an= +d +> some voices in this discussion need to be more humble about what users mu= +st +> or must not run. +> > > > Does no one realize that it is a very possible outcome 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 those handfu= +l +> 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 o= +ff +> 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 minority of people who +> didn't want to be lenient with miners by default. The chains could be +> called BitcoinLenient and BitcoinStubborn. +> > > > How is that strictly safer or more coordinated? +> > > > I may be in the minority, or maybe a silent majority, or maybe a +> majority that just hasn't considered this as a choice but honestly if the= +re +> is contention about whether we're going to be stubborn or lenient with +> miners for Taproot and in the future then I prefer to just not activate +> anything at all. I'm fine for calling bitcoin ossified, accepting that +> segwit is Bitcoin's last network upgrade. Taproot is amazing but no new +> feature is worth a network split down the middle. +> > > > Maybe in 10 or 20 years, when other blockchains implement features +> like Taproot and many more, we will become envious enough to put aside ou= +r +> differences on how to behave towards miners and finally activate Taproot. +> > > > An activation mechanism is a consensus change like any other change= +, +> can be contentious like any other change, and we must resolve it like any +> other change. Otherwise we risk arriving at the darkest timeline. +> > > > Cheers +> > > > Ariel Lorenzo-Luaces +> > > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev < +> bitcoin-dev@lists.linuxfoundation.org> wrote: +> > > > +> > > > > Yesterday (February 16th) we held a second meeting on Taproot +> > > > > activation on IRC which again was open to all. Despite what +> appeared +> > > > > to be majority support for LOT=3Dfalse over LOT=3Dtrue in the fir= +st +> > > > > meeting I (and others) thought the arguments had not been explore= +d +> in +> > > > > depth and that we should have a follow up meeting almost entirely +> > > > > focused on whether LOT (lockinontimeout) should be set to true or +> > > > > false. +> > > > > +> > > > > The meeting was announced here: +> > > > > +> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018= +380.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 f= +orm +> I +> > > > > could. David Harding responded with an additional argument for +> > > > > LOT=3Dfalse (F7) here: +> > > > > +> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018= +415.html +> > > > > +> > > > > These meetings are very challenging given they are open to all, y= +ou +> > > > > don=E2=80=99t know who will attend and you don=E2=80=99t know mos= +t people=E2=80=99s views +> in +> > > > > advance. I tried to give time for both the LOT=3Dtrue arguments a= +nd +> the +> > > > > LOT=3Dfalse arguments to be discussed as I knew there was support= + for +> > > > > both. We only tried evaluating which had more support and which h= +ad +> > > > > 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 setti= +ng up the +> livestream: +> > > > > https://www.youtube.com/watch?v=3Dvpl5q1ovMLM) +> > > > > +> > > > > A summary of the meeting was provided by Luke Dashjr on Mastodon +> here: +> > > > > https://bitcoinhackers.org/@lukedashjr/105742918779234566 +> > > > > +> > > > > Today's #Bitcoin #Taproot meeting was IMO largely unproductive, +> but we +> > > > > did manage to come to consensus on everything but LockinOnTimeout= +. +> > > > > +> > > > > Activation height range: 693504-745920 +> > > > > +> > > > > MASF threshold: 1815/2016 blocks (90%) +> > > > > +> > > > > Keep in mind only ~100 people showed for the meetings, hardly +> > > > > representative of the entire community. +> > > > > +> > > > > So, these details remain JUST a proposal for now. +> > > > > +> > > > > It seems inevitable that there won't be consensus on LOT. +> > > > > +> > > > > Everyone will have to choose for himself. :/ +> > > > > +> > > > > Personally I agree with most of this. I agree that there wasn=E2= +=80=99t +> > > > > overwhelming consensus for either LOT=3Dtrue or LOT=3Dfalse. Howe= +ver, +> from +> > > > > my perspective there was clearly more strong opposition (what wou= +ld +> > > > > usually be deemed a NACK in Bitcoin Core review terminology) from +> > > > > Bitcoin Core contributors, Lightning developers and other communi= +ty +> > > > > 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 +> > > > > +> > > > > I am also aware of other current and previous Bitcoin Core +> > > > > contributors and Lightning developers who didn=E2=80=99t attend t= +he +> 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 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 kno= +w how strong +> > > > > that preference was. +> > > > > +> > > > > I am only one voice but it is my current assessment that if we ar= +e +> to +> > > > > attempt to finalize Taproot activation parameters and propose the= +m +> to +> > > > > the community at this time our only option is to propose LOT=3Dfa= +lse. +> > > > > Any further delay appears to me counterproductive in our collecti= +ve +> > > > > aim to get the Taproot soft fork activated as early as possible. +> > > > > +> > > > > Obviously others are free to disagree with that assessment and +> > > > > continue discussions but personally I will be attempting to avoid +> > > > > those discussions unless prominent new information comes to light +> or +> > > > > various specific individuals change their minds. +> > > > > +> > > > > Next week we are planning a code review of the Bitcoin Core PR +> #19573 +> > > > > which was initially delayed because of this LOT discussion. As I= +=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. +> > > > > +> > > > > Thanks to the meeting participants (and those who joined the +> > > > > discussion on the channel prior and post the meeting) for engagin= +g +> > > > > productively and in good faith. +> > > +> > > -- +> > > Michael Folkson +> > > Email: michaelfolkson@gmail.com +> > > Keybase: michaelfolkson +> > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 +> > > _______________________________________________ +> > > bitcoin-dev mailing list +> > > bitcoin-dev@lists.linuxfoundation.org +> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> +> +> + +--=20 +Michael Folkson +Email: michaelfolkson@gmail.com +Keybase: michaelfolkson +PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 + +--00000000000037447705bb9b5ce9 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Right, that is one option. Personally I would prefer a Bit= +coin Core release sets LOT=3Dfalse (based on what I have heard from Bitcoin= + Core contributors) and a community effort releases a version with LOT=3Dtr= +ue. I don't think users should be forced to choose something they may h= +ave no context on before they are allowed to use Bitcoin Core.=C2=A0<div><b= +r></div><div>My current understanding is that roasbeef is planning to set L= +OT=3Dfalse on btcd (an alternative protocol implementation to Bitcoin Core)= + and Luke Dashjr hasn't yet decided on Bitcoin Knots.</div><div><div><b= +r></div><div><br></div></div></div><br><div class=3D"gmail_quote"><div dir= +=3D"ltr" class=3D"gmail_attr">On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <= +;<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>>= + wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = +0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Good mor= +ning all,<br> +<br> +> "An activation mechanism is a consensus change like any other cha= +nge, can be contentious like any other change, and we must resolve it like = +any other change. Otherwise we risk arriving at the darkest timeline."= +<br> +><br> +> Who's we here?<br> +><br> +> Release both and let the network decide.<br> +<br> +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.<br> +<br> +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.<br> +<br> +Regards,<br> +ZmnSCPxj<br> +<br> +><br> +> On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <<a= + href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bi= +tcoin-dev@lists.linuxfoundation.org</a>> wrote:<br> +><br> +> > Thanks for your response Ariel. It would be useful if you respond= +ed to specific points I have made in the mailing list post or at least quot= +e these ephemeral "people" you speak of. I don't know if you&= +#39;re responding to conversation on the IRC channel or on social media etc= +.<br> +> ><br> +> > > The argument comes from a naive assumption that users MUST u= +pgrade to the choice that is submitted into code. But in fact this isn'= +t true and some voices in this discussion need to be more humble about what= + users must or must not run.<br> +> ><br> +> > I personally have never made this assumption. Of course users are= +n't forced to run any particular software version, quite the opposite. = +Defaults set in software versions matter though as many users won't cha= +nge them.<br> +> ><br> +> > > Does no one realize that it is a very possible outcome 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 rea= +son of not getting involved in politics) and a year later those handful of = +people just become stuck at the moment of MUST_SIGNAL, unable to mine new b= +locks?<br> +> ><br> +> > It is a possible outcome but the likely outcome is that miners ac= +tivate Taproot before LOT is even relevant. I think it is prudent to prepar= +e for the unlikely but possible outcome that miners fail to activate and he= +nce 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=C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev= +/2021-February/018380.html" rel=3D"noreferrer" target=3D"_blank">https://li= +sts.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html</a>= +) 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.<br> +> ><br> +> > > The result: a wasted year of waiting and a minority of peopl= +e who didn't want to be lenient with miners by default.<br> +> ><br> +> > 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 th= +ink it offers them clarity on what will happen over a year time period and = +removes the need for coordinated or uncoordinated community UASF efforts on= + top of LOT=3Dfalse.<br> +> ><br> +> > > An activation mechanism is a consensus change like any other= + change, can be contentious like any other change, and we must resolve it l= +ike any other change. Otherwise we risk arriving at the darkest timeline.<b= +r> +> ><br> +> > I don't know what you are recommending here to avoid "th= +is darkest timeline". Open discussions have occurred and are continuin= +g and in my mailing list post that you responded to **I recommended we prop= +ose 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 w= +orst case scenarios in advance and doing so is not antagonistic or destruct= +ive. Mining pools=C2=A0have pledged support for Taproot but we don't bu= +ild secure systems based on pledges of support, we build them to minimize t= +rust in any human actors. We can be grateful that people like Alejandro hav= +e worked hard on <a href=3D"http://taprootactivation.com" rel=3D"noreferrer= +" target=3D"_blank">taprootactivation.com</a> (and this effort has informed= + the discussion) without taking pledges of support as cast iron guarantees.= +<br> +> ><br> +> > TL;DR It sounds like you agree with my recommendation to set LOT= +=3Dfalse in protocol implementations in my email :)<br> +> ><br> +> > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <<a href= +=3D"mailto:arielluaces@gmail.com" target=3D"_blank">arielluaces@gmail.com</= +a>> wrote:<br> +> ><br> +> > > Something what strikes me about the conversation is the emot= +ion surrounding the letters UASF.<br> +> > > It appears as if people discuss UASF as if it's a massiv= +e tidal wave of support that is inevitable, like we saw during segwit activ= +ation. But the actual definition is "any activation that is not a MASF= +".<br> +> > > 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 node= +s. On another dimension it can have zero mining support, 51% support, 49% s= +upport, or any support right up against a miner activation threshold.<br> +> > > Hell a UASF doesn't even need code or even a single node= + running as long as it exists as a possibility in people's minds.<br> +> > > The only thing a UASF doesn't have is miner support abov= +e an agreed activation threshold (some number above %51).<br> +> > > I say this because it strikes me when people say that they a= +re for LOT=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.<br> +> > > The argument comes from a naive assumption that users MUST u= +pgrade to the choice that is submitted into code. But in fact this isn'= +t true and some voices in this discussion need to be more humble about what= + users must or must not run.<br> +> > > Does no one realize that it is a very possible outcome 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 rea= +son of not getting involved in politics) and a year later those handful of = +people just become stuck at the moment of MUST_SIGNAL, unable to mine new b= +locks? Or attracting a minority of miners, activating, and forking off into= + a minority fork. Then a lot=3Dfalse could be started that ends up activati= +ng the feature now that the stubborn option has ran its course.<br> +> > > The result: a wasted year of waiting and a minority of peopl= +e who didn't want to be lenient with miners by default. The chains coul= +d be called BitcoinLenient and BitcoinStubborn.<br> +> > > How is that strictly safer or more coordinated?<br> +> > > I may be in the minority, or maybe a silent majority, or may= +be a majority that just hasn't considered this as a choice but honestly= + if there is contention about whether we're going to be stubborn or len= +ient with miners for Taproot and in the future then I prefer to just not ac= +tivate anything at all. I'm fine for calling bitcoin ossified, acceptin= +g that segwit is Bitcoin's last network upgrade. Taproot is amazing but= + no new feature is worth a network split down the middle.<br> +> > > Maybe in 10 or 20 years, when other blockchains implement fe= +atures like Taproot and many more, we will become envious enough to put asi= +de our differences on how to behave towards miners and finally activate Tap= +root.<br> +> > > An activation mechanism is a consensus change like any other= + change, can be contentious like any other change, and we must resolve it l= +ike any other change. Otherwise we risk arriving at the darkest timeline.<b= +r> +> > > Cheers<br> +> > > Ariel Lorenzo-Luaces<br> +> > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev= + <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= +ank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br> +> > ><br> +> > > > Yesterday (February 16th) we held a second meeting on T= +aproot<br> +> > > > activation on IRC which again was open to all. Despite = +what appeared<br> +> > > > to be majority support for LOT=3Dfalse over LOT=3Dtrue = +in the first<br> +> > > > meeting I (and others) thought the arguments had not be= +en explored in<br> +> > > > depth and that we should have a follow up meeting almos= +t entirely<br> +> > > > focused on whether LOT (lockinontimeout) should be set = +to true or<br> +> > > > false.<br> +> > > ><br> +> > > > The meeting was announced here:<br> +> > > > <a href=3D"https://lists.linuxfoundation.org/pipermail/= +bitcoin-dev/2021-February/018380.html" rel=3D"noreferrer" target=3D"_blank"= +>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/0183= +80.html</a><br> +> > > ><br> +> > > > In that mailing list post I outlined the arguments for = +LOT=3Dtrue (T1 to<br> +> > > > T6) and arguments for LOT=3Dfalse (F1 to F6) in their s= +trongest form I<br> +> > > > could. David Harding responded with an additional argum= +ent for<br> +> > > > LOT=3Dfalse (F7) here:<br> +> > > > <a href=3D"https://lists.linuxfoundation.org/pipermail/= +bitcoin-dev/2021-February/018415.html" rel=3D"noreferrer" target=3D"_blank"= +>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/0184= +15.html</a><br> +> > > ><br> +> > > > These meetings are very challenging given they are open= + to all, you<br> +> > > > don=E2=80=99t know who will attend and you don=E2=80=99= +t know most people=E2=80=99s views in<br> +> > > > advance. I tried to give time for both the LOT=3Dtrue a= +rguments and the<br> +> > > > LOT=3Dfalse arguments to be discussed as I knew there w= +as support for<br> +> > > > both. We only tried evaluating which had more support a= +nd which had<br> +> > > > more strong opposition towards the end of the meeting.<= +br> +> > > ><br> +> > > > The conversation log is here:<br> +> > > > <a href=3D"http://gnusha.org/taproot-activation/2021-02= +-16.log" rel=3D"noreferrer" target=3D"_blank">http://gnusha.org/taproot-act= +ivation/2021-02-16.log</a><br> +> > > ><br> +> > > > (If you are so inclined you can watch a video of the me= +eting here.<br> +> > > > Thanks to the YouTube account =E2=80=9CBitcoin=E2=80=9D= + for setting up the livestream:<br> +> > > > <a href=3D"https://www.youtube.com/watch?v=3Dvpl5q1ovML= +M" rel=3D"noreferrer" target=3D"_blank">https://www.youtube.com/watch?v=3Dv= +pl5q1ovMLM</a>)<br> +> > > ><br> +> > > > A summary of the meeting was provided by Luke Dashjr on= + Mastodon here:<br> +> > > > <a href=3D"https://bitcoinhackers.org/@lukedashjr/10574= +2918779234566" rel=3D"noreferrer" target=3D"_blank">https://bitcoinhackers.= +org/@lukedashjr/105742918779234566</a><br> +> > > ><br> +> > > > Today's #Bitcoin #Taproot meeting was IMO largely u= +nproductive, but we<br> +> > > > did manage to come to consensus on everything but Locki= +nOnTimeout.<br> +> > > ><br> +> > > > Activation height range: 693504-745920<br> +> > > ><br> +> > > > MASF threshold: 1815/2016 blocks (90%)<br> +> > > ><br> +> > > > Keep in mind only ~100 people showed for the meetings, = +hardly<br> +> > > > representative of the entire community.<br> +> > > ><br> +> > > > So, these details remain JUST a proposal for now.<br> +> > > ><br> +> > > > It seems inevitable that there won't be consensus o= +n LOT.<br> +> > > ><br> +> > > > Everyone will have to choose for himself. :/<br> +> > > ><br> +> > > > Personally I agree with most of this. I agree that ther= +e wasn=E2=80=99t<br> +> > > > overwhelming consensus for either LOT=3Dtrue or LOT=3Df= +alse. However, from<br> +> > > > my perspective there was clearly more strong opposition= + (what would<br> +> > > > usually be deemed a NACK in Bitcoin Core review termino= +logy) from<br> +> > > > Bitcoin Core contributors, Lightning developers and oth= +er community<br> +> > > > members against LOT=3Dtrue than there was for LOT=3Dfal= +se. Andrew Chow<br> +> > > > tried to summarize views from the meeting in this analy= +sis:<br> +> > > > <a href=3D"https://gist.github.com/achow101/3e179501290= +abb7049de198d46894c7c" rel=3D"noreferrer" target=3D"_blank">https://gist.gi= +thub.com/achow101/3e179501290abb7049de198d46894c7c</a><br> +> > > ><br> +> > > > I am also aware of other current and previous Bitcoin C= +ore<br> +> > > > contributors and Lightning developers who didn=E2=80=99= +t attend the meeting in<br> +> > > > person who are opposed to LOT=3Dtrue. I don=E2=80=99t w= +ant to put them in the<br> +> > > > spotlight for no reason but if you go through the conve= +rsation logs of<br> +> > > > not only the meeting but the weeks of discussion prior = +to this meeting<br> +> > > > you will see their views evaluated on the ##taproot-act= +ivation<br> +> > > > channel. In addition, on <a href=3D"http://taprootactiv= +ation.com" rel=3D"noreferrer" target=3D"_blank">taprootactivation.com</a> s= +ome mining pools<br> +> > > > expressed a preference for lot=3Dfalse though I don=E2= +=80=99t know how strong<br> +> > > > that preference was.<br> +> > > ><br> +> > > > I am only one voice but it is my current assessment tha= +t if we are to<br> +> > > > attempt to finalize Taproot activation parameters and p= +ropose them to<br> +> > > > the community at this time our only option is to propos= +e LOT=3Dfalse.<br> +> > > > Any further delay appears to me counterproductive in ou= +r collective<br> +> > > > aim to get the Taproot soft fork activated as early as = +possible.<br> +> > > ><br> +> > > > Obviously others are free to disagree with that assessm= +ent and<br> +> > > > continue discussions but personally I will be attemptin= +g to avoid<br> +> > > > those discussions unless prominent new information come= +s to light or<br> +> > > > various specific individuals change their minds.<br> +> > > ><br> +> > > > Next week we are planning a code review of the Bitcoin = +Core PR #19573<br> +> > > > which was initially delayed because of this LOT discuss= +ion. As I=E2=80=99ve<br> +> > > > said previously that will be loosely following the form= +at of the<br> +> > > > Bitcoin Core PR review club and will be lower level and= + more<br> +> > > > technical. That is planned for Tuesday February 23rd at= + 19:00 UTC on<br> +> > > > the IRC channel ##taproot-activation.<br> +> > > ><br> +> > > > Thanks to the meeting participants (and those who joine= +d the<br> +> > > > discussion on the channel prior and post the meeting) f= +or engaging<br> +> > > > productively and in good faith.<br> +> ><br> +> > --<br> +> > Michael Folkson<br> +> > Email:=C2=A0<a href=3D"mailto:michaelfolkson@gmail.com" target=3D= +"_blank">michaelfolkson@gmail.com</a><br> +> > Keybase: michaelfolkson<br> +> > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3<br> +> > _______________________________________________<br> +> > bitcoin-dev mailing list<br> +> > <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target= +=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br> +> > <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bit= +coin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundatio= +n.org/mailman/listinfo/bitcoin-dev</a><br> +<br> +<br> +</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"= + class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div= + dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D= +"ltr"><font face=3D"arial, helvetica, sans-serif" color=3D"#000000">Michael= + Folkson</font><div><font face=3D"arial, helvetica, sans-serif" color=3D"#0= +00000">Email:=C2=A0<a href=3D"mailto:michaelfolkson@gmail.com" target=3D"_b= +lank">michaelfolkson@gmail.com</a></font></div><div><font face=3D"arial, he= +lvetica, sans-serif" color=3D"#000000">Keybase: michaelfolkson</font></div>= +<div><font face=3D"arial, helvetica, sans-serif" color=3D"#000000">PGP: 43E= +D C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3</font></div></div></div></di= +v></div></div></div></div></div></div></div> + +--00000000000037447705bb9b5ce9-- + |