Should block height or MTP (median time past defined in BIP 113) or a mixture of both be used in an activation mechanism like BIP 8 or BIP 9 for defining the timings of the state transitions?
What are the advantages and disadvantages of both and how do they compare?
Should block height or MTP (median time past [...]) or a mixture of both be used in an activation mechanism like BIP 8 or BIP 9 for defining the timings of the state transitions? What are the advantages and disadvantages of both and how do they compare?
The main advantage of MTP is that it usually roughly corresponds to wall time, so it's easy to communicate what a number means to humans. For example, BIP141 says: "the BIP9 starttime will be midnight 15 november 2016 UTC [...] and BIP9 timeout will be midnight 15 november 2017 UTC". When both of those MTP values were reached on the actual network, they were within three hours of actual UTC.
The main disadvantage of MTP is that it can be manipulated by miners. MTP is the median of the value recorded in the nTime field of the current block header and the previous 10 blocks. Miners can set their nTime values to any value greater than the current MTP and less than two hours in the future. This makes it possible for a majority of miners working for an extended amount of time to hold MTP to an old value (say 3 months ago) and then, in the space of a single block, move to a much later time (say 1 month ago). This can allow them to jump over MTP-based mandatory signaling periods such as specified in BIP148.
The main advantage of block heights is that there's no way to skip over a height-based threshold, so they make sense for flag day activations, mandatory signaling requirements, and other transitions we want to ensure happen (such as from BIP9 LOCKED_IN to ACTIVE, which happens using a relative height-based threshold of 2,016 blocks).
The main disadvantage of block heights is that they're not particularly consistent. In an average year, we expect there to be 52,596 blocks, but it would not be extraordinary for there to be 58,440 blocks---reducing an intended 12-month deployment to 10.8 months.
There's no harm in mixing MTP times and heights, and there can be significant advantages if you can take advantage of both strengths at the same time without losing too much to their weaknesses.
Using block heights for the start and timeout parameters has the advantage of giving miners a known number of signaling periods. Loss of hashpower doesn't reduce the number of retarget periods available for activation. Especially for an activation mechanism over a shorter time horizon (e.g. the Speedy Trial proposal) it may be important to ensure miners have the maximum number of signaling periods. Block heights are also arguably easier to communicate and easier to reason about as blockchain developers are used to working with them.
Using MTP (median time past) has the advantage of being able to schedule an activation at a specific time in the day to avoid activation occurring in the middle of the night for some region in the world. Concerns around hashrate decreases or increases affecting the number of signaling periods can be mitigated with selecting mid signaling period MTPs. The short duration of proposals like Speedy Trial are less sensitive to hashrate drifts changing the number of periods (a large hashrate decrease would be required to decrease the number of signalling periods).
A concern with MTP is that a coalition of miners could scale down their mined blocks at nTime to MTP + 1 to prevent reaching a MTP start time at the expected real world time. This concern seems minor as it could impact difficulty adjustments and would require broad participation from miners to limit MTP.
It is also subject to debate whether using block height consistently or using a mixture of both block heights and MTP is preferable for making the implementation and release of an alternative competing (compatible or incompatible) activation mechanism (e.g. a UASF release) more difficult or for avoiding a scalp for marketing purposes.
AJ Towns explains a disadvantage with using MTP for the minactivation point here. If activation time falls near a difficulty retarget block activation could happen the next day or in two weeks. This presents some communication challenges.
In addition:
The height at which you transition from LOCKED_IN to ACTIVE must be fully determined as soon as you transition from STARTED to LOCKED_IN. That way the entire LOCKED_IN period has to be re-orged if you want to steal funds protected by both nLocktime and the new rules.
In summary, there appears to be consensus that block heights should be used exclusively in activation mechanisms for future soft forks but it is less clear whether there is consensus to use them exclusively for the proposed Taproot activation mechanism, Speedy Trial.
For more details on the timewarp attack on MTP see this from Mark Friedenbach and this from Andrew Chow.
This answer was taken from comments on GitHub and the mailing list from Andrew Chow, AJ Towns, Jeremy Rubin, Sjors Provoost, Antoine Riard and David Harding.