path: root/b5/b1eb063f9845fc5101b72af1cc94bdcbb2316d

Return-Path: <jlrubin@mit.edu>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 5167FC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 28 Feb 2021 19:44:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 342C2834D5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 28 Feb 2021 19:44:09 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.101
X-Spam-Level: 
X-Spam-Status: No, score=0.101 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id mUhdk4NG4dPM
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 28 Feb 2021 19:44:07 +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 smtp1.osuosl.org (Postfix) with ESMTPS id AC3C4834BA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 28 Feb 2021 19:44:07 +0000 (UTC)
Received: from mail-io1-f41.google.com (mail-io1-f41.google.com
 [209.85.166.41]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 11SJi5nm006145
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 28 Feb 2021 14:44:06 -0500
Received: by mail-io1-f41.google.com with SMTP id o9so496123iow.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 28 Feb 2021 11:44:05 -0800 (PST)
X-Gm-Message-State: AOAM530Oj9hWxq0/SpbvrtzKNErbA4jmOOtN3PG+64WBMI2C/es3EDjS
 Aiz9FLJiTHHUoqb5vPByL6hoF93MnkYK7fNLFUc=
X-Google-Smtp-Source: ABdhPJy/Zy2rPMTdO3jL2OWcLzdgnvdW9O46SqrNZbNGGDhcxun77cnOLjsmP9DhhrL+Ct1DvelP4EyyvlRNq8nmuEk=
X-Received: by 2002:a5d:9245:: with SMTP id e5mr11046991iol.97.1614541445121; 
 Sun, 28 Feb 2021 11:44:05 -0800 (PST)
MIME-Version: 1.0
References: <c35e1761-43ca-e157-6a5c-72d27f2c6c6e@mattcorallo.com>
 <202102281720.07392.luke@dashjr.org>
 <c6a7a7ab-ee68-6594-ebd0-60f38ba40c37@mattcorallo.com>
In-Reply-To: <c6a7a7ab-ee68-6594-ebd0-60f38ba40c37@mattcorallo.com>
From: Jeremy <jlrubin@mit.edu>
Date: Sun, 28 Feb 2021 11:43:53 -0800
X-Gmail-Original-Message-ID: <CAD5xwhhRCBa86B0ApZ=VioZngREOh1bth4H=zk69k4xsZc9d0Q@mail.gmail.com>
Message-ID: <CAD5xwhhRCBa86B0ApZ=VioZngREOh1bth4H=zk69k4xsZc9d0Q@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000004fcccf05bc6ab997"
Subject: Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
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: Sun, 28 Feb 2021 19:44:09 -0000

--0000000000004fcccf05bc6ab997
Content-Type: text/plain; charset="UTF-8"

I agree with much of the logic presented by Matt here.

BIP8 was intended to be simpler to agree on to maintain consensus, yet we
find ourselves in a situation where a "tiny" parameter has the potential to
cause great network disruption and confusion (rationality is not too useful
a concept here given differing levels of sophistication and information).
It is therefore much simpler and more likely to be universally understood
by all network participants to just have a flag day. It is easier to
communicate what users should do and when.

This is ultimately not coercive to users because the upgrade for Taproot
itself is provable and analyzable on its own, but activation parameters
based on what % of economically relevant nodes are running an upgrade by a
certain date are not. Selecting these sorts of complicated consensus
parameters may ultimately present more opportunity for a cooptable
consensus process than something more straightforward.


That said, a few points strike me as worth delving into.


1) Con: Mandatory signalling is no different than a flag day. Mandatory
signaling is effectively 2 flag days -- one for the signaling rule, 1 for
the taproot type. The reason for the 2 week gap between flag day for
signaling and flag day for taproot rules is, more or less, so that nodes
who aren't taproot ready at the 1st flag day do not end up SPV mining
(using standardness rules in mempool prevents them from mining an invalid
block on top of a valid tip, but does not ensure the tip is valid).
2) Con: Releasing a flag day without releasing the LOT=true code leading up
to that flag day means that clients would not be fully compatible with an
early activation that could be proposed before the flag day is reached.
E.g., LOT=true is a flag day that retains the possibility of being
compatible with other BIP8 releases without changing software.
3) Pro: BIP-8 is partially in service of "early activation" and . I'm
personally skeptical that early activation is/was ever a good idea. A fixed
activation date may be largely superior for business purposes, software
engineering schedules, etc. I think even with signaling BIP8, it would be
possibly superior to activate rules at a fixed date (or a quantized set of
fixed dates, e.g. guaranteeing at least 3 months but maybe more).
4) Pro: part of the argument for BIP-8=false is that it is possible that
the rule could not activate, if signaling does not occur, providing
additional stopgap against dev collusion and bugs. But BIP-8 can activate
immediately (with start times being proposed 1 month after release?) so we
don't have certainty around how much time there is for that secondary
review process (read -- I think it isn't that valuable) and if there *is* a
deadly bug discovered, we might want to hard-fork to fix it even if it
isn't yet signaled for (e.g., if the rule activates it enables more mining
reward). So I think that it's a healthier mindset to release a with
definite deadline and not rule out having to do a hard fork if there is a
grave issue (we shouldn't ever release a SF if we think this is at all
likely, mind you).
5) Con: It's already taken so long for taproot, the schedule around taproot
was based on the idea it could early activate, 2022 is now too far away. I
don't know how to defray this other than, if your preferred idea is 1 year
flag day, to do that via LOT=true so that taproot can still have early
activation if desired.

