<blockquote>
<p><strong>Is it saying ...</strong></p>
</blockquote>
<p>I think you have it right except that for 2.2. the whole new block is broadcast not just the hash.</p>
<p>Actually &quot;broadcast&quot; isn't exactly the right term really. I believe the node transmits the new block to a small number of peers (e.g. ten or so other nodes). These other nodes then pass on the new block if it looks OK to them. Eventually the new block reaches all nodes in the network.</p>
<p>In a comment below, Pieter Wuille has clarified some of the details, &quot;Blocks are announced to all peers. Those peers then fetch the actual block from (typically) the first peer that announces from them.&quot;</p>
<p>I haven't found an explicit detailed description of the exact sequence of network actions, but if you read <a href="https://en.bitcoin.it/wiki/Protocol_documentation#Message_types" rel="nofollow noreferrer">The Bitcoin Wiki's Protocol documentation</a> you'll see that there are many message types and one of them is <code>inv</code>  (inventory)</p>
<blockquote>
<p>Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to getblocks.</p>
</blockquote>
<p>The <code>inv</code> payload includes an array <code>inv_vec[]</code> which contains a code for a type of data available (e.g. block) and a hash of that data.</p>
<p>So the recipient of that message could presumably see that the sender has one or more blocks that the recipient doesn't and could presumably then issue a <code>getdata</code> message to obtain that new data. As I said, I haven't yet found a detailed explanation of the exact sequence of operations but I imagine the reality is along these lines. So my description of this as broadcasting new blocks is a simplification.</p>
<hr />
<blockquote>
<p><strong>There is little information online trying to research the concept of &quot;timestamp server&quot;</strong></p>
</blockquote>
<p>As you evidently know, but others might not, what Nakamoto was describing, under section <em>3. Timestamp Server</em>, is an activity that we would now refer to as mining.</p>

CC BY-SA 4.0
2021-05-13T18:58:21.587Z
Blocks are *announced* to all peers. Those peers then fetch the actual block from (typically) the first peer that announces from them. This can be done through a number of mechanisms, but new blocks announced at the tip, modern Bitcoin Core nodes (0.13 and up) use compact blocks, see BIP152.
Pieter Wuille
CC BY-SA 4.0
2021-05-15T20:40:01.183Z
@Pieter, thanks for the clarification. I have accordingly updated the answer a little and might do so again when and if I think I understand the details better.
RedGrittyBrick
CC BY-SA 4.0
2021-05-13T17:48:44.480Z
2021-05-15T20:38:31.650Z
2021-05-15T20:38:31.650Z
RedGrittyBrick
<p>I'm trying to understand the &quot;Timestamp Server&quot; section in the original bitcoin paper. It feels overly short for someone without an understanding of cryptography.</p>
<p><strong>Is it saying?</strong></p>
<ol>
<li>A block includes:
<ol>
<li>The block itself</li>
<li>The time the block was created</li>
<li>A hash of the previous block</li>
</ol>
</li>
<li>When a new block is created:
<ol>
<li>This block includes the current time and a hash of the previous block</li>
<li>The hash of this new block is broadcasted to all nodes</li>
</ol>
</li>
</ol>
<p>There is little information online trying to research the concept of &quot;timestamp server&quot;.
Apologies if this is a silly question. As a software developer I'm trying to understand how this works on a granular level.</p>
<p><strong>Source:</strong></p>
<p>From the original paper, <a href="https://bitcoin.org/bitcoin.pdf" rel="nofollow noreferrer">Bitcoin: A Peer-to-Peer Electronic Cash System</a>.</p>
<pre><code>3. Timestamp Server
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.
</code></pre>
<p><a href="https://i.sstatic.net/Kjh2Z.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Kjh2Z.png" alt="enter image description here" /></a></p>

<block><cryptography><timestamp>
Explanation of "Timestamp Server" section in original bitcoin paper
tim_xyz
# Explanation of "Timestamp Server" section in original bitcoin paper

(Asked by: username_0 on 2021-05-13)

I'm trying to understand the "Timestamp Server" section in the original bitcoin paper. It feels overly short for someone without an understanding of cryptography.
Is it saying?

A block includes:

The block itself
The time the block was created
A hash of the previous block


When a new block is created:

This block includes the current time and a hash of the previous block
The hash of this new block is broadcasted to all nodes



There is little information online trying to research the concept of "timestamp server".
Apologies if this is a silly question. As a software developer I'm trying to understand how this works on a granular level.
Source:
From the original paper, Bitcoin: A Peer-to-Peer Electronic Cash System.
3. Timestamp Server
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.

**Tags:** block, cryptography, timestamp


---

## 1 answers

### Answer by username_1 on 2021-05-13. Score: 1 | Accepted answer

> **Is it saying ...**

I think you have it right except that for 2.2. the whole new block is broadcast not just the hash.

Actually "broadcast" isn't exactly the right term really. I believe the node transmits the new block to a small number of peers (e.g. ten or so other nodes). These other nodes then pass on the new block if it looks OK to them. Eventually the new block reaches all nodes in the network.

In a comment below, username_2 has clarified some of the details, "Blocks are announced to all peers. Those peers then fetch the actual block from (typically) the first peer that announces from them."

I haven't found an explicit detailed description of the exact sequence of network actions, but if you read [The Bitcoin Wiki's Protocol documentation](https://en.bitcoin.it/wiki/Protocol_documentation#Message_types) you'll see that there are many message types and one of them is `inv` (inventory)

> Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to getblocks.

The `inv` payload includes an array `inv_vec[]` which contains a code for a type of data available (e.g. block) and a hash of that data.

So the recipient of that message could presumably see that the sender has one or more blocks that the recipient doesn't and could presumably then issue a `getdata` message to obtain that new data. As I said, I haven't yet found a detailed explanation of the exact sequence of operations but I imagine the reality is along these lines. So my description of this as broadcasting new blocks is a simplification.

---

> **There is little information online trying to research the concept of "timestamp server"**

As you evidently know, but others might not, what Nakamoto was describing, under section *3. Timestamp Server*, is an activity that we would now refer to as mining.

> **Comments:**
> **username_2**: Blocks are *announced* to all peers. Those peers then fetch the actual block from (typically) the first peer that announces from them. This can be done through a number of mechanisms, but new blocks announced at the tip, modern Bitcoin Core nodes (0.13 and up) use compact blocks, see BIP152.  
> **username_1**: @Pieter, thanks for the clarification. I have accordingly updated the answer a little and might do so again when and if I think I understand the details better.  

---

