Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id B8BDCC0001 for ; 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 ; 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 ; 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 ; Tue, 2 Mar 2021 06:11:30 +0000 (UTC) Received: by mail-pj1-f47.google.com with SMTP id t9so1213391pjl.5 for ; 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 Date: Tue, 2 Mar 2021 01:11:17 -0500 Message-ID: To: yanmaani@cock.li, Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
This is the declining percentage of signaling activation.=

It has all the benefits of bo= th.

Eventually it become= s a LOT=3Dtrue, so any argument for LOT=3Dtrue holds=C2=A0

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



On Mon, Mar 1, 2021, 12:05 PM yanmaani--- via bit= coin-dev <bitco= in-dev@lists.linuxfoundation.org> wrote:
How about a compromise?

With LOT=3Dfalse, taproot will be activated if at least 95% of the miners <= br> vote yes.
With LOT=3Dtrue, taproot will be activated if at least 0% of the miners vote yes.
...with LOT=3Dmaybe, 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 w= ill 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 sig= nal
>> alone,
>> despite its potential benefits, also leaves open the door to a min= er
>> 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 wa= s
> desirable to override the attempted veto, but the attempt at vetoing > nevertheless failed.
>
>> It wouldn't be much different than adding back the inflation b= ug
>> (CVE-2018-17144) and trusting miners not to exploit it.
>
> That is ridiculous FUD.
>
>> With LOT=3DFalse in the picture, however, things can get messy: >
> LOT=3Dfalse is always in the picture if we are talking about a soft-fo= rk:
> the defining feature of a soft-fork is that old node software continue= s
> 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=3DTrue), while others will = not
>> (those
>> with LOT=3DFalse)
>
> If you are following bip8 with lockinontimeout=3Dfalse, you will enfor= ce
> taproot rules if activation occurs, you will simply not reject blocks =
> if
> activation does not occur.
>
>> Users with LOT=3DTrue will still get all the safety thereof,
>> but those with LOT=3DFalse will (in the event of miners deciding t= o
>> produce a
>> chain split) face an unreliable chain, being replaced by the LOT= =3DTrue
>> chain
>> every time it overtakes the LOT=3DFalse chain in work.
>
> This assumes anyone mining the chain where taproot does not activate i= s
> not able to avoid a reorg, despite having majority hashpower (as
> implied
> by the lot=3Dtrue chain having to overtake them repeatedly). That'= s
> absurd;
> avoiding a reorg is trivially achieved via running "invalidateblo= ck",
> or
> via pool software examining block headers, or via a patch along the > lines
> of MUST_SIGNAL enforcement, but doing the opposite. For concreteness,<= br> > here's a sketch of such a patch:
>
> ht= tps://github.com/ajtowns/bitcoin/commit/f195688bd1eff3780f200e7a049e23b30ca= 4fe2f
>
>> For 2 weeks, users with LOT=3DFalse would not have a usable networ= k.
>
> 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=3DTrue being the only=
>> deployed
>> parameter, and any introduction of LOT=3DFalse only increases risk=
>> probability
>> and severity.
>
> LOT=3Dfalse is the default behaviour of everything single piece of nod= e
> 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.linuxfou= ndation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--000000000000f29efb05bc879ac9--