<blockquote>
<p>It seems to me that PoW overwrites whatever timestamps there may be, and in effect determines what &quot;time&quot; is for the blockchain.</p>
</blockquote>
<p>I think this is your confusion: arguably, timestamping <strong>is part of PoW</strong>. The only timestamps that exist in the Bitcoin protocol are those included in block headers by miners, and committed to by the proof of work. These provide the (very rough) timing information blocks carry. Transactions or blocks don't contain any timestamps besides these.</p>
<p>In more detail, every block consists of a header and list of transactions. That header contains the hash of the (Merkle root of) transactions, the hash of the previous block, a timestamp, a version number, a nonce, and the difficulty. There are two requirements for that timestamp to be valid:</p>
<ul>
<li>The timestamp must be higher than the median of the 11 immediate ancestors of the block (violating this rule makes the block permanently invalid). Note however that this does mean that blocks can have a timestamp lower than their parent.</li>
<li>The timestamp must be no more than 2 hours in the future (violating this rule makes the block only temporarily unacceptable, but not invalid, because waiting some time will change it).</li>
</ul>
<p>But, importantly, these rules are the only requirements, and miners are free to pick any timestamp between the lower bound set by the first rule, and the upper bound set by the second one. In practice, miners choose times that tend to be close to or at least around the current real-world time, because that maximizes the acceptability of the block and thus income. Together however, this only really means that the timestamps in blocks have an <strong>accuracy of roughly 1 hour</strong>.</p>
<p>That timestamp is used for two purposes:</p>
<ul>
<li>The block difficulty adjustment rule uses the timestamps of the first and last block within every 2016-block retarget window to determine what difficulty factor to apply. If miners would set timestamps artificially low (permitted by the first rule above), they'd cut their own flesh, as that would drive up the block difficulty, reducing their income. (this rule isn't perfect however and could be exploited; look up the timewarp attack for more details).</li>
<li>Transactions can have a timelock that determines when the earliest time is that they can be included in a block. To make sure all nodes agree about which block that is, transaction timelocks are compared with the block's timestamp, and not with nodes' own local clocks.</li>
</ul>

CC BY-SA 4.0
2022-03-30T12:23:48.253Z
I don't understand what you mean with "Note however that this does mean that blocks can have a timestamp lower than their parent". Reading https://github.com/bitcoin/bitcoin/blob/171f6f2699dc27e77843318be2fefdfcd9e589fb/src/validation.cpp#L3367, it seems to me that a block's timestamp must be greater than MPT (median of last 11 blocks). Is there another rule somewhere that compare's a block's timestamp to the one of the previous block?
X. N.
CC BY-SA 4.0
2022-03-30T12:28:00.660Z
@XavierNodet No, in that sentence I'm just trying to highlight that there is **no** rule against the timestamp of a block being below that timestamp of its parent.
Pieter Wuille
CC BY-SA 4.0
2022-03-30T14:17:14.220Z
"The timestamp must be no more than 2 hours in the future"

Just to clarify, does this check use the node's system clock?
vnprc
CC BY-SA 4.0
2022-03-30T14:25:51.293Z
It uses the verifying node's local clock, yes, so it is subjective (which is why it can't be an actual consensus rule causing violating blocks to be considered invalid; it's just a temporary local acceptance policy).
Pieter Wuille
CC BY-SA 4.0
2022-03-30T19:20:29.293Z
I’m not sure how I managed to misread this. Sorry about the noise…
X. N.
CC BY-SA 4.0
2022-03-19T14:36:26.737Z
2022-03-19T14:36:26.737Z
Pieter Wuille
<p><a href="https://bitcoin.stackexchange.com/q/68653/133124">This question</a> asks about the role of timestamping and <a href="https://bitcoin.stackexchange.com/a/68656/133124">this answer</a> supports the assertion that the main role is block difficulty adjustment.</p>
<p>On the other hand, the whitepaper claims that ordering blocks/transactions is important. I don't really understand this, but I must be missing something.</p>
<p>It seems to me that PoW overwrites whatever timestamps there may be, and in effect determines what &quot;time&quot; is for the blockchain.</p>
<p><strong>Question.</strong> What was the intended role of timestamping in the bitcoin whitepaper and is it still relevant?</p>

