<p>The bitcoin blockchain <em>itself</em> works as the 'timestamp server'. Each new block is like the next step forward in time, and the order of transactions within the block is explicit as well.</p>
<p>So it isn't that each block is timestamped to a real-world clock-time, instead the blocks themselves represent the progression of the clock.</p>
<p>Note that each block header does include a timestamp that references a real-world clock, but this timestamp is just used as a rough sanity check, and to help regulate the network difficulty. <a href="https://bitcoin.stackexchange.com/questions/68653/the-role-of-timestamp">See this question</a> for more info.</p>

CC BY-SA 4.0
2022-02-27T00:50:17.550Z
2022-02-27T00:50:17.550Z
chytrik
<p>from my understanding, the idea is to have an <em>order of things</em>, and it has nothing to do with the real-world clock. Like chytrik mentioned - the block itself is time - the block is the measure of time in bitcoin world - the order of things.</p>
<p>I wouldn't pretend that I understand it completely yet (after reading up a few versions of it) but the crux of it is that proof-of-work requires energy &amp; time and we do not need to trust anything external (like a real world clock) and blocks represent a measure, a sequence in order - which is what time is.</p>
<p>Bitcoin is loosely connected to the real world time through its difficulty adjustment - that happens every 2016 blocks and readjusts the hashing difficulty based on  previous blocks' <em>real-world time</em>. And that is to keep sanity with ever increasing computation efficiency.</p>

CC BY-SA 4.0
2022-02-27T04:26:01.457Z
2022-02-27T04:26:01.457Z
t480625
<p>I'm trying to fully grasp the third section of the whitepaper. Quoting (emphasis mine):</p>
<blockquote>
<p>The solution we propose begins with a timestamp server. A timestamp server works by taking a
hash of a block of items to be timestamped and widely publishing the hash, such as in a
newspaper or Usenet post [2-5]. <strong>The timestamp proves that the data must have existed at the
time, obviously, in order to get into the hash.</strong> Each timestamp includes the previous timestamp in
its hash, forming a chain, with each additional timestamp reinforcing the ones before it.</p>
</blockquote>
<p>I understand the double spending problem described in the previous section and how a timestamp server as described in this section solves it. I don't understand why <em>timestamps</em> are needed.</p>
<p>Let's presume that the timestamp server itself doesn't check for double spending[1]. In this case, in order for the payee to validate the transaction, they have to confirm that the coin hasn't been spent in any previous blocks[2]. Timestamps are irrelevant since the order is defined by the chain of hashes.</p>
<p>I considered the possibility that the author uses the word &quot;timestamp&quot; liberally to refer to a block, but the bold sentence in the quote suggests that it indeed refers to real-world time.</p>
<p>[1] If it does, then the payee doesn't have to care about the order of transactions.</p>
<p>[2] The term &quot;block&quot; hasn't been introduced at this point, but it does appear in the subsequent diagram.</p>

<whitepaper>
Isn't timestamp server overkill?
Nikolai
# Isn't timestamp server overkill?

(Asked by: username_0 on 2022-02-26)

I'm trying to fully grasp the third section of the whitepaper. Quoting (emphasis mine):

> The solution we propose begins with a timestamp server. A timestamp server works by taking a
> hash of a block of items to be timestamped and widely publishing the hash, such as in a
> newspaper or Usenet post [2-5]. **The timestamp proves that the data must have existed at the
> time, obviously, in order to get into the hash.** Each timestamp includes the previous timestamp in
> its hash, forming a chain, with each additional timestamp reinforcing the ones before it.

I understand the double spending problem described in the previous section and how a timestamp server as described in this section solves it. I don't understand why *timestamps* are needed.

Let's presume that the timestamp server itself doesn't check for double spending[1]. In this case, in order for the payee to validate the transaction, they have to confirm that the coin hasn't been spent in any previous blocks[2]. Timestamps are irrelevant since the order is defined by the chain of hashes.

I considered the possibility that the author uses the word "timestamp" liberally to refer to a block, but the bold sentence in the quote suggests that it indeed refers to real-world time.

[1] If it does, then the payee doesn't have to care about the order of transactions.

[2] The term "block" hasn't been introduced at this point, but it does appear in the subsequent diagram.

**Tags:** whitepaper


---

## 2 answers

### Answer by username_1 on 2022-02-27. Score: 3

The bitcoin blockchain *itself* works as the 'timestamp server'. Each new block is like the next step forward in time, and the order of transactions within the block is explicit as well.

So it isn't that each block is timestamped to a real-world clock-time, instead the blocks themselves represent the progression of the clock.

Note that each block header does include a timestamp that references a real-world clock, but this timestamp is just used as a rough sanity check, and to help regulate the network difficulty. [See this question](https://bitcoin.stackexchange.com/questions/68653/the-role-of-timestamp) for more info.


---

### Answer by username_2 on 2022-02-27. Score: 1

from my understanding, the idea is to have an *order of things*, and it has nothing to do with the real-world clock. Like username_1 mentioned - the block itself is time - the block is the measure of time in bitcoin world - the order of things.

I wouldn't pretend that I understand it completely yet (after reading up a few versions of it) but the crux of it is that proof-of-work requires energy & time and we do not need to trust anything external (like a real world clock) and blocks represent a measure, a sequence in order - which is what time is.

Bitcoin is loosely connected to the real world time through its difficulty adjustment - that happens every 2016 blocks and readjusts the hashing difficulty based on previous blocks' *real-world time*. And that is to keep sanity with ever increasing computation efficiency.


---

