Timewarp attack 600 second grace period

sjors · January 3, 2025, 1:11pm

While trying to illustrate the griefing attack with a functional test, I found another bug Will link to a fix PR here.

Update:

github.com/bitcoin/bitcoin

rpc: fix mintime field testnet4, expand timewarp attack test

bitcoin:master ← Sjors:2025/01/timewarp-oops

opened 02:41PM - 03 Jan 25 UTC

Sjors

+44 -17

#30681 fixed the `curtime` field of `getblocktemplate` to take the timewarp rule… into account. However I forgot to do the same for the `mintime` field, which was hardcoded to use `pindexPrev->GetMedianTimePast()+1`. This PR adds a helper `GetMinimumTime()` and uses it for the `mintime` field. It could be backported to v28. However I don't expect (testnet4) pools to use `mintime` in practice, since under normal mainnet circumstances this would produce blocks an hour in the past. Additionally this PR adjusts the timewarp test to better illustrate the griefing attack discussed here: https://delvingbitcoin.org/t/timewarp-attack-600-second-grace-period/1326/19 Changing `MAX_TIMEWARP` to something `> MAX_FUTURE_BLOCK_TIME` in `consensus.h` and `mining_basic.py` will cause the updated test to fail. I'm not proposing such a change here of course. The new test should be useful guidance for pool software developers, for why they really should use `curtime`, or least not ignore `mintime`.

Aside from the fix it illustrates the griefing attack above.