This aligns the BIP with the Bitcoin Core pull request and sets the allowed delta between the first block of the new difficulty period and the previous block to 7200 seconds (2 hours) instead of 600 seconds.
See also the discussion in the PR: https://github.com/bitcoin/bitcoin/pull/29775#discussion_r1704428831
2 hours is 7200, not 720.
Fixed, also slightly changed the wording and added some additional explanation.
I’m curious about the original author’s take on this, @TheBlueMatt.
Although we can always change the number later if this is proposed for mainnet, that would either complicate the consensus code with another if branch, or require us to drop / fork testnet4 (or hope we never hit an edge case).
There’s two additional reasons that make the number 600 nice:
When maximally exploited, it neatly offsets the off-by-one error in Satoshi’s code so that blocks actually happen every 10 minutes. See footnote [1] in the original BIP.
“we limit the attack scenario to about a 0.1% inflation rate, much smaller than the historical inflation rate due to rapid hashrate growth” - what happens to that rate with this new value?
Looking around a bit more, there’s a mailinglist post from 2018 Johnson Lau who called this number t:
0 <= t <= infinity. With a bigger t, the fix is less effective but also less likely to cause intentional/unintentional split.
He then considered that even “t=86400 (one day)” would probably be safe enough, so the choice of 7200 should be fine here.
All that said, I think it makes sense to make it safe for honest miners to just use their system time when producing a block. Though even with this change I’m not sure if that’s really safe behavior.
Our own code does the following (miner.cpp):
0pblock->nTime = TicksSinceEpoch<std::chrono::seconds>(NodeClock::now());
1...
2UpdateTime(pblock, ...)
3
4
5int64_t UpdateTime(CBlockHeader* pblock, ...)
6{
7 int64_t nOldTime = pblock->nTime;
8 int64_t nNewTime{std::max<int64_t>(pindexPrev->GetMedianTimePast() + 1, TicksSinceEpoch<std::chrono::seconds>(NodeClock::now()))};
9
10 if (nOldTime < nNewTime) {
11 pblock->nTime = nNewTime;
12 }
In other words, we pick the system time, and if needed bump it to MTP + 1.
I think this would indeed get us in trouble under the timewarp rule if t=600, when the previous block is > 600 seconds in the future.
I don’t think there’s much reason to care about miners being able to mine at their system time. Mining devices generally don’t have clocks that are robust anyway, they just roll nTime from where the mining work producer told them to start.
This seemed like a good idea to me at the time but I can’t really judge this since I don’t know the mining landscape enough. What time do the honest pools usually use then? I would have assumed they just use the easiest thing.
We could still make the switch to 600 if there is a preference for it. There don’t seem to be any shenanigans on the network so far, I could sync fine with the 600 delta.