Tom Harding via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes: > 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.
Yeah, but Gavin's right. If you can't account for all the corner cases, all you can do is keep it simple and well defined. Thanks, Rusty. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
