On Dec 18, 2015 9:43 PM, "Peter Todd" <pete@petertodd.org> wrote:
> FWIW all these median time based schemes should be using median time past: the point is to use a time that the block creator has no direct control of, while still tying the rule to wall clock time for planning purposes.

Well, if after the "planned clock time" you need to wait for the next diff retarget and then wait for 95% (bip9) I think the value of being able to use "human friendly clock time" is very dubious (specially since median time is different from real-world time anyway).
But yeah, not giving the creator of the current block direct control over whether its block starts the activation process or not is achieved with median time of the previous block just as well as nHeight does.
So even if I disagree with the value that median time brings over the simpler height approach, let's please decide on one and always use that for both hardforks and softforks as part of bip9 (which we would need to modify).
An initial time threshold is not necessary for uncontroversial softforks, but it doesn't hurt (you can always set it in the past if you want to not use it) and in fact it simplifies bip9's implementation.
Let's please decide once and for all, update bip9 and bip99 and stop doing something different on every hardfork patch we write.