Timewarp attack 600 second grace period

[AntoineP]

@sjors

We shouldn’t introduce a soft fork rule that can be broken by accident, unless there’s a really good reason to.

This is a truism. I don’t think it’s necessary to say i agree.

@sjors

The original motivation for the timewarp attack was to prevent a very destructive attack that could happen in a matter of weeks.

Again you only give one of the multiple motivations for fixing timewarp. I already called you up on that in a previous post. As i’ve described in my writeup as well as in private discussions i don’t think it is the most likely scenario. 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.

@sjors

If the timewarp attack had been fixed with a 24 hour limit, I don’t think anyone would have proposed a subsequent soft fork to lower it to 600 seconds.

That’s plausible because a soft fork is risky and expensive. Not because somehow 24 hours is a better value than 10 minutes.

@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!

@sjors

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

What is this bug?

@sjors

We have no idea how much (closed source, unmaintained) mining software is out there, and we can’t expect every pool, individual mining farm and solo operator to thoroughly test their entire infrastructure on testnet4.

I agree, but it is not on itself an argument for a looser value. 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?

@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.

In conclusion, let me state i do not have a too strong opinion in favour of a 600 seconds grace period. It just makes sense to me and i don’t think we should change it unless there is a good reason to.

There is good reasons for the fix to be neither too loose nor too tight. 600 seconds is a good sweet spot as it seems to get rid of the incentive for miners to artificially increase the block rate (with a 600 seconds grace period a 10% block rate increase would take 212 periods) while being loose enough that using higher values wouldn’t materially decrease the probability of creating an invalid block. You have dismissed the reasons for avoiding a looser fix without providing compelling arguments why going for a 150 minutes grace period would lower risks.