path: root/70/c1912f2a72eb56320b221a2cee5e3298db8137

Return-Path: <jlrubin@mit.edu>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 15C71C000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>; Wed, 24 Mar 2021 14:10:30 -0400
Received: by mail-il1-f170.google.com with SMTP id l5so22216732ilv.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAFvNmHTtH=ohCY1e3nS5GVACzbBJs1MCEcYO-yxzRFOQqgULqQ@mail.gmail.com>
In-Reply-To: <CAFvNmHTtH=ohCY1e3nS5GVACzbBJs1MCEcYO-yxzRFOQqgULqQ@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Wed, 24 Mar 2021 11:10:17 -0700
X-Gmail-Original-Message-ID: <CAD5xwhi8f=w4htNURkZ_eDRgzoHxFYYvBmQWrqff15Spn+hTmA@mail.gmail.com>
Message-ID: <CAD5xwhi8f=w4htNURkZ_eDRgzoHxFYYvBmQWrqff15Spn+hTmA@mail.gmail.com>
To: Michael Folkson <michaelfolkson@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000c5894c05be4c3601"
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 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 <https://twitter.com/JeremyRubin>
<https://twitter.com/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
>

--000000000000c5894c05be4c3601
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">Michael,</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Your resp=
onse strikes me as ingenuine with regards to &quot;other projects&quot; as =
it is a project I understand you to be one of the parties spearheading. I t=
hink it&#39;s misleading to not clarify that in your response.<br></div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">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 &quot;weird&quot;. &quot;Weird&quot; i=
s not a technical argument, it&#39;s a normative statement.</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">As you wo=
uld ACK either full MTP or full height, but nacking &quot;mixed, seems to b=
e a fallacy of the excluded middle. </div><div class=3D"gmail_default" styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">=
<br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:#000000"> AJ&#39;s note on this where it =
is technically justified to use MTP w/ min active height  <a href=3D"https:=
//github.com/bitcoin/bitcoin/pull/21377#issuecomment-792425221" target=3D"_=
blank">https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-792425221=
</a>, as such it is not a weird choice at all. In fact, without further pat=
ching, if I understand correctly, you wouldn&#39;t want to use pure MTP wit=
hout additional logic.</div><div class=3D"gmail_default" style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div=
 class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:#000000">I further find your logic around point 2, &#39=
;To prevent a &quot;marketed push to launch a UASF client.&quot;&#39;, to m=
ore aptly apply to ST with height.</div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><=
br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:#000000"></div><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00=
0000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:#000000">Pushing for height based S=
T is causing additional review burden on contributors in service of enablin=
g a fringe group&#39;s side project. That is actually making a technical de=
cision on another project&#39;s marketing strategy, and is precisely why I =
NACK&#39;d it.</div><div class=3D"gmail_default" style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000">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&#39;s the group trying to preempt the release o=
f an ST client with a UASF client which is the fringe sentiment.</div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">For =
you to flip the exact argument that I made for rejecting ST Height onto ST =
MTP is no more than a &quot;I know you are but what am I&quot; argument, wh=
ich I do not think holds water.<br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><=
br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:#000000">Best,</div><div class=3D"gmail_de=
fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:#000000">Jeremy<br></div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br>=
</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:#000000"><br></div><div><div dir=3D"ltr" data=
-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"https://tw=
itter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https:/=
/twitter.com/JeremyRubin" target=3D"_blank"></a></div></div></div><br></div=
><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On We=
d, Mar 24, 2021 at 4:24 AM Michael Folkson &lt;<a href=3D"mailto:michaelfol=
kson@gmail.com" target=3D"_blank">michaelfolkson@gmail.com</a>&gt; wrote:<b=
r></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">Thanks for this J=
eremy. I agree with the vast majority of this.<br>
<br>
For those that missed yesterday&#39;s meeting the meeting log is here:<br>
<a href=3D"http://gnusha.org/taproot-activation/2021-03-23.log" rel=3D"nore=
ferrer" target=3D"_blank">http://gnusha.org/taproot-activation/2021-03-23.l=
og</a><br>
<br>
Jeremy also livestreamed the meeting on his Twitch channel:<br>
<a href=3D"https://www.twitch.tv/videos/960346848" rel=3D"noreferrer" targe=
t=3D"_blank">https://www.twitch.tv/videos/960346848</a><br>
<br>
On the choice between using block heights consistently or using a<br>
weird mix of both block heights and MTP in the same activation<br>
mechanism you can put me down for a NACK for the latter also.<br>
<br>
In addition I documented here the preferences for a consistent use of<br>
block height:<br>
<a href=3D"https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-80233=
6038" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/bitco=
in/pull/21377#issuecomment-802336038</a><br>
<br>
If it was a direct choice between entirely block height or entirely<br>
MTP then I probably wouldn&#39;t NACK either. But using a mix of both<br>
makes no sense to me.<br>
<br>
The two arguments in favor of using a weird mix of block heights and<br>
MTP appear to be:<br>
1) &quot;additional review required to ensure height based activation&quot;=
<br>
2) To prevent a &quot;marketed push to launch a UASF client.&quot;<br>
<br>
On 1) I would argue that the additional review required is not<br>
excessive by any means and we have the time to review a consistent use<br>
of block height (especially if people spent their time reviewing a PR<br>
with a consistent use of block height rather than arguing for a mix).<br>
On 2) if we are making technical decisions based on speculating on the<br>
marketing strategies of other projects Bitcoin Core is a very<br>
different project to the project I thought it was.<br>
<br>
I personally would find it much easier to reason about timings and<br>
time intervals of the different activation phases if block heights are<br>
used consistently across the activation mechanism rather than a weird<br>
mix of both block heights and MTP.<br>
<br>
Other than that, I agree it was an excellent meeting and thanks for<br>
your efforts organizing and hosting the meeting.<br>
<br>
-- <br>
Michael Folkson<br>
Email: <a href=3D"mailto:michaelfolkson@gmail.com" target=3D"_blank">michae=
lfolkson@gmail.com</a><br>
Keybase: michaelfolkson<br>
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3<br>
</blockquote></div>

--000000000000c5894c05be4c3601--