Bitcoin wiki says that:

A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours

My question is why 2 hours? Why not 1 or 3? Is there any calculation behind it?


1 Answer 1


I don't ever recall seeing an actual calculation for it, and I strongly suspect the reason is that it is "good enough".

The original, primary use of block timestamps is in difficulty calculations. They now also adjust the time for locktime transactions, but that's a newer addition.

A block's timestamps must:

  • Be greater than the median of the past 11 blocks (11 also seems to be a number chosen because it's good enough)
  • Within 2 hours of the network adjusted time

The network adjusted time is calculated by asking all your peers for their UTC timestamps, and if it's within 70 minutes of your own node, updating a network adjusted time median calculation over all the node times.

This imposes limits on how much a single node or miner can influence the time related parameters. Since difficulty adjustments look at the time between blocks and adjust to bring the mean down or up to 10 minutes, allowing for a very large variance may be counterproductive. 2 hours (to me) seems like a reasonable amount, since even if someone confuses DST time settings and has a bad clock, they would still be off in the range of 1-2 hours, on a reasonable system.

Of course, with ntp and other timekeeping services these days, nodes should be off a lot less. I've never heard of the 2 hour limit being insufficient, or of it being too large and causing issues with difficulty readjustment.

There are several things in the Bitcoin spec that exist because that's the way it was set up in the original implementation, and no pressing reason exists to change it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.