An interesting thread was started by Neiman via bitcoin-dev regarding the accuracy of Bitcoin block timestamps.

I’m doing a research project about blockchain timestamping. There are many such projects, including the fantastic OpenTimestamps.

…

I didn’t find any discussion or research regarding Bitcoin timestamp accuracy (also not in the history of this mailing list). I share here a simple analysis of timestamp accuracy, and a suggestion how to improve it.

One of the author’s observations is that timestamps are not necessary to avoid double-spending. A simple ordering of blocks would therefore be sufficient; exchaning timestamps with enumeration would work for the double-spending problem.

As far as I could tell, timestamps are included in Bitcoin’s protocol only to adjust the difficulty of PoW.

As was noted on the thread, timestamps only need to be reasonably accurate, their main purpose being to allow difficulty updates.

The author inquires about the mechanisms of direct control of timestamp accuracy in Bitcoin. Notably that the only mechanism provided by the Bitcoin protocol is the network time defined for each node. The network time being the median time for other clients, only if:

1. There are at least 5 connected nodes

2. The difference between the median time and the nodes own system time is less than 70 minutes.

Then new blocks are accepted by the peers if their timestamps is:

1. less than the network time plus 2 hours, and

2. greater than the median timestamp of previous 11 blocks.

The first rule supplies a 2 hour upper bound for timestamp accuracy.

However, the second rule doesn’t give a tight lower bound. Actually, no lower bound is given at all if no assumption is made about the median. If we assume the median to be accurate enough at some timepoint, then we’re only assured that any future timestamp is no bigger than this specific median, which is not much information.

Further analysis can be made under different assumptions. For example, what’s the accuracy if holders of 51% of the computational power create honest timestamps? But unfortunately, I don’t see any good reason to work under such an assumptions.

The second rule cannot be strengthened to be similar to the first one (i.e., nodes don’t accept blocks less than network time minus 2 hours). The reason is that nodes cannot differentiate if it’s a new block with dishonest timestamp, an old block with an old timestamps (with many other blocks coming) or simply a new block that took a long time to mine.

On the median timestamp accuracy, Gregory Maxell answered:

It would be more accurate to say that the median is not used for improved accuracy but to mitigate a consensus incompatibility:

If the block’s own timestamp were used for nlocktime and time based nlocks were common on the network each miner would maximize their fee income by setting the value as high as they could get away with. What concerned us wasn’t so much that this would make the times less accurate (though it would) but rather that it would create an incentive for a runaway situation that could harm network stability (e.g. with all miners cranking times against the 2hr window, then creating pressure for miners to accept further and further in the future; each responding to his own local incentives).

The timestamps in Bitcoin aren’t intended to be particularly accurate. They’re used only for controlling the difficulty, and the adjustment window is large enough that there isn’t much distortion that can be accomplished there. It’s not clear to me that much better can really be done… if there were tighter time requirements in the protocol miners would address them by running NTP which as an astounding lack of security in terms of how it is commonly deployed. As far as I know, I’m the only person whos ever mined blocks with their own stratum 1 time source.

If times need to be accurate Bitcoin would need to use a rather different design (e.g. each block would commit to the observation time of the prior N blocks, and an iterative algorithm would solve for each blocks time and each miners local offset).

IIRC open-timestamp calendar servers provide more precise time-stamping under the assumption that the calendar server is behaving correctly.

Further readings:

• A perspective on block timestamp and opentimestamps.
• OpenTimestamps trusted timestamping scheme via disposable keys.

Call for contributors:

If you have some expert knowledge on the topic and wish to contribute on the subject, feel free to contact us at authors@bitcointechweekly.com.