Time

Rough time a block was created

Diagram showing the location of the time field inside the block header.

The time field in the block header indicates the rough time a block was created.

Miners put the current time in the block header when they construct their candidate block. It contains a Unix Timestamp (the number of seconds since 01 January 1970), which is what computer programs typically use for storing specific points in time.

For example, the genesis block has the timestamp 1231006505, which is 03 Jan 2009, 18:15:05.

tool-6623e7534d3dc
Tool Icon

Unix Time

Convert the number of seconds since 1 Jan 1970, 00:00:00 to a date.

0d
0 secs

Block Order

Does block time influence the order of blocks?

The timestamps do not influence the order of blocks in the blockchain.

In fact, it's possible that one block could have an earlier timestamp than a block that came before it in the chain. Here's a fairly recent example:

Another particularly bad example is from 2011 where a block has a time of almost 2 hours "before" the block below it:

So whilst the timestamps are usually fairly accurate, sometimes blocks are not in "chronological" order, and that's perfectly fine.

The timestamp of each block is usually pretty close to the current time, but you shouldn't rely on them to be 100% correct. You'll see "out of order" blocks appear in the blockchain a few times a month, so it's not terribly uncommon.

Requirements

What is the maximum and minimum block time?

Diagram showing the valid time range that can be placed in the block header.

The timestamp has to be within a certain range for it to be valid:

So there is some flexibility in what the timestamp can be. For any newly-mined block, the time field could be anywhere between -1 to +2 hours (roughly) from the actual current time, and it would still be valid.

This flexibility allows for a node to have an incorrect time setting (e.g. mistakes due to Daylight Savings Time), and for latency when transmitting blocks across the network.

There is no mathematical justification for the range being between the median of the last 11 blocks and up to +2 hours in to the future. They're "good enough" values that Satoshi chose when they coded the first version of bitcoin, and we still use them today.

The two hour rule is really weird. It's the only 'consensus' rule that isn't based on blockchain data but on local data.
John Newbery, Bitcoin Core PR Review Club (Jun 19, 2019)

Network Adjusted Time

Local Computer Time:  
Network Adjusted Time: (-)

The network adjusted time is your local time plus the median offset of all the nodes you are connected to.

Diagram showing the network average time being calculated based on the timestamps sent by connected nodes
Nodes send a UTC timestamp of their local time when they connect to each other.

For example:

Local Time = 1685010124

Connected Nodes:
  Node 1     = 1685010121 (-3 seconds)
  Node 2     = 1685010122 (-2 seconds)
  Node 3     = 1685010122 (-2 seconds)
  Node 4     = 1685010125 (+1 second)
  Node 5     = 1685010125 (+1 second)
  Node 6     = 1685010127 (+3 seconds)
  Node 7     = 1685010128 (+3600 seconds)
  Median Offset = +1 second

Network Adjusted Time = 1685010125

Note: This is just a quick example.
Nodes are usually connected to more than 7 peers at a time.

The reason we use network adjusted time is that it's difficult for computers on a decentralized network to agree on the current exact time.

The network adjusted time allows the nodes to agree on a time between them, whilst limiting the ability of any one node from manipulating the "current" agreed time.

Network Adjusted Time bug

There is a well-known bug with the network adjusted time calculation in timedata.cpp.

Basically, if you have a long-running node, after 199 connections your node will get "stuck" with the median offset based on those first 199 connections, as any further connections will not be registered for the median offset calculation.

However, this bug protects other kinds of attacks according the Gregory Maxwell, so it has intentionally not been fixed.

Usage

What is the time field in the block header used for?

Besides being a rough indicator of when the block was mined, the block's timestamp has a couple of other uses within bitcoin:

Target Recalculations

Diagram showing a target recalculation based on the time between the last 2015 blocks.

The timestamps in block headers are used to work out whether blocks are being mined more quickly or more slowly than expected over a 2016-block period, and the target is adjusted accordingly.

Target Adjustment

Transaction Locktime

Diagram showing the locktime being used to prevent a transaction being mined until a specific time in the future.

A transaction can include a specific locktime to prevent it from being mined in a block until it's less a valid time field in a block header.

Notes

Resources