Timewarp attack 600 second grace period

[sjors]

@AntoineP

It’d make more sense for miners to artificially increase the block rate thereby bringing available block space up and, all other things equal, fee rates down. With the current concentration of mining we shouldn’t underestimate the odds of it happening. We should not keep in place the incentive for them to pull it off by making the fix too loose.

I don’t think this is dangerous for the network for the numbers we’re discussing, i.e. a 10% speedup after a sustained 51% attack for 59 difficulty periods. And why would a miner want to reduce their own fee revenue?

@AntoineP

@sjors

Above I linked to two actual mining pool software bugs that caused invalid blocks on testnet4 because they were using the system clock instead of the block template nTime.

Those softwares are already broken today due to the MTP rule. “Existing broken software may produce invalid blocks under exceptional circumstances” is not a valid argument for looser bounds if said software can already produce invalid blocks with current rules under exceptional circumstances!

But no miner ran into that bug so far, because it takes significant hash rate to push MTP above wall clock time and perform this attack. With the timewarp rule, griefing a miner that uses wall clock time only requires finding the last block in a retarget period and setting its time (a bit more than) 600 seconds in the future. Both attacks are free, but the latter only requires luck, no large percentage of hash power.

@AntoineP

@sjors

Bitcoin Core itself (briefly) had a bug where it could accidentally violate the timewarp rule.

What is this bug?

Have miner account for timewarp mitigation, activate on regtest, lower nPowTargetTimespan to 144 and add test

The main change adds this to miner.cpp:

if (consensusParams.enforce_BIP94) {
        // Height of block to be mined.
        const int height{pindexPrev->nHeight + 1};
        if (height % consensusParams.DifficultyAdjustmentInterval() == 0) {
            nNewTime = std::max<int64_t>(nNewTime, pindexPrev->GetBlockTime() - MAX_TIMEWARP);
        }
    }

The pull request description is focussed on a different scenario, but this (also) fixes the second griefing attack.

@AntoineP

Assuming you are still proposing to use 150 minutes instead, could you provide an argument for why this value would possibly better accommodate broken software we do not know about?

Yes, 150 minutes makes the above griefing attack on broken miner software impossible, because the attacker can’t put their timestamp more than 120 minutes in the future.

@AntoineP

@sjors

The timewarp fix with a 600 second limit deviates from that because it requires miners to also check their entire stack of mining software. Whereas a 150 minute threshold only requires them to upgrade their node.

How so? Could you be more specific? I don’t think we’ve established that.

Hopefully the above example illustrates this? With a 150 minute threshold there’s no (additional) danger in having a bug in mining software that ignores the nTime value provided in the Bicoin Core template. They might ignore it by accident like SRI Pool and JDC update `nTime` field with current timestamp - they should use the one sent by TP · Issue #1324 · stratum-mining/stratum · GitHub, or they might have custom code that calculates nTime correctly under the current rules (but not accounting for the new timewarp rule).