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 <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco= in-dev@lists.linuxfoundation.org</a>> 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 'emergency cancel' feature without binding yourself= to <br> it, couldn't you have some middle-of-the-road solution? "Taproot w= ill be <br> enabled if miner support ever goes above 95%, or on flag day if miner <br> support is >20% then". 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> > On Sun, Feb 28, 2021 at 07:33:30PM +0000, Luke Dashjr via bitcoin-dev = <br> > wrote:<br> >> As we saw in 2017 with BIP 9, coordinating activation by miner sig= nal <br> >> alone,<br> >> despite its potential benefits, also leaves open the door to a min= er <br> >> veto.<br> > <br> > To the contrary, we saw in 2017 that miners could *not* successfully<b= r> > veto a BIP 9 activation. It was certainly more effort and risk than wa= s<br> > desirable to override the attempted veto, but the attempt at vetoing<b= r> > nevertheless failed.<br> > <br> >> It wouldn't be much different than adding back the inflation b= ug<br> >> (CVE-2018-17144) and trusting miners not to exploit it.<br> > <br> > That is ridiculous FUD.<br> > <br> >> With LOT=3DFalse in the picture, however, things can get messy:<br= > > <br> > LOT=3Dfalse is always in the picture if we are talking about a soft-fo= rk:<br> > the defining feature of a soft-fork is that old node software continue= s<br> > to work, and old node software will be entirely indifferent to whether= <br> > activation is signalled or not.<br> > <br> >> some users will<br> >> enforce Taproot(eg) (those running LOT=3DTrue), while others will = not <br> >> (those<br> >> with LOT=3DFalse)<br> > <br> > If you are following bip8 with lockinontimeout=3Dfalse, you will enfor= ce<br> > taproot rules if activation occurs, you will simply not reject blocks = <br> > if<br> > activation does not occur.<br> > <br> >> Users with LOT=3DTrue will still get all the safety thereof,<br> >> but those with LOT=3DFalse will (in the event of miners deciding t= o <br> >> produce a<br> >> chain split) face an unreliable chain, being replaced by the LOT= =3DTrue <br> >> chain<br> >> every time it overtakes the LOT=3DFalse chain in work.<br> > <br> > This assumes anyone mining the chain where taproot does not activate i= s<br> > not able to avoid a reorg, despite having majority hashpower (as <br> > implied<br> > by the lot=3Dtrue chain having to overtake them repeatedly). That'= s <br> > absurd;<br> > avoiding a reorg is trivially achieved via running "invalidateblo= ck", <br> > or<br> > via pool software examining block headers, or via a patch along the <b= r> > lines<br> > of MUST_SIGNAL enforcement, but doing the opposite. For concreteness,<= br> > here's a sketch of such a patch:<br> > <br> > <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> > <br> >> For 2 weeks, users with LOT=3DFalse would not have a usable networ= k.<br> > <br> > That's also ridiculous FUD.<br> > <br> > If it were true, it would mean the activation mechanism was not<br> > acceptable, as non-upgraded nodes would also not have a usable network= <br> > for the same reason.<br> > <br> > Fortunately, it's not true.<br> > <br> > More generally, if miners are willing to lose significant amounts of<b= r> > money mining orphan blocks, they can do that at any time. If they'= re<br> > not inclined to do so, it's incredibly straightforward for them to= <br> > avoid<br> > doing so, whatever a minority of other miners might do.<br> > <br> >> The overall risk is maximally reduced by LOT=3DTrue being the only= <br> >> deployed<br> >> parameter, and any introduction of LOT=3DFalse only increases risk= <br> >> probability<br> >> and severity.<br> > <br> > LOT=3Dfalse is the default behaviour of everything single piece of nod= e<br> > software out there. That behaviour doesn't need to be introduced, = it's<br> > already universal.<br> > <br> > Cheers,<br> > aj<br> > <br> > _______________________________________________<br> > bitcoin-dev mailing list<br> > <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= ank" 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.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--