(Replies to multiple emails)

On Tue, Apr 06, 2021 at 12:27:34PM -0400, Russell O'Connor wrote:
> It isn't  "$MIN_LOCKIN_TIME + $((10 * 2016)) minutes". It's
> "$MIN_LOCKIN_TIME + time until next retargeting period + $((10 * 2016))
> minutes".

Ah, drat, I forgot about that.  Thank you for correcting my oversight!

> That doesn't seem like a particularly important design goal to me? Having
> a last minute two week delay seems easy to deal with

From my perspective, that of a person focused on communicating
information that affects Bitcoin users and recommending infrastructure
adjustments that should be made to accomodate those changes, I'd find
having a predictable activation date to be of significant benefit.
Given that, an activation scheme that could provide a tight timeline
(only delayable, not accellerable, by miner shenanegeans) would be
something I'd consider an advantage of that method.

That said, it's probably not worth making the activation state machine
more complicated for when the simplicity of the machine for height-based
activations is it's chief touted benefit.

Thanks,

-Dave