Consensus primacy: MTP → timestamps → difficulty.
In deciding the consensus in any consensus mechanism, monotonicity has primacy over timestamps. In the case of PoW, timestamps have precedence over difficulty because they are how difficulty is determined which determines PoW. No adjustment to timespan (or target for that matter) that is restricted to the difficulty calculation should be made. It doesn’t matter what difficulty algorithm you use, as long as it’s a “fair” (blind) mathematical estimate of the hashrate based on prior difficulty(ies) and solvetime(s). Changing timespan in the algorithm pollutes the math. I have seen many exploits that result from that. For example, the 4 and 1/4 timespan limits allow exploits which I previously said should exist for this theoretical reason and apparently PW believed my reasoning enough to found the exploit. He may do the same here.
So this consensus rule change should be made in the MTP calculation. When it’s at that level, it makes more intuitive sense to do it every block.
Hard-to-see “gotcha” problems involve the MTP because it’s a patch instead of strictly following monotonicity.
edit: I was having trouble figuring out what it means to say
MTP → timestamps → difficulty.
when I know that’s the theoretical requirement and yet timestamps dictate MTP. The answer prevents the exploit: it means that the “timestamps” used by the difficulty algorithm to calculate timespan must be the MTP of the 1st and 2016th blocks. Even PW’s attack on the 4x ad 1/4 timespan limits can be fixed without removing them completely if they’re turned into limits on the MTP. That is, no timestamp can be more that 3/4 * 2016 * 600 seconds into the past from the current MTP or more than 4 * 2016 * 600 into the future. If there’s a network partition for more than that limit the limit is used until real time catches up. Likewise for the past limit.
But either of these are too big of a change to implement. I don’t know of any simple solution that would make me feel comfortable in saying “it probably can’t be attack” except to make MTP=1 instead of 11. This forces true monotonicity. But as a minimum, Murch’s limit on timespan better be enforced on the timestamp instead of timespan or there’s probably an exploit.
How many times have people had to learn “don’t use timestamps for time, use the MTP”? And here we are still trying to use them for the absolute core of our consensus. Non-monotonic timestamps for any consensus mechanism are not legitimate.
It’s concerning that the “official time” for a lot of things in bitcoin like what scripts use is the MTP, but the consensus mechanism is based on timestamps. The consensus mechanism isn’t determining the value of the MTP. All nodes place an upper limit on it, so it’s how far in the past that a 51% attack, enabling an unlimited disconnect even if the difficulty can’t be exploited for excess blocks. The MTP monotonicity isn’t enforcing monotonicity on the difficulty algorithm if there’s a >51% attack which is why we had to proposed a monotonic rule on the timespan. Also, by limiting only the timespan, the consensus isn’t attesting to the value of the 1st and 2016th timestamps.
This gives two levers that miners can control without PoW.
Monotonicity on each timestamp is the only way to assure there are no unknown attacks external to the difficulty algorithm. Assuming that’s too drastic to implement (via MTP=1 instead of 11), I’d say no timestamp should be older than 1 second after the 2016th timestamp in the past. But this doesn’t address the problem of the disconnect between the difficulty timestamps and the MTP time used everywhere else. The simplest fix for that if MTP=1 can’t be used is to base the timespan on the MTP of the 1st and 2016th blocks. This wouldn’t need a limit on the timestamps.
Lamport’s 1978 paper tells us what must be done with timestamps in all consensus mechanisms to do it correctly. We can propose patches but if the rules aren’t followed, there’s an attack. The only way to let the PoW prove the 1st and 2016th timestamps and MTP are correct is to force the timestamps to be monotonic. All nodes independently prevent miners from pushing time forward. Monotonicty prevents them from holding it back.
The other rules being broken show an attack isn’t necessarily large. The other rules are that clock tick must be slower than propagation speed but a lot faster than the length of consensus rounds (1 block) and clock accuracy should be less than 1/2 clock ticks. Enforcing these rules would prevent the possibility of 1 or 2 block selfish mining attacks, is they start being a problem.
The non-repurposability requirement for good security forces the miners to act in the best interest of the value of the coin, but I believe there are instances where they won’t if they’re not required to such as maximizing fees. They can’t increase the number of blocks with the proposed fix, but can their control of the other two levers somehow increase fees or deprecate something they don’t like? What are the possible profitable consequences if miners as a group hold the MTP back 6 months and make it jump to the present in 1 block? This can’t be done without a super-majority if the timespan limit is moved out of the DA to a limit on every timestamp.
Murch’s fix seems the easiest and safest in terms of preventing an attack and not breaking anything. But a monotonicity fix should be readily available in case of an emergency. There should be a BIP.