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. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev