Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 28890C002D for ; Mon, 25 Apr 2022 17:00:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 16AC260A69 for ; Mon, 25 Apr 2022 17:00:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 1gGM9hLf_12H for ; Mon, 25 Apr 2022 17:00:20 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193]) by smtp3.osuosl.org (Postfix) with ESMTPS id CB59B60797 for ; Mon, 25 Apr 2022 17:00:19 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian)) id 1nj24N-00059g-Tn; Tue, 26 Apr 2022 03:00:17 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Tue, 26 Apr 2022 03:00:12 +1000 Date: Tue, 26 Apr 2022 03:00:12 +1000 From: Anthony Towns To: Keagan McClelland , Bitcoin Protocol Discussion Message-ID: <20220425170012.GA7453@erisian.com.au> References: <20220326014546.GA12225@erisian.com.au> <20220330042106.GA13161@erisian.com.au> <20220411130522.GA3633@erisian.com.au> <20220424121429.GA7363@erisian.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Score-int: -18 X-Spam-Bar: - Subject: Re: [bitcoin-dev] Speedy Trial 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, 25 Apr 2022 17:00:21 -0000 On Mon, Apr 25, 2022 at 10:11:45AM -0600, Keagan McClelland via bitcoin-dev wrote: > > Under *any* other circumstance, when they're used to activate a bad soft > > fork, speedy trial and bip8 are the same. If a resistance method works > > against bip8, it works against speedy trial; if it fails against speedy > > trial, it fails against bip8. > IIRC one essential difference between ST (which is a variant of BIP9) and > BIP8 is that since there is no mandatory signaling during the lockin > period, BIP8 doesn't have mandatory signaling during the lockin period, it has semi-mandatory [0] signalling during the must_signal period. > you can't do a counter soft fork as easily. The "counter" for bip8 activation is to reject any block during either the started or must_signal phases that would meet the threshold. In that case someone running bip8 might see blocks: [elapsed=2010, count=1813, signal=yes] [elapsed=2011, count=1813, signal=no] [elapsed=2012, count=1814, signal=yes] [elapsed=2013, count=1815, signal=yes, will-lockin!] [elapsed=2014, count=1816, signal=yes] [elapsed=2015, count=1816, signal=no] [elapsed=2016, count=1816, signal=no] [locked in!] But running software to reject the soft fork, you would reject the elapsed=2013 block, and any blocks that build on it. You would wait for someone else to mine a chain that looked like: [elapsed=2013, count=1814, signal=no] [elapsed=2014, count=1814, signal=no] [elapsed=2015, count=1814, signal=no] [elapsed=2016, count=1814, signal=no] [failed!] That approach works *exactly* the same with speedy trial. Jeremy's written code that does exactly this using the getdeploymentinfo rpc to check the deployment status, and the invalidateblock rpc to reject a block. See: https://github.com/JeremyRubin/forkd The difference to bip8 with lot=true is that nodes running speedy trial will reorg to follow the resisting chain if it has the most work. bip8 with lot=true nodes will not reorg to a failing chain, potentially creating an ongoing chain split, unless one group or the other gives up, and changes their software. Cheers, aj [0] Semi-mandatory in that only "threshold" blocks must signal, so if only 4% or 9% of miners aren't signalling and the threshold is set at 95% or 90%, no blocks will be orphaned.