Why isn't the upper bound (+2h) on the block timestamp set as a consensus rule?

Question

Why isn't the +2h acceptance rule part of the consensus? Of course, then it couldn't be based on network-adjusted time + 2h because, in edge cases, one part of the network might accept something while the other part would have to wait a bit, but why wasn't it set, for example, so that the lower bound remains the same (median of the last 11 blocks), and the upper bound is +2h relative to that value? In this way, the entire network would have the same value.

Why wasn't it done this way, would there be certain problems if it were implemented like this, and what are they?

Answer 1

the upper bound is +2h relative to that value?

Under such a rule, miners could just set every block timestamp to 20 minutes later than the previous block timestamp - ignoring real world time entirely - and get a 2x difficulty reduction every 2016 blocks.

In this way, the entire network would have the same value.

Yes, but it would fail at its purpose: tying block timestamps (roughly) to real-world time. Without any rule that relates block timestamps and nodes' real world clock at validation time, the two cannot be assumed to correspond.

And since real-world time is necessarily external to the chain, any rule that provides this relation cannot be a consensus rule. It's a network rule, crucial for Bitcoin's security, but it relies on information that is not part of the chain itself.

Essentially, the "max two hours in the future" rule is what makes the timestamps in blocks actual (rough) timestamps. It is what brings real world time in scope of the chain.