<blockquote>
<p>I've always been under the impression that a block's timestamp represents the second at which a block was found.</p>
</blockquote>
<p>It is, though not with that much accuracy. The protocol allows for a roughly 3-hour window around that timestamp (1 hour in the past, 2 hours in the future).</p>
<blockquote>
<p>For this to be true, it would seem that the time header field must be modified along with nonce and possibly other fields in the mining loop(s).</p>
</blockquote>
<p>In practice, miners do this, but not actually inside the mining loop. Modern mining chips can churn through the entire <em>2<sup>32</sup></em> nonce space of a given block candidate in under a second, at which point they need to receive new work from the controller anyway. That new work can mean a change in extranonce (inside the coinbase transaction), rolling of the timestamp, or something else.</p>
<blockquote>
<p>But I don't see that there is anything enforcing that a miner does this.</p>
</blockquote>
<p>The only hard consensus rule is that the timestamp of a block is strictly larger than the median of the timestamps of the 11 blocks before it. Under normal circumstances, that means the timestamp can be up to an hour in the past.</p>
<p>There is an additional <em>acceptance</em> rule, where nodes will not accept blocks whose timestamp is more than 2 hours into the future <em>compared to their own local clock, at the time it is received</em>. This isn't a consensus rule per se, as local clocks are subjective, and violating this rule doesn't mean the block is permanently rejected; just temporarily not acceptable. Still, this means it is generally not beneficial for miners to intentionally set timestamps in the future (unless perhaps when it is many miners at once doing so, making this akin to a selfish mining attack).</p>
<blockquote>
<p>Can anyone succinctly state what the block time time field truly represents?</p>
</blockquote>
<p>The time the block was mined, within a precision of hours. Usually it's more precise than that, but this cannot be relied upon.</p>

CC BY-SA 4.0
2024-05-03T02:14:33.803Z
2024-05-03T02:14:33.803Z
Pieter Wuille
<p>I've always been under the impression that a block's timestamp represents the second at which a block was found.</p>
<p>For this to be true, it would seem that the time header field must be modified along with nonce and possibly other fields in the mining loop(s).</p>
<p>But I don't see that there is anything enforcing that a miner does this.  If not, then a miner could start mining a block at say 04:30:25 and find the block approx ten minutes later at 04:40:55, but the block will have timestamp 04:30:25.  So long as 04:30:25 is later than the previous block, it should still satisfy consensus rules and be accepted by other nodes.</p>
<p>If my analysis is correct, then it seems the best we can do is infer what the timestamp represents by comparing it to the time at which other nodes actually received the block.</p>
<p>And I believe that by convention, it does normally represent the second of finding the block.  But I imagine there may be exceptions existing in the blockchain.</p>
<p>So, have I got this right?   Can anyone succinctly state what the block time time field truly represents?</p>
<p>Eg, if I wanted to put a label in a block explorer, perhaps with a one sentence description, what should the label and sentence be, such that I am not misleading users?</p>

<block><block-header><timestamp>
What does the block time represent?
user49396
# What does the block time represent?

(Asked by: username_0 on 2024-05-02)

I've always been under the impression that a block's timestamp represents the second at which a block was found.

For this to be true, it would seem that the time header field must be modified along with nonce and possibly other fields in the mining loop(s).

But I don't see that there is anything enforcing that a miner does this. If not, then a miner could start mining a block at say 04:30:25 and find the block approx ten minutes later at 04:40:55, but the block will have timestamp 04:30:25. So long as 04:30:25 is later than the previous block, it should still satisfy consensus rules and be accepted by other nodes.

If my analysis is correct, then it seems the best we can do is infer what the timestamp represents by comparing it to the time at which other nodes actually received the block.

And I believe that by convention, it does normally represent the second of finding the block. But I imagine there may be exceptions existing in the blockchain.

So, have I got this right? Can anyone succinctly state what the block time time field truly represents?

Eg, if I wanted to put a label in a block explorer, perhaps with a one sentence description, what should the label and sentence be, such that I am not misleading users?

**Tags:** block, block-header, timestamp


---

## 1 answers

### Answer by username_1 on 2024-05-03. Score: 3 | Accepted answer

> I've always been under the impression that a block's timestamp represents the second at which a block was found.

It is, though not with that much accuracy. The protocol allows for a roughly 3-hour window around that timestamp (1 hour in the past, 2 hours in the future).

> For this to be true, it would seem that the time header field must be modified along with nonce and possibly other fields in the mining loop(s).

In practice, miners do this, but not actually inside the mining loop. Modern mining chips can churn through the entire *232* nonce space of a given block candidate in under a second, at which point they need to receive new work from the controller anyway. That new work can mean a change in extranonce (inside the coinbase transaction), rolling of the timestamp, or something else.

> But I don't see that there is anything enforcing that a miner does this.

The only hard consensus rule is that the timestamp of a block is strictly larger than the median of the timestamps of the 11 blocks before it. Under normal circumstances, that means the timestamp can be up to an hour in the past.

There is an additional *acceptance* rule, where nodes will not accept blocks whose timestamp is more than 2 hours into the future *compared to their own local clock, at the time it is received*. This isn't a consensus rule per se, as local clocks are subjective, and violating this rule doesn't mean the block is permanently rejected; just temporarily not acceptable. Still, this means it is generally not beneficial for miners to intentionally set timestamps in the future (unless perhaps when it is many miners at once doing so, making this akin to a selfish mining attack).

> Can anyone succinctly state what the block time time field truly represents?

The time the block was mined, within a precision of hours. Usually it's more precise than that, but this cannot be relied upon.


---

