Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2022-04-25 📝 Original message:On Mon, Apr 25, 2022 at ...
📅 Original date posted:2022-04-25
📝 Original message: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.
📝 Original message: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.