My question is:
does BIP54 inadvertently preclude the possibility of a soft fork to handle timestamp overflow?
Conceptually, I think you could implement a soft fork that resolves the timestamp overflow bug, by using the "timewarp attack" [3] to intentionally minimize the timestamp and reduce the legacy difficulty, while simultaneously using a u64 timestamp in the coinbase transaction to enforce the real difficulty target.
In short, the "timewarp attack" makes it possible to increment the u32 timestamp by 1 second each block, ensuring the chain will practically never halt (provided the soft fork is adopted sufficiently in advance).
Formally, given a block of height N and a timestamp T at activation height H:
- if N % 2016 < 2015: miners set the legacy timestamp to T + (N - H).
- if N % 2016 = 2015, miners set the legacy timestamp to min(2^32 - 1, timestamp in the coinbase transaction).
- nodes require that the block hash meets the difficulty target determined in the coinbase (in addition to the artificially low legacy difficulty target).
This solution, of course, doesn't work if the Great Consensus Cleanup is adopted and the "timewarp attack" gets fixed. Also, it will make header and SPV validation more complex, as nodes will need the coinbase transaction and a merkle proof in order to validate the header chain. Perhaps worst of all, it could confiscate coins that are locked to a timestamp, rather than a block height.
The upside is that this is a soft fork, rather than a hard fork, which has its own advantages. Meanwhile, confiscation concerns could potentially be mitigated by signaling activation several decades in advance.
Is the possibility of a soft fork worth forgoing the timewarp fix? I'm not sure. A compromise could be to expire the timewarp fix after a certain block height, but that introduces a new set of tradeoffs.
Josh