Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id CC552C0001 for ; Wed, 3 Mar 2021 22:58:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id BEF864BAFA for ; Wed, 3 Mar 2021 22:58:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 3.604 X-Spam-Level: *** X-Spam-Status: No, score=3.604 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_BL_SPAMCOP_NET=1.246, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_RP_RNBL=1.284, RDNS_NONE=1.274, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=cock.li Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwuhOYYx31oA for ; Wed, 3 Mar 2021 22:58:20 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from mail.cock.li (unknown [37.120.193.123]) by smtp4.osuosl.org (Postfix) with ESMTPS id C4CF04B7CF for ; Wed, 3 Mar 2021 22:58:19 +0000 (UTC) MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cock.li; s=mail; t=1614812291; bh=LMEyEQGROedWRxp7PtnVeZPUIxkCyExkFLF2BHhrsDE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=gIhgj/C6zCzfehGGI7vBcp4dhdB9mOQbWbmBJSsmUw0yVXoVux5MkVmHfZecBuOfx yrFH2MAgx6Rmg7TMKT1doq0As0jkLcOq6rSM6ucaSwfQaASvAAkXRlH227Ea+H7cmp zuunAA/jYGe7aOjKe0tZX5zyHdrb6zW2ujmlkP4Uwgp+nasLAQ9viFE6Pd41jr5sUj NWNMZw/r4AMhc803Bb5QIOnBUoaMOqLDSMs8flnd+2FYYCOVI1eRZpR/pTOVI+3cM/ H4mFO4vRphvKDDM444SbTm4jHadKrKOzU63+D9T78rHX9UvzvKBYbfXJqTXMtK4Y1a aOW6UAe2sxJNw== Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 03 Mar 2021 22:58:10 +0000 From: yanmaani@cock.li To: Erik Aronesty In-Reply-To: References: <202102281933.30691.luke@dashjr.org> <20210301150614.vz557ssn2epxknjn@erisian.com.au> <86f87c6e5e4fd05c2295de2209694771@cock.li> Message-ID: <57ab51611ab99f29f82f7355bb936f67@cock.li> X-Sender: yanmaani@cock.li User-Agent: Roundcube Webmail/1.3.15 X-Mailman-Approved-At: Wed, 03 Mar 2021 22:59:34 +0000 Cc: Bitcoin Protocol Discussion 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: Wed, 03 Mar 2021 22:58:24 -0000 No, it's not the same. This approach is not guaranteed to activate. On flag day, it'd check for (say) 20% miner support, and activate if so. If >80% of miners oppose, it'd fail. LOT=true (and declining percentage) will activate unconditionally. Also, the day before lock-in, this would still have 95% as the limit, not a linear interpolation between 95% and the lock-in limit. This checks: if miner support > 95% support it (ever) or miner support > X% (on flag day), activate DP checks: if miner support > lerp(95%, 0%) (ever), activate LOT=true checks: on flag day, activate unconditionally (Erik: I forgot to hit reply all on my last e-mail, that's why you're seeing this twice) On 2021-03-02 06:11, Erik Aronesty wrote: > 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 > 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