<blockchain><block><timestamp>
Is timestamping needed for anything except difficulty adjustment
user516728
# Is timestamping needed for anything except difficulty adjustment

(Asked by: username_0 on 2022-03-19)

[This question](https://bitcoin.stackexchange.com/q/68653/133124) asks about the role of timestamping and [this answer](https://bitcoin.stackexchange.com/a/68656/133124) supports the assertion that the main role is block difficulty adjustment.

On the other hand, the whitepaper claims that ordering blocks/transactions is important. I don't really understand this, but I must be missing something.

It seems to me that PoW overwrites whatever timestamps there may be, and in effect determines what "time" is for the blockchain.

**Question.** What was the intended role of timestamping in the bitcoin whitepaper and is it still relevant?

**Tags:** blockchain, block, timestamp


---

## 1 answers

### Answer by username_1 on 2022-03-19. Score: 7 | Accepted answer

> It seems to me that PoW overwrites whatever timestamps there may be, and in effect determines what "time" is for the blockchain.

I think this is your confusion: arguably, timestamping **is part of PoW**. The only timestamps that exist in the Bitcoin protocol are those included in block headers by miners, and committed to by the proof of work. These provide the (very rough) timing information blocks carry. Transactions or blocks don't contain any timestamps besides these.

In more detail, every block consists of a header and list of transactions. That header contains the hash of the (Merkle root of) transactions, the hash of the previous block, a timestamp, a version number, a nonce, and the difficulty. There are two requirements for that timestamp to be valid:

* The timestamp must be higher than the median of the 11 immediate ancestors of the block (violating this rule makes the block permanently invalid). Note however that this does mean that blocks can have a timestamp lower than their parent.
* The timestamp must be no more than 2 hours in the future (violating this rule makes the block only temporarily unacceptable, but not invalid, because waiting some time will change it).

But, importantly, these rules are the only requirements, and miners are free to pick any timestamp between the lower bound set by the first rule, and the upper bound set by the second one. In practice, miners choose times that tend to be close to or at least around the current real-world time, because that maximizes the acceptability of the block and thus income. Together however, this only really means that the timestamps in blocks have an **accuracy of roughly 1 hour**.

That timestamp is used for two purposes:

* The block difficulty adjustment rule uses the timestamps of the first and last block within every 2016-block retarget window to determine what difficulty factor to apply. If miners would set timestamps artificially low (permitted by the first rule above), they'd cut their own flesh, as that would drive up the block difficulty, reducing their income. (this rule isn't perfect however and could be exploited; look up the timewarp attack for more details).
* Transactions can have a timelock that determines when the earliest time is that they can be included in a block. To make sure all nodes agree about which block that is, transaction timelocks are compared with the block's timestamp, and not with nodes' own local clocks.

> **Comments:**
> **username_2**: I don't understand what you mean with "Note however that this does mean that blocks can have a timestamp lower than their parent". Reading https://github.com/bitcoin/bitcoin/blob/171f6f2699dc27e77843318be2fefdfcd9e589fb/src/validation.cpp#L3367, it seems to me that a block's timestamp must be greater than MPT (median of last 11 blocks). Is there another rule somewhere that compare's a block's timestamp to the one of the previous block?  
> **username_1**: @XavierNodet No, in that sentence I'm just trying to highlight that there is **no** rule against the timestamp of a block being below that timestamp of its parent.  
> **username_3**: "The timestamp must be no more than 2 hours in the future"  Just to clarify, does this check use the node's system clock?  
> **username_1**: It uses the verifying node's local clock, yes, so it is subjective (which is why it can't be an actual consensus rule causing violating blocks to be considered invalid; it's just a temporary local acceptance policy).  
> **username_2**: I’m not sure how I managed to misread this. Sorry about the noise…  

---

