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