path: root/e7/465fbaba9eb22ee0465c0a58968ad8f564cf2d

Return-Path: <michaelfolkson@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id BC923C000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 24 Mar 2021 19:14:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 9594A40EA6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 24 Mar 2021 19:14:26 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id DUWW20Hc9lH5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 24 Mar 2021 19:14:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com
 [IPv6:2607:f8b0:4864:20::329])
 by smtp4.osuosl.org (Postfix) with ESMTPS id DA22E40E72
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 24 Mar 2021 19:14:24 +0000 (UTC)
Received: by mail-ot1-x329.google.com with SMTP id
 g8-20020a9d6c480000b02901b65ca2432cso24097054otq.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 24 Mar 2021 12:14:24 -0700 (PDT)
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:content-transfer-encoding;
 bh=+OdfsD4CoBDujbavcXfFiUhl3XhXuUuptSBnPelzrfU=;
 b=rWV+ZsJjZ5kTfKKe63CQyNdM9hqMnlDTqIwSOY2+n4Q+f5GPStOkPw9Ry0WpKs/l1T
 BOHZkC4MhmzFWFpBw3Dq8xnmZ/EPzhvl1R8m/OYW5Q0QjiF2Nbi/Boj85Awft66L5XrO
 cjlk9m6qgktRH41t0/qJMdLvZS62TnjvS7JCS7lHWFh5nVvJBlrD1sfzZiVleANLtNtb
 AgnMXLtQCfh+TDsh/Z34oTJV/f2qvf19yHh2hw6kK2C7xskpQqzDOeVmtapY2kGgxTOn
 SDhuvsEGZkGCZbCF+WUBb/2n0j86802ylwz7UFJX6NWyPIOKEw36di9uWqfhjwi8JEla
 wkqw==
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:content-transfer-encoding;
 bh=+OdfsD4CoBDujbavcXfFiUhl3XhXuUuptSBnPelzrfU=;
 b=A6Z/HqbkT3cAaWG2Q5Wo6UZkwYeWkfZ9U3x1rTuYWoA/kWKqVpyBY6CTem2eWh7OWQ
 SD1CrArpxJtOAdUFhhn5EelIvuxOlGu+hOWiTJlpJ8TuHKjfUVYHkoAGSU+GU+3xutzi
 uGL8elGuI9u0o9Djftp/LL6fTKUGV+T/UnLGAwv13ybHEfwexXQGn5RRGqKxBV9Ng1Ln
 K/bL2yaGcT9X9lTPCamWu1TS3B/Q09JOeTX6UUKKicp7HkHI1KjSvt+dD4ofEBSyG2G2
 IlfTsK+utdDrm5A1SuoOo3XgUd4G89C7LqY9ceGyVF6IDo+g2FrzWzdXJ4wExDzeRYnm
 VrZw==
X-Gm-Message-State: AOAM532myjJfRbIJT0ySEAmKFsNM75mecoAGmr87lVCtS4G7t3qbQ6Xz
 Z54D9SHORwtLTxfL4u74VaJqdBO4vMfqXudc/1A=
X-Google-Smtp-Source: ABdhPJyNS0K12sg3QcWjeQdxAJC8ZWgQAMDyMnPZd73Q6ZiLfzqquEBYYxPVcnTw4113ZP3L+RiM6gzpt2Y9l1sKwU8=
X-Received: by 2002:a05:6830:14c1:: with SMTP id
 t1mr4382799otq.305.1616613263690; 
 Wed, 24 Mar 2021 12:14:23 -0700 (PDT)
MIME-Version: 1.0
References: <CAFvNmHTtH=ohCY1e3nS5GVACzbBJs1MCEcYO-yxzRFOQqgULqQ@mail.gmail.com>
 <CAD5xwhi8f=w4htNURkZ_eDRgzoHxFYYvBmQWrqff15Spn+hTmA@mail.gmail.com>
In-Reply-To: <CAD5xwhi8f=w4htNURkZ_eDRgzoHxFYYvBmQWrqff15Spn+hTmA@mail.gmail.com>
From: Michael Folkson <michaelfolkson@gmail.com>
Date: Wed, 24 Mar 2021 19:14:12 +0000
Message-ID: <CAFvNmHR1a7e=20_Rjx0JOPOqibMxJy3J=KfoXNUeXwzb3_tzLw@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Wed, 24 Mar 2021 21:51:33 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: Wed, 24 Mar 2021 19:14:26 -0000

> 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.

I support Taproot activation and any project that can help bring that
about. As I have said many times I am 100 percent against an
incompatible UASF release with a Core ST release. However a UASF
project is well within its rights to work around finalized ST
parameters in Core to prepare for a possible (but unlikely) failed ST
deployment, *especially* in the case that Core is unable to.

> As you would ACK either full MTP or full height, but nacking "mixed, seem=
s to be a fallacy of the excluded middle.

I just prefer consistency. If you prefer inconsistency that is your
right. Although "I have a preference for fully height based design,
correct" is another of your direct quotes from 6 days ago. So NACKing
that same approach 6 days later is a touch bizarre.
https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-802396191

> 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.

"marketed push to launch a UASF client" is a direct quote from your
email. What marketing has to do with anything I have no idea. As I
said in my original response I would prefer not to make technical
decisions based on speculation for the marketing strategy of an
alternative project. That leads down a very dark road of merging in
PRs in response to "world computers" and "Turing completeness"
marketing.

Thanks
Michael

On Wed, Mar 24, 2021 at 6:10 PM Jeremy <jlrubin@mit.edu> wrote:
>
> 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, seem=
s to be a fallacy of the excluded middle.
>
> AJ's note on this where it is technically justified to use MTP w/ min act=
ive height https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-79242=
5221, 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 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 contri=
butors in service of enabling a fringe group's side project. That is actual=
ly 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 b=
ased BIP8 LOT=3Dtrue + minactiveheight client, so there really is not a goo=
d 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 UAS=
F client which is the fringe sentiment.
>
> For you to flip the exact argument that I made for rejecting ST Height on=
to 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 <michaelfolkson@gmail.com=
> 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



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