Timewarp attack 600 second grace period

[sjors]

@MattCorallo

The StratumV2 spec explicitly (I thought?) only allows a miner to roll nTime once per second

If that’s the intention, then the spec should be clarified. Currently there’s only an ambiguous statement buried in the discussion section. See sv2-spec/10-Discussion.md at 52e1fa22f68c343a3d25a2b1a04f93f8e701eced · stratum-mining/sv2-spec · GitHub and the header-only-mining (HOM) discussion here: cleanup and update Mining Protocol specs by plebhash · Pull Request #98 · stratum-mining/sv2-spec · GitHub

make sure that no miners are broken by the limitation,

Unfortunately this bug could exist for years without detection, only revealing itself in the distant future when chips are fast enough to cause a problem.

@ajtowns

If our block’s timestamp is invalid, then the malicious block’s timestamp will also have been to be too far in the future, so any node that would have rejected our block due to the timestamp would also reject it due to its parent

If the sv2 spec explicitly disallows accelerated nTime rolling then indeed the attacker would take the same risk as their victim.

But otherwise the malicious miner could use extra_nonce rolling to give themselves a bigger safety margin than their accelerated nTime rolling competitor.

@MattCorallo

I further don’t buy that we need to make inferior protocol design decisions

I’m not convinced (yet) that we need to make these numbers so tight. It seems that having a few hours of padding, instead of 10 minutes, avoids some actual bugs (pool software ignoring nTime) and theoretical future bugs. While the only downside is a minuscule increase in worst case inflation.