Which is a bug in Bitcoin Core. It was caught before release. The second bug wasn’t, it’s fixed by 31600. It just illustrates how easy it is to screw things up when the grace period is only 600 seconds.
Update: it was a known omission before the original PR was merged, so maybe shouldn’t count as a bug: Move maximum timewarp attack threshold back to 600s from 7200s by TheBlueMatt · Pull Request #30647 · bitcoin/bitcoin · GitHub
Exactly. I’m not really worried about a one-off 10% increase in block speed. But compounded over time it’s more worrying.
Hundreds of years is enough time to come up with a plan, but serious problems could happen long before difficulty reaches 1. E.g. deep reorgs would be easier to execute.
If we take a difficulty reduction of 10x as the (arbitrary) definition of “bad”, and if assume a 10% difficulty decrease every ~10 retarget periods, it takes 240 retarget periods to reduce to reach this “bad” situation. That’s several years, probably enough to discuss and deploy a soft-fork to make it stricter. But not super comfortable either.
Whereas with a grace period of 600 reaching “bad” takes 20 times longer, which seems very safe.
So this may be a good argument for keeping the number at 600 and to insist that pools either use the min_time field provided by Bitcoin Core, or implement their own code for the minimum time that takes both MTP and the new timewarp rule into account.