Overall I agree with the point that all the contention around LOT, makes a
flag day look not so bad. And something closer to a flag day might not be
so bad either for future forks as well.

However, I think given the appetite for early activation, if a flag day is
desired I think LOT=true is the best option at this time as it allows our
flag day to remain compatible with such an early activation.

I think we can also clearly communicate that LOT=true for Taproot is not a
precedent setting occurence for any future forks (hold me accountable to
not using this as precedent this should I ever advocate for a SF with
similar release parameters).

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

<div dir=3D"ltr"><div style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:rgb(0,0,0)" class=3D"gmail_default">I agree with much of t=
he logic presented by Matt here.</div><div style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><=
br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)" class=3D"gmail_default">BIP8 was intended to be simple=
r to agree on to maintain consensus, yet we find ourselves in a situation w=
here a &quot;tiny&quot; parameter has the potential to cause great network =
disruption and confusion (rationality is not too useful a concept here give=
n differing levels of sophistication and information). It is therefore much=
 simpler and more likely to be universally understood by all network partic=
ipants to just have a flag day. It is easier to communicate what users shou=
ld do and when.</div><div style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,=
0)" class=3D"gmail_default">This is ultimately not coercive to users becaus=
e the upgrade for Taproot itself is provable and analyzable on its own, but=
 activation parameters based on what % of economically relevant nodes are r=
unning an upgrade by a certain date are not. Selecting these sorts of compl=
icated consensus parameters may ultimately present more opportunity for a c=
ooptable consensus process than something more straightforward.<br></div><d=
iv style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg=
b(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_defa=
ult"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:rgb(0,0,0)" class=3D"gmail_default">That said, a few points =
strike me as worth delving into.</div><div style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><=
br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D=
"gmail_default">1) Con: Mandatory signalling is no different than a flag da=
y. Mandatory signaling is effectively 2 flag days -- one for the signaling =
rule, 1 for the taproot  type. The reason for the 2 week gap between flag d=
ay for signaling and flag day for taproot rules is, more or less, so that n=
odes who aren&#39;t taproot ready at the 1st flag day do not end up SPV min=
ing (using standardness rules in mempool prevents them from mining an inval=
id block on top of a valid tip, but does not ensure the tip is valid).<br><=
/div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)" class=3D"gmail_default">2) Con: Releasing a flag day witho=
ut releasing the LOT=3Dtrue code leading up to that flag day means that cli=
ents would not be fully compatible with an early activation that could be p=
roposed before the flag day is reached. E.g., LOT=3Dtrue is a flag day that=
 retains the possibility of being compatible with other BIP8 releases witho=
ut changing software.<br></div><div style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">3) Pro: =
BIP-8 is partially in service of &quot;early activation&quot; and . I&#39;m=
 personally skeptical that early activation is/was ever a good idea. A fixe=
d activation date may be largely superior for business purposes, software e=
ngineering schedules, etc. I think even with signaling BIP8, it would be po=
ssibly superior to activate rules at a fixed date (or a quantized set of fi=
xed dates, e.g. guaranteeing at least 3 months but maybe more).<br></div><d=
iv style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg=
b(0,0,0)" class=3D"gmail_default">4) Pro: part of the argument for BIP-8=3D=
false is that it is possible that the rule could not activate, if signaling=
 does not occur, providing additional stopgap against dev collusion and bug=
s. But BIP-8 can activate immediately (with start times being proposed 1 mo=
nth after release?) so we don&#39;t have certainty around how much time the=
re is for that secondary review process (read -- I think it isn&#39;t that =
valuable) and if there *is* a deadly bug discovered, we might want to hard-=
fork to fix it even if it isn&#39;t yet signaled for (e.g., if the rule act=
ivates it enables more mining reward). So I think that it&#39;s a healthier=
 mindset to release a with definite deadline and not rule out having to do =
a hard fork if there is a grave issue (we shouldn&#39;t ever release a SF i=
f we think this is at all likely, mind you).<br></div><div style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"=
gmail_default">5) Con: It&#39;s already taken so long for taproot, the sche=
dule around taproot was based on the idea it could early activate, 2022 is =
now too far away. I don&#39;t know how to defray this other than, if your p=
referred idea is 1 year flag day, to do that via LOT=3Dtrue so that taproot=
 can still have early activation if desired.<br></div><div style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"=
gmail_default"><br></div><div style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">Overall I agre=
e with the point that all the contention around LOT, makes a flag day look =
not so bad. And something closer to a flag day might not be so bad either f=
or future forks as well.</div><div style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div=
><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:rgb(0,0,0)" class=3D"gmail_default">However, I think given the appetite fo=
r early activation, if a flag day is desired I think LOT=3Dtrue is the best=
 option at this time as it allows our flag day to remain compatible with su=
ch an early activation.<br></div><div style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></=
div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:rgb(0,0,0)" class=3D"gmail_default">I think we can also clearly communi=
cate that LOT=3Dtrue for Taproot is not a precedent setting occurence for a=
ny future forks (hold me accountable to not using this as precedent this sh=
ould I ever advocate for a SF with similar release parameters).<br></div><d=
iv style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg=
b(0,0,0)" class=3D"gmail_default"><br></div></div>

--0000000000004fcccf05bc6ab997--