From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3FE8AC0001 for ; Sun, 21 Feb 2021 16:21:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 38E3985B3B for ; Sun, 21 Feb 2021 16:21:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTbGC3JpLnpG for ; Sun, 21 Feb 2021 16:21:51 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by fraxinus.osuosl.org (Postfix) with ESMTPS id E445F85B18 for ; Sun, 21 Feb 2021 16:21:51 +0000 (UTC) Received: by mail-pl1-f174.google.com with SMTP id e9so6098868plh.3 for ; Sun, 21 Feb 2021 08:21:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=q32-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=pkmRi7irXuY1/Fr92p7zo/uomM4CFcuvsOZHPNpf/o8=; b=bj0MyCq5MNZ6NAQJW2XGX8wfmA4KFWt9aHayObvAYky83281bWwUkFVZQJRUCg6Sjq fTnaqJUVzyEukupb5V08OP/tMN9DKeRDPUlkfHuZTPhXnOuhClQa/SV+62HAoLWy+/BG 0eU0LWB/p4ThMna0yIS9bBpw1iu3DxxNXnQ3YYWt+ipyR6HjwoBQuv8KTgY4XVXhxNjH g5T1AwAlhNsz/vdRXNCpPYWTy42KxruGhtjiEA7dWULh9IsR/zjOyvcS765LuMRET/HU gVMSaw5++udCUCO5bURmHy3Ms9KezHL51NVL20R1k8YP0vTkbQ8fRbNee/VtGdYtHLL1 3bRA== 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; bh=pkmRi7irXuY1/Fr92p7zo/uomM4CFcuvsOZHPNpf/o8=; b=DlyTs/g4UjnRQh54B6tpRs38mxWe1HW7knX+pohhJ1QuJ5UjylNXkxTfh4mehFDCvy 6c+RGbtOLl6+0LRupdfmMnvu2okJVYKv7anIrCNKxQ3RpkAs5jvDafaGpv/E1OEc5j40 6lGzTaeSRjfBa4umjLt+iQwyQePXNSWrn/G+g6/SgozwGbD7udJJkYSU5hpqVzdk46t1 6MeDFLBU5Kbaq9soJNsucOlTUYa4ycqsmI7VgdcBSOWhPJM46zJBE9ERQgTe7RIT8c9o iAPuVi9J6drQssJkgnSTVbHx1GzPbIyfYDuBYWXcz3zAcKnGzgWxL6p8Bh5bpu2RDRMQ 5h2Q== X-Gm-Message-State: AOAM530J39tiP0Dw1aG4vRGxXGxbFdW4xPcYtWUO3tF2CUy1rfDvReWG fl8R3R3Hw3eUxnOXCyzsmdJ/93DPTWkHxJiDgWsjlXA= X-Google-Smtp-Source: ABdhPJy3eAoqIT0iqDBSZ3qPGvij3u+yrUiy+g7Iiflw6dbEJFOhTrqCOynuxa9U4bW4IX4MFiYelIlpucTjsxzR7NA= X-Received: by 2002:a17:902:74cb:b029:e3:f43c:78f3 with SMTP id f11-20020a17090274cbb02900e3f43c78f3mr1553278plt.2.1613924511375; Sun, 21 Feb 2021 08:21:51 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Erik Aronesty Date: Sun, 21 Feb 2021 11:21:34 -0500 Message-ID: To: Michael Folkson , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000031e59505bbdb1567" X-Mailman-Approved-At: Sun, 21 Feb 2021 16:39:40 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2021 16:21:53 -0000 --00000000000031e59505bbdb1567 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think the most important thing is that the configuration setting is advertised if somebody were to query the node for its capabilities. Is this the case? That way the default value isn't really the important thing. There are longstanding and well-known nodes, for example. Community support and visibility for a UASF is the most important aspect. I looked over the threads and I don't think I saw the broadcast nature of this setting clearly discussed. On Wed, Feb 17, 2021, 10:10 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 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-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 form 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, 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 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 th= e 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. However, fro= m > 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 > > I am also aware of other current and previous Bitcoin Core > contributors and Lightning developers who didn=E2=80=99t attend the meeti= ng 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 st= rong > 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=3Dfalse. > 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 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=99= ve > 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 engaging > 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 > --00000000000031e59505bbdb1567 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think the most important thing is that the configuratio= n setting is advertised if somebody were to query the node for its capabili= ties.

Is this the case?
<= div dir=3D"auto">

That way the= default value isn't really the important thing.

There are longstanding and well-known nodes, f= or example.=C2=A0 Community support and visibility for a UASF is the most i= mportant aspect.

I looke= d over the threads and I don't think I saw the broadcast nature of this= setting clearly discussed.





On Wed, Feb 17, 2021, 10:10 AM Michael Folkson via bitcoin-dev <bitcoin-dev@lists.linuxfo= undation.org> wrote:
Yesterd= ay (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.

The meeting was announced here:
https://= lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/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 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

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 support and which had
more strong opposition towards the end of the meeting.

The conversation log is here:
http://gnusha.org/taproot-activation/2= 021-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=3Dvpl5q1ovML= M)

A summary of the meeting was provided by Luke Dashjr on Mastodon here:
https://bitcoinhackers.org/@lu= kedashjr/105742918779234566

Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we<= br> 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. However, from<= br> 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

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 them in t= he
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 minin= g pools
expressed a preference for lot=3Dfalse though I don=E2=80=99t know how stro= ng
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=3Dfalse.
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 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 engaging
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.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--00000000000031e59505bbdb1567--