path: root/34/a41867ce2dcbba853fbe1eaa7c4ed87c129543

Return-Path: <earonesty@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B8BDCC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  2 Mar 2021 06:11:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 9988A60612
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  2 Mar 2021 06:11:31 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.397
X-Spam-Level: 
X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001,
 RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=no autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=q32-com.20150623.gappssmtp.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id jgdhFi7e_h39
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  2 Mar 2021 06:11:30 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com
 [209.85.216.47])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 592F760606
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  2 Mar 2021 06:11:30 +0000 (UTC)
Received: by mail-pj1-f47.google.com with SMTP id t9so1213391pjl.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 01 Mar 2021 22:11:30 -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
 :cc; bh=/FBdiYH3shindbCAe2YxLRxkpsauDm8SpvcNMtTqs5k=;
 b=VsjI24BhFV/su0rSxHG2LasEnZn/ldjG311P0lkS095H4WVOUWF55iqY0eMNXJLicY
 dl01qTbhCoqmpqYXu0cF0IQezomx6SWtZqVf5VhHTN7L2ezTQF/EB7zPjcG3df1rMCae
 ivwkFQ9fEGv4gdVmAtu9ltpMf3LplZKAkJkZJxVOyobCwkfZ4gStt61pMvue/wCrnx8i
 RaTj65rxgrMi4Rw00eDzmu6VPOvU+fIRVVGc0lbFvJeh9sf9ntYZXa7PZvchcJcvZeET
 d4/xNE1ASrHsTLu44eOlY4AHyvQctg6rMj2+fSAMWFc2bk6QO+UPrF5FwI2ppuvqI9Eo
 nWPA==
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;
 bh=/FBdiYH3shindbCAe2YxLRxkpsauDm8SpvcNMtTqs5k=;
 b=X54zpRTsWEgEx7sX7Z+6fUjlDRHLPsUupBm0bD0GTot/MT7qJIQf04FI7YJL/iEvDU
 ZtFAqLPanfCp0OPP9gpNZ+KI/Lzg+3qvsjdD/VdZN3p0wcwQXQiqHNxJghNihJqGWNd6
 j1yguuq9YWiIxkmLyOZa/avXdL1ekOcukcfQnp/jKmIRdTiMfUIN9VvjE6qzHjTWJDXf
 dw3NwAk5+4KsnAuK6e0GTGjlSdaa1B60NADwvRLm4QK4UbbfdOGzGRvedjOVhsECqt/D
 xgDWMO5FFnSfJHU4wawWbu22Z1TVrEMNkbreEC/FeSsPPveOETmI1f65hMbGGLHiwuQm
 H8cQ==
X-Gm-Message-State: AOAM531wgkS7O8hdD1dbG3Nj494XUIdiMpTYNAG8a97/0Tutbi7MU1Bi
 r8jWUN6bRk0Cv9kxm8ehNwrfr0dYl44E7e5vwTtBkoI=
X-Google-Smtp-Source: ABdhPJzP1tNga+sseLOQdt3dKixQHtokdOqwDYB32dz9X15egY4mzpNrGCSXeoxWtulmzX2IR+/uxYUAY3hfLLQ9gKo=
X-Received: by 2002:a17:902:dac9:b029:e4:b52f:1d38 with SMTP id
 q9-20020a170902dac9b02900e4b52f1d38mr2286414plx.15.1614665489749; Mon, 01 Mar
 2021 22:11:29 -0800 (PST)
MIME-Version: 1.0
References: <202102281933.30691.luke@dashjr.org>
 <20210301150614.vz557ssn2epxknjn@erisian.com.au>
 <86f87c6e5e4fd05c2295de2209694771@cock.li>
In-Reply-To: <86f87c6e5e4fd05c2295de2209694771@cock.li>
From: Erik Aronesty <erik@q32.com>
Date: Tue, 2 Mar 2021 01:11:17 -0500
Message-ID: <CAJowKgLWfc8WJF9guy_3nztBm=iJ9+jWRMEg-Vadj9cdXGvkFA@mail.gmail.com>
To: yanmaani@cock.li, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000f29efb05bc879ac9"
X-Mailman-Approved-At: Tue, 02 Mar 2021 07:58:13 +0000
Subject: Re: [bitcoin-dev] LOT=False is dangerous and shouldn't be used
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: Tue, 02 Mar 2021 06:11:31 -0000

--000000000000f29efb05bc879ac9
Content-Type: text/plain; charset="UTF-8"

This is the declining percentage of signaling activation.

It has all the benefits of both.

Eventually it becomes a LOT=true, so any argument for LOT=true holds

And all of the arguments for LOT=false are satisfied by the cool down
period.



