A clarification on the perpetual discussion of Bitcoin’s timestamp

What is it about?

Time stamping is just one convenient way of ordering transactions in traditional consensus systems. When running a banking business, the bank wants to know, which transaction came first and which came after. Some kind of ordering is needed, whether it is a timestamp or simply an incremented number. Yet, in distributed ledger technology (DLT) and its new kind of consensus mechanisms it is quite different and challenging on how to deal with ordering. It is not sufficient to rely on NTP (Network Time Protocol) servers, atomic clocks and similar time services, since it brings in the centralised flavour and introduces single points of failures.When Bitcoin — as the most prominent example of distributed ledger technology — and its underlying blockchain concept was released, they designed the ordering as an intrinsic feature. The ordering is basically the sequential “chain” part of the blockchain itself, since one block comes after the other.

What is the purpose of timestamps then?

Nevertheless, Bitcoin still uses timestamps, but for two other purposes:

• Difficulty calculation (origin feature)
• Locktime transactions (newer feature)

The timestamp is primarily used for establishing the difficulty (and also as an additional source of variation for the block hash).Without a timestamp, nodes wouldn’t be able to determine the correct difficulty to be used for each 2016 block period as they wouldn’t know how long it took to mine the previous blocks.However, miners still can manipulate the timestamp, but nodes will check against real time and will ignore blocks which are outside a certain time range. The conditions for timestamps are the following:

• be greater than the median of the past 11 blocks (Why 11? 11 blocks seems to be a number that’s good enough)
• within 2 hours of the network adjusted time (Why 2 hours? 2 hours also seems to be a number that’s good enough)

The network adjusted time is the process of how to sync the node time in a decentralised manner. A node asks all its peers for their UTC timestamps and if the timestamp is within 70 minutes of its own node, the network adjusted time median calculation over all the node timestamps will be done.

A simple example of why Bitcoin’s timestamp are not relevant for the ordering are the following two blocks (https://bit.ly/2FKXwTm):

[Bitcoin Block #180966](https://www.blockchain.com/btc/block/00000000000009109a556cf6c997f1ec10afa32fa53064b59a5fa0c026d200ee)

vs

[Bitcoin Block #180967](https://www.blockchain.com/btc/block/000000000000002aab5e054a80b8147bf9bdf8ef78d9da094f537489e53e2513)

The timestamp of block 180966 is 2012–05–20 23:02:53The timestamp of block 180967 is 2012–05–20 23:02:13

(example from here)

How is it done with other concepts like DAGs?

There are also DLT concepts based on directed acyclic graphs (DAG) which have to deal with more challenges when it comes to total ordering of a system. The main problem is its feature of concurrency. A known example of this endeavour is IOTA. As stated in the following paper: “On the timestamps in the tangle” (https://bit.ly/2qKTXTk)It is impossible the correct time order of transactions. Even if all transactions have timestamps, it can’t be ensured that all these timestamps are accurate (there can be some malicious nodes that want to fool the network about the true time when their transactions appear, and/or some nodes with simply a wrong clock). Those confidence intervals, which are up to now, just theoretical concepts described in this paper, which haven’t been implemented yet.

The ordering is important if you want to have certain smart contract functionality (which is also announced with IOTA’s Qubic — [Qubic: Quorum-based Computations — Powered by IOTA](https://bit.ly/2LcqMF9)). The most known example of a requirement for an ordering are Ethereum’s ERC20 contracts (used for all the ICOs since ’16).