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

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…