On Mon, Mar 1, 2021, 12:05 PM yanmaani--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> How about a compromise?
>
> With LOT=false, taproot will be activated if at least 95% of the miners
> vote yes.
> With LOT=true, taproot will be activated if at least 0% of the miners
> vote yes.
> ...with LOT=maybe, taproot will be activated if at least ~some% of the
> miners vote yes?
>
> If you want the 'emergency cancel' feature without binding yourself to
> it, couldn't you have some middle-of-the-road solution? "Taproot will be
> enabled if miner support ever goes above 95%, or on flag day if miner
> support is >20% then". That would prevent obstreperous miners from doing
> too much damage, while still hopefully making it possible to bail out of
> a disaster.
>
> On 2021-03-01 15:06, Anthony Towns via bitcoin-dev wrote:
> > On Sun, Feb 28, 2021 at 07:33:30PM +0000, Luke Dashjr via bitcoin-dev
> > wrote:
> >> As we saw in 2017 with BIP 9, coordinating activation by miner signal
> >> alone,
> >> despite its potential benefits, also leaves open the door to a miner
> >> veto.
> >
> > To the contrary, we saw in 2017 that miners could *not* successfully
> > veto a BIP 9 activation. It was certainly more effort and risk than was
> > desirable to override the attempted veto, but the attempt at vetoing
> > nevertheless failed.
> >
> >> It wouldn't be much different than adding back the inflation bug
> >> (CVE-2018-17144) and trusting miners not to exploit it.
> >
> > That is ridiculous FUD.
> >
> >> With LOT=False in the picture, however, things can get messy:
> >
> > LOT=false is always in the picture if we are talking about a soft-fork:
> > the defining feature of a soft-fork is that old node software continues
> > to work, and old node software will be entirely indifferent to whether
> > activation is signalled or not.
> >
> >> some users will
> >> enforce Taproot(eg) (those running LOT=True), while others will not
> >> (those
> >> with LOT=False)
> >
> > If you are following bip8 with lockinontimeout=false, you will enforce
> > taproot rules if activation occurs, you will simply not reject blocks
> > if
> > activation does not occur.
> >
> >> Users with LOT=True will still get all the safety thereof,
> >> but those with LOT=False will (in the event of miners deciding to
> >> produce a
> >> chain split) face an unreliable chain, being replaced by the LOT=True
> >> chain
> >> every time it overtakes the LOT=False chain in work.
> >
> > This assumes anyone mining the chain where taproot does not activate is
> > not able to avoid a reorg, despite having majority hashpower (as
> > implied
> > by the lot=true chain having to overtake them repeatedly). That's
> > absurd;
> > avoiding a reorg is trivially achieved via running "invalidateblock",
> > or
> > via pool software examining block headers, or via a patch along the
> > lines
> > of MUST_SIGNAL enforcement, but doing the opposite. For concreteness,
> > here's a sketch of such a patch:
> >
> >
> https://github.com/ajtowns/bitcoin/commit/f195688bd1eff3780f200e7a049e23b30ca4fe2f
> >
> >> For 2 weeks, users with LOT=False would not have a usable network.
> >
> > That's also ridiculous FUD.
> >
> > If it were true, it would mean the activation mechanism was not
> > acceptable, as non-upgraded nodes would also not have a usable network
> > for the same reason.
> >
> > Fortunately, it's not true.
> >
> > More generally, if miners are willing to lose significant amounts of
> > money mining orphan blocks, they can do that at any time. If they're
> > not inclined to do so, it's incredibly straightforward for them to
> > avoid
> > doing so, whatever a minority of other miners might do.
> >
> >> The overall risk is maximally reduced by LOT=True being the only
> >> deployed
> >> parameter, and any introduction of LOT=False only increases risk
> >> probability
> >> and severity.
> >
> > LOT=false is the default behaviour of everything single piece of node
> > software out there. That behaviour doesn't need to be introduced, it's
> > already universal.
> >
> > Cheers,
> > aj
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"auto">This is the declining percentage of signaling activation.=
<div dir=3D"auto"><br></div><div dir=3D"auto">It has all the benefits of bo=
th.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Eventually it become=
s a LOT=3Dtrue, so any argument for LOT=3Dtrue holds=C2=A0</div><div dir=3D=
"auto"><br></div><div dir=3D"auto">And all of the arguments for LOT=3Dfalse=
 are satisfied by the cool down period.</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto"><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"=
ltr" class=3D"gmail_attr">On Mon, Mar 1, 2021, 12:05 PM yanmaani--- via bit=
coin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">How about a compromise?<br>
<br>
With LOT=3Dfalse, taproot will be activated if at least 95% of the miners <=
br>
vote yes.<br>
With LOT=3Dtrue, taproot will be activated if at least 0% of the miners <br=
>
vote yes.<br>
...with LOT=3Dmaybe, taproot will be activated if at least ~some% of the <b=
r>
miners vote yes?<br>
<br>
If you want the &#39;emergency cancel&#39; feature without binding yourself=
 to <br>
it, couldn&#39;t you have some middle-of-the-road solution? &quot;Taproot w=
ill be <br>
enabled if miner support ever goes above 95%, or on flag day if miner <br>
support is &gt;20% then&quot;. That would prevent obstreperous miners from =
doing <br>
too much damage, while still hopefully making it possible to bail out of <b=
r>
a disaster.<br>
<br>
On 2021-03-01 15:06, Anthony Towns via bitcoin-dev wrote:<br>
&gt; On Sun, Feb 28, 2021 at 07:33:30PM +0000, Luke Dashjr via bitcoin-dev =
<br>
&gt; wrote:<br>
&gt;&gt; As we saw in 2017 with BIP 9, coordinating activation by miner sig=
nal <br>
&gt;&gt; alone,<br>
&gt;&gt; despite its potential benefits, also leaves open the door to a min=
er <br>
&gt;&gt; veto.<br>
&gt; <br>
&gt; To the contrary, we saw in 2017 that miners could *not* successfully<b=
r>
&gt; veto a BIP 9 activation. It was certainly more effort and risk than wa=
s<br>
&gt; desirable to override the attempted veto, but the attempt at vetoing<b=
r>
&gt; nevertheless failed.<br>
&gt; <br>
&gt;&gt; It wouldn&#39;t be much different than adding back the inflation b=
ug<br>
&gt;&gt; (CVE-2018-17144) and trusting miners not to exploit it.<br>
&gt; <br>
&gt; That is ridiculous FUD.<br>
&gt; <br>
&gt;&gt; With LOT=3DFalse in the picture, however, things can get messy:<br=
>
&gt; <br>
&gt; LOT=3Dfalse is always in the picture if we are talking about a soft-fo=
rk:<br>
&gt; the defining feature of a soft-fork is that old node software continue=
s<br>
&gt; to work, and old node software will be entirely indifferent to whether=
<br>
&gt; activation is signalled or not.<br>
&gt; <br>
&gt;&gt; some users will<br>
&gt;&gt; enforce Taproot(eg) (those running LOT=3DTrue), while others will =
not <br>
&gt;&gt; (those<br>
&gt;&gt; with LOT=3DFalse)<br>
&gt; <br>
&gt; If you are following bip8 with lockinontimeout=3Dfalse, you will enfor=
ce<br>
&gt; taproot rules if activation occurs, you will simply not reject blocks =
<br>
&gt; if<br>
&gt; activation does not occur.<br>
&gt; <br>
&gt;&gt; Users with LOT=3DTrue will still get all the safety thereof,<br>
&gt;&gt; but those with LOT=3DFalse will (in the event of miners deciding t=
o <br>
&gt;&gt; produce a<br>
&gt;&gt; chain split) face an unreliable chain, being replaced by the LOT=
=3DTrue <br>
&gt;&gt; chain<br>
&gt;&gt; every time it overtakes the LOT=3DFalse chain in work.<br>
&gt; <br>
&gt; This assumes anyone mining the chain where taproot does not activate i=
s<br>
&gt; not able to avoid a reorg, despite having majority hashpower (as <br>
&gt; implied<br>
&gt; by the lot=3Dtrue chain having to overtake them repeatedly). That&#39;=
s <br>
&gt; absurd;<br>
&gt; avoiding a reorg is trivially achieved via running &quot;invalidateblo=
ck&quot;, <br>
&gt; or<br>
&gt; via pool software examining block headers, or via a patch along the <b=
r>
&gt; lines<br>
&gt; of MUST_SIGNAL enforcement, but doing the opposite. For concreteness,<=
br>
&gt; here&#39;s a sketch of such a patch:<br>
&gt; <br>
&gt; <a href=3D"https://github.com/ajtowns/bitcoin/commit/f195688bd1eff3780=
f200e7a049e23b30ca4fe2f" rel=3D"noreferrer noreferrer" target=3D"_blank">ht=
tps://github.com/ajtowns/bitcoin/commit/f195688bd1eff3780f200e7a049e23b30ca=
4fe2f</a><br>
&gt; <br>
&gt;&gt; For 2 weeks, users with LOT=3DFalse would not have a usable networ=
k.<br>
&gt; <br>
&gt; That&#39;s also ridiculous FUD.<br>
&gt; <br>
&gt; If it were true, it would mean the activation mechanism was not<br>
&gt; acceptable, as non-upgraded nodes would also not have a usable network=
<br>
&gt; for the same reason.<br>
&gt; <br>
&gt; Fortunately, it&#39;s not true.<br>
&gt; <br>
&gt; More generally, if miners are willing to lose significant amounts of<b=
r>
&gt; money mining orphan blocks, they can do that at any time. If they&#39;=
re<br>
&gt; not inclined to do so, it&#39;s incredibly straightforward for them to=
 <br>
&gt; avoid<br>
&gt; doing so, whatever a minority of other miners might do.<br>
&gt; <br>
&gt;&gt; The overall risk is maximally reduced by LOT=3DTrue being the only=
 <br>
&gt;&gt; deployed<br>
&gt;&gt; parameter, and any introduction of LOT=3DFalse only increases risk=
 <br>
&gt;&gt; probability<br>
&gt;&gt; and severity.<br>
&gt; <br>
&gt; LOT=3Dfalse is the default behaviour of everything single piece of nod=
e<br>
&gt; software out there. That behaviour doesn&#39;t need to be introduced, =
it&#39;s<br>
&gt; already universal.<br>
&gt; <br>
&gt; Cheers,<br>
&gt; aj<br>
&gt; <br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfou=
ndation.org/mailman/listinfo/bitcoin-dev</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000f29efb05bc879ac9--