Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 15C71C000A for ; Wed, 24 Mar 2021 18:10:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id F10F14014C for ; Wed, 24 Mar 2021 18:10:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vr6ArKqFhyX for ; Wed, 24 Mar 2021 18:10:31 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp2.osuosl.org (Postfix) with ESMTPS id 826D5400D3 for ; Wed, 24 Mar 2021 18:10:31 +0000 (UTC) Received: from mail-il1-f170.google.com (mail-il1-f170.google.com [209.85.166.170]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 12OIATWg006330 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 24 Mar 2021 14:10:30 -0400 Received: by mail-il1-f170.google.com with SMTP id l5so22216732ilv.9 for ; Wed, 24 Mar 2021 11:10:29 -0700 (PDT) X-Gm-Message-State: AOAM531jyfzSyIx0tOT5BdhgvwcJE6MdqiaBo10eVZqvY0i+DCNF8pfx SDwkKLjtV2UNDhFky8IZBQp77GiyqybYERMRTf0= X-Google-Smtp-Source: ABdhPJy9dQawoWrK683wIoS8Gk1NwX6aQzLcot1UjrnJh/mbZppUmFsr66c+6pnGadJ30pQ1qeaZHhiJsr2DkpE5X7U= X-Received: by 2002:a05:6e02:1d0e:: with SMTP id i14mr3498109ila.49.1616609429257; Wed, 24 Mar 2021 11:10:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Date: Wed, 24 Mar 2021 11:10:17 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Michael Folkson Content-Type: multipart/alternative; boundary="000000000000c5894c05be4c3601" Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes 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: Wed, 24 Mar 2021 18:10:33 -0000 --000000000000c5894c05be4c3601 Content-Type: text/plain; charset="UTF-8" Michael, Your response strikes me as ingenuine with regards to "other projects" as it is a project I understand you to be one of the parties spearheading. I think it's misleading to not clarify that in your response. Your NACK on MTP based ST does not have any merit. The only argument you made for nacking MTP based ST is it is "weird". "Weird" is not a technical argument, it's a normative statement. As you would ACK either full MTP or full height, but nacking "mixed, seems to be a fallacy of the excluded middle. AJ's note on this where it is technically justified to use MTP w/ min active height https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-792425221, as such it is not a weird choice at all. In fact, without further patching, if I understand correctly, you wouldn't want to use pure MTP without additional logic. I further find your logic around point 2, 'To prevent a "marketed push to launch a UASF client."', to more aptly apply to ST with height. Pushing for height based ST is causing additional review burden on contributors in service of enabling a fringe group's side project. That is actually making a technical decision on another project's marketing strategy, and is precisely why I NACK'd it. Even more outrageously, MTP based ST is easily compatible with a height based BIP8 LOT=true + minactiveheight client, so there really is not a good reason for the fuss. Note -- in general UASF is not the fringe group here -- it's the group trying to preempt the release of an ST client with a UASF client which is the fringe sentiment. For you to flip the exact argument that I made for rejecting ST Height onto ST MTP is no more than a "I know you are but what am I" argument, which I do not think holds water. Best, Jeremy -- @JeremyRubin On Wed, Mar 24, 2021 at 4:24 AM Michael Folkson wrote: > Thanks for this Jeremy. I agree with the vast majority of this. > > For those that missed yesterday's meeting the meeting log is here: > http://gnusha.org/taproot-activation/2021-03-23.log > > Jeremy also livestreamed the meeting on his Twitch channel: > https://www.twitch.tv/videos/960346848 > > On the choice between using block heights consistently or using a > weird mix of both block heights and MTP in the same activation > mechanism you can put me down for a NACK for the latter also. > > In addition I documented here the preferences for a consistent use of > block height: > https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-802336038 > > If it was a direct choice between entirely block height or entirely > MTP then I probably wouldn't NACK either. But using a mix of both > makes no sense to me. > > The two arguments in favor of using a weird mix of block heights and > MTP appear to be: > 1) "additional review required to ensure height based activation" > 2) To prevent a "marketed push to launch a UASF client." > > On 1) I would argue that the additional review required is not > excessive by any means and we have the time to review a consistent use > of block height (especially if people spent their time reviewing a PR > with a consistent use of block height rather than arguing for a mix). > On 2) if we are making technical decisions based on speculating on the > marketing strategies of other projects Bitcoin Core is a very > different project to the project I thought it was. > > I personally would find it much easier to reason about timings and > time intervals of the different activation phases if block heights are > used consistently across the activation mechanism rather than a weird > mix of both block heights and MTP. > > Other than that, I agree it was an excellent meeting and thanks for > your efforts organizing and hosting the meeting. > > -- > Michael Folkson > Email: michaelfolkson@gmail.com > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > --000000000000c5894c05be4c3601 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Michael,

Your resp= onse strikes me as ingenuine with regards to "other projects" as = it is a project I understand you to be one of the parties spearheading. I t= hink it's misleading to not clarify that in your response.

Y= our NACK on MTP based ST does not have any merit. The only argument you mad= e for nacking MTP based ST is it is "weird". "Weird" i= s not a technical argument, it's a normative statement.

As you wo= uld ACK either full MTP or full height, but nacking "mixed, seems to b= e a fallacy of the excluded middle.
=
AJ's note on this where it = is technically justified to use MTP w/ min active height https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-792425221= , as such it is not a weird choice at all. In fact, without further pat= ching, if I understand correctly, you wouldn't want to use pure MTP wit= hout additional logic.

I further find your logic around point 2, '= ;To prevent a "marketed push to launch a UASF client."', to m= ore aptly apply to ST with height.
<= br>

Pushing for height based S= T is causing additional review burden on contributors in service of enablin= g a fringe group's side project. That is actually making a technical de= cision on another project's marketing strategy, and is precisely why I = NACK'd it.

Even more outrageously, MTP based ST is easily compa= tible with a height based BIP8 LOT=3Dtrue + minactiveheight client, so ther= e really is not a good reason for the fuss. Note -- in general UASF is not = the fringe group here -- it's the group trying to preempt the release o= f an ST client with a UASF client which is the fringe sentiment.

For = you to flip the exact argument that I made for rejecting ST Height onto ST = MTP is no more than a "I know you are but what am I" argument, wh= ich I do not think holds water.
<= br>
Best,

Jeremy


=



On We= d, Mar 24, 2021 at 4:24 AM Michael Folkson <michaelfolkson@gmail.com> wrote:
Thanks for this J= eremy. I agree with the vast majority of this.

For those that missed yesterday's meeting the meeting log is here:
http://gnusha.org/taproot-activation/2021-03-23.l= og

Jeremy also livestreamed the meeting on his Twitch channel:
https://www.twitch.tv/videos/960346848

On the choice between using block heights consistently or using a
weird mix of both block heights and MTP in the same activation
mechanism you can put me down for a NACK for the latter also.

In addition I documented here the preferences for a consistent use of
block height:
https://github.com/bitcoin/bitco= in/pull/21377#issuecomment-802336038

If it was a direct choice between entirely block height or entirely
MTP then I probably wouldn't NACK either. But using a mix of both
makes no sense to me.

The two arguments in favor of using a weird mix of block heights and
MTP appear to be:
1) "additional review required to ensure height based activation"=
2) To prevent a "marketed push to launch a UASF client."

On 1) I would argue that the additional review required is not
excessive by any means and we have the time to review a consistent use
of block height (especially if people spent their time reviewing a PR
with a consistent use of block height rather than arguing for a mix).
On 2) if we are making technical decisions based on speculating on the
marketing strategies of other projects Bitcoin Core is a very
different project to the project I thought it was.

I personally would find it much easier to reason about timings and
time intervals of the different activation phases if block heights are
used consistently across the activation mechanism rather than a weird
mix of both block heights and MTP.

Other than that, I agree it was an excellent meeting and thanks for
your efforts organizing and hosting the meeting.

--
Michael Folkson
Email: michae= lfolkson@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
--000000000000c5894c05be4c3601--