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 B8D51C0001 for ; Mon, 1 Mar 2021 17:00:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 9F3786F5F3 for ; Mon, 1 Mar 2021 17:00:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 4.028 X-Spam-Level: **** X-Spam-Status: No, score=4.028 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_RP_RNBL=1.31, RDNS_NONE=0.793, SPF_HELO_PASS=-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=cock.li 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 6aDL0Dia4p5Q for ; Mon, 1 Mar 2021 17:00:45 +0000 (UTC) X-Greylist: delayed 00:06:32 by SQLgrey-1.8.0 Received: from mail.cock.li (unknown [37.120.193.123]) by smtp3.osuosl.org (Postfix) with ESMTPS id AC37060655 for ; Mon, 1 Mar 2021 17:00:44 +0000 (UTC) MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cock.li; s=mail; t=1614617648; bh=lkqK2nDLr12PEasotKmtagCTaThHVHdt3jEsaayZStk=; h=Date:From:To:Subject:In-Reply-To:References:From; b=kmahM0gkjmqa08z5XrVYcgr5zQRlAnZRSewcyWtKmmqwEtyb6DoEOWWmTBLGfvEcE U1zSeH3CotBlKhQSc04CwUynx7GDI8le8IgbJKUu5MidAtDD/8yrYpA9h2SeL6vuXi it0Jy+8vJaFkEGhbkKD4xOi+jCeYOLaLlk6Wn3Rm01vmugsLCal8QPiPnrEqxtw3bu aFjl3rq/kdkoaaLUPhAq802b2IrHlnJz8ovoH9hKd242+6FIVwyqEKbfvGHsUPOUun D6SwEkxkr0OZDuZksYWUp0Uemime52Eth9PKtAscKOFRIM0+P5A2M32AWHTEp0TVSm MGNU0cRZx9wSw== Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 01 Mar 2021 16:54:07 +0000 From: yanmaani@cock.li To: Anthony Towns , Bitcoin Protocol Discussion In-Reply-To: <20210301150614.vz557ssn2epxknjn@erisian.com.au> References: <202102281933.30691.luke@dashjr.org> <20210301150614.vz557ssn2epxknjn@erisian.com.au> Message-ID: <86f87c6e5e4fd05c2295de2209694771@cock.li> X-Sender: yanmaani@cock.li User-Agent: Roundcube Webmail/1.3.15 X-Mailman-Approved-At: Mon, 01 Mar 2021 17:05:11 +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 17:00:48 -0000 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