The Bitcoin whitepaper, explained and commented — section 3: timestamp server

4 min readApr 4, 2020

Following the previous installments of this series, we’re dissecting Satoshi Nakamoto’s 2008 whitepaper introducing Bitcoin to the world, section by section, and putting it in context. This time: section 3 — Timestamp server. As previously, quotes are from the whitepaper.

You may remember from the previous parts that Bitcoin attempts to solve a common problem of digital cash systems — namely, avoiding digital coins being spent twice — without requiring a centralized authority. Instead, Nakamoto proposes to make the record of transactions public and distribute it to all participants of a peer-to-peer network. Problem: how to make everybody agree on a single history of transactions?

It boils down to making participants agree on the order of transactions: between competing transactions (i.e. spending the same coin), which one came first? Let’s see what Nakamoto has to say:

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.

Let’s break it down:

  • first, we group transactions that appear more or less at the same time in bundles called blocks. This is just done for efficiency: better timestamp a bunch of non-competing transactions together than timestamp each of them individually!
  • then, we compute the hash of the transactions and publish it to an external outlet with a wide audience like a newspaper. The hash, a tool borrowed from cryptography, is a short digital number that can be computed quickly but cannot be reversed. It’s a sort of digital digest of the data. This digest IS the timestamp: since the hash was published, the data (that the hash sums up) must have existed at the time of publication.
  • finally, as more transactions are recorded, and thus more blocks are added, each new hash/digest will be computed from the current block AND the…