From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7A3BAC0001 for ; Mon, 1 Mar 2021 18:02:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 74FD76F649 for ; Mon, 1 Mar 2021 18:02:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.811 X-Spam-Level: X-Spam-Status: No, score=0.811 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 epfzle0KYVui for ; Mon, 1 Mar 2021 18:02:46 +0000 (UTC) X-Greylist: delayed 00:09:50 by SQLgrey-1.8.0 Received: from mail.emuadmin.com (mail.emuadmin.com [108.61.189.74]) by smtp3.osuosl.org (Postfix) with ESMTPS id 0561A606F1 for ; Mon, 1 Mar 2021 18:02:45 +0000 (UTC) Received: by mail.emuadmin.com (Postfix, from userid 1001) id 171A97590E; Mon, 1 Mar 2021 17:52:54 +0000 (UTC) Date: Mon, 1 Mar 2021 17:52:54 +0000 From: Emil Pfeffer To: Anthony Towns via bitcoin-dev Message-ID: <20210301175254.qjuz6vjppgkzcti7@www01.emuadmin.com> References: <202102281933.30691.luke@dashjr.org> <20210301150614.vz557ssn2epxknjn@erisian.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210301150614.vz557ssn2epxknjn@erisian.com.au> X-Mailman-Approved-At: Mon, 01 Mar 2021 22:06:15 +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: Mon, 01 Mar 2021 18:02:47 -0000 On Tue, Mar 02, 2021 at 01:06:14AM +1000, 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. You cannot prove a statement to be false by making another statement. > > > 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. That is an analogy not FUD. A strong one nevertheless but still an analogy. > > > 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. > That is the correct description of how soft-forks should work in principle. > > 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. Also correct in principle. > > 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 If lot=true has majority of hashpower it wins. Having to overtake them repeatedly assumes a 50/50 split one chain taking over the other repeatedly. In which case OP's statement that the LOT=True chain is safer holds true. > > > For 2 weeks, users with LOT=False would not have a usable network. > > That's also ridiculous FUD. In context thats not FUD and most certainly it's not ridiculous FUD. Assuming a 50/50 hashpower split the Lot=False chain has no stability till difficulty re-adjustment. > > 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. In the split scenario non-upgraded nodes don't play, right? aka they're part of both chains. > > 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. Except that when incentives change so does miner behavior. > > > 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. You are again making an "in principle" statement. > > Cheers, > aj If you meant this to be a rebuttal, it is not. It is mostly blanket statements and attacking OP. --