BSV Academy Logo over node concept

Ch4: The Bitcoin white paper - Timestamp Server

The BSV Academy’s free introduction to Bitcoin Theory course covers the design of Bitcoin as a system as prescribed by Satoshi Nakamoto. This course is open to anyone who is interested in Bitcoin and is the beginner course in this series. Some technical experience would be helpful to complete the course, however, it is open to anyone regardless of experience.

The course goes through the Bitcoin white paper section by section elaborating on the concepts contained within each. This section focuses on the timestamp server and how it works.

To make it as effortless as possible for you to have access to this educational material, we are publishing the entire course here on our blog. Stay tuned for a section-by-section release, and remember that you are still welcome to enrol in the BSV Academy to gain a certificate of completion to add to your resume.

The timestamp server of the Bitcoin white paper

Illustration of a timestamp server header

Timestamped hashes

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.
- Satoshi Nakamoto, Bitcoin White paper

Timestamp Hashes Demonstration

A Bitcoin block consists of an ordered set of transactions which each validly spend existing unspent transaction outputs (UTXO) into new transaction outputs. The network considers each transaction to be a separate item or event, and builds the blocks as such, using the hashed transaction message as an input into the block’s own hash function.

When a node finds a valid block, each transaction is published as part of that block, and through the hash of the transaction message can be provenly shown to have existed at the time the block was found. Blocks are broadcast across the whole Bitcoin network and either accepted or rejected by the rest of the nodes in the competition. These broadcast events can be considered akin to the publishing of a notice on a publicly available bulletin board or website.

A chain of timestamped hashes

Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it.
- Satoshi Nakamoto, Bitcoin White paper

Timestamp Hashes Demonstration

A block’s header must include the hash of the block upon which it is built. This ‘link’ forms a single chain of valid blocks leading all the way back to the very first block (the Genesis block) ever created using the system. A single block can have multiple child blocks which are built upon it, however only one of those children can become part of the permanent ‘longest chain’ of proof of work, further incentivising a strong connection between nodes who always want their own valid blocks to become part of the chain.

As blocks are added to the chain the cumulative proof of work built upon all the blocks preceding it is increased. In this way, as transactions age they become more secure through the proof of work applied to all blocks that come after.

This chain of proof of work forms a separate and distinct Directed Acyclic Graph (DAG) from the transaction ledger commonly referred to as the Timechain or Blockchain. The contents of this chain are an immutable record of what took place on the ledger and the order in which it took place. Any transaction that contradicts an event (e.g. double spends an input) that has been recorded in a block which forms part of the chain is considered invalid and can never become a part of the longest chain of proof of work.

Transactions which appear in blocks that do not form part of the longest chain of proof of work and which either contradict transactions that do appear in the longest chain, or which never get included in the longest chain of proof of work are considered invalid and are effectively removed from the ledger.

Transactions that are validly created (e.g. not double spent inputs, valid script) may still end up being excluded from the longest chain of proof of work due to not being correctly broadcast or not paying enough of a transaction fee to be committed to the ledger. These transactions can persist in local versions of the transaction DAG however can never become a permanent part of the ledger and when lost from local memory are effectively erased.

Learn more about the Bitcoin blockchain here.

Learn more about Bitcoin as Timechain here.

Ryan Brothwell
Ryan Brothwell

Deputy Editor, Bitcoin Association