See this comment: Great Consensus Cleanup Revival - #66 by AntoineP
Although @AntoineP now agrees with increasing the grace period, for reasons explained in the above comment, it might still be useful to investigate the following:
Does anyone have a log of when their node saw blocks arrive over e.g. the past 10 years? Perhaps we can determine, or rule out, the presence of such a bug in the wild.
I don’t know how though.
One problem with such analysis is that any block violating the MTP rule would not get propagated, so you wouldn’t observe it. Even compact block relay checks the header: bips/bip-0152.mediawiki at 5333e5e9514aa9f92810cfbde830da79c44051bf · bitcoin/bips · GitHub
Another problem is that you don’t know know the clock of the (pool) node that generated the block template.
A bug that ignores the template timestamp can be present in the pool software, the ASIC (stock or alternative) firmware or a proxy run by the miner.
If the bug is in pool software, we might be able to observe it live by studying live stratum jobs. This is easy on testnet4 today because MTP is ahead of wall clock time there. But not on mainnet.
Perhaps long term logs of such jobs exist, though again I’m not sure what to look for.
It seems a bit less likely to me that ASIC firmware ignores the timestamp provided in its stratum job. My own experience with old linux machines is that NTP doesn’t always work out of the box, so someone would have noticed such a bug the hard way quickly.
I have no idea how stratum proxies work. Those might exist at the scale of a small mining farm that rarely finds an actual block, so it seems undetectable.