I say keep it simple. If the 75% threshold is hit, then support suddenly drops off below 50%, "meh" -- there will be a big ruckus, everybody will freak out, and miners will refuse to build big blocks because they'll worry that they'll get orphaned.
Adding more complexity for a case that ain't gonna happen (and isn't a disaster if it does) is a mistake, in my humble opinion. On Wed, Sep 23, 2015 at 2:33 PM, Tom Harding via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 9/13/2015 11:56 AM, Rusty Russell via bitcoin-dev wrote: > >> '''Success: Activation Delay''' >> The consensus rules related to ''locked-in'' soft fork will be enforced in >> the second retarget period; ie. there is a one retarget period in >> which the remaining 5% can upgrade. At the that activation block and >> after, the bit B may be reused for a different soft fork. >> >> > Rather than a simple one-period delay, should there be a one-period > "burn-in" to show sustained support of the threshold? During this period, > support must continuously remain above the threshold. Any lapse resets to > inactivated state. > > With a simple delay, you can have the embarrassing situation where support > falls off during the delay period and there is far below threshold support > just moments prior to enforcement, but enforcement happens anyway. > > BIP 101 has this problem too. > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- -- Gavin Andresen
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
