24
7
The timestamps starting at block 145044 are:
145044: 2011-09-12 15:46:39
145045: 2011-09-12 16:05:07
145046: 2011-09-12 16:00:05 // ~5 minutes before prior block
145047: 2011-09-12 15:53:36 // ~7 & ~12 minutes before 2 prior blocks
145048: 2011-09-12 16:04:06 // after 2 prior blocks but still before 145045
How does this occur?
21
From the wiki:
A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours. "Network-adjusted time" is the median of the timestamps returned by all nodes connected to you.
Whenever a node connects to another node, it gets a UTC timestamp from it, and stores its offset from node-local UTC. The network-adjusted time is then the node-local UTC plus the median offset from all connected nodes. Network time is never adjusted more than 70 minutes from local system time, however.
It's not obvious that there aren't any problems with this way of timestamping. See the blog post Timejacking & Bitcoin and the discussion about it here.
1So block producers out of sync by up to an hour or 2 cause no real problems so long as they remain in the minority. – Mocky – 2011-09-12T17:54:29.227
1I added some info on potential problems to the answer. – D.H. - bitcoin.se – 2011-09-12T19:59:58.617
so then the blockchain is more about ordering, and timestampedness only in a more abstract sense is it? – smatthewenglish – 2016-09-14T14:32:45.490
What do you mean by greater than the median timestamp of previous 11 blocks ? – jean-mickael nounahon – 2017-04-18T12:42:27.813
13
To add a bit to the other answers: Imagine if the protocol required that timestamps increase. Now imagine somebody mines a block with a timestamp a minute in the future as far as you can tell. What do you do? If you try to mine blocks with the timestamp you currently believe is correct, your blocks will get rejected (since they'd have a timestamp earlier than the last accepted block).
Due to the requirement that the network easily agree on whether a block is valid or not, the protocol can't require highly-accurate timestamps as a condition of accepting a block as valid. As a result, requiring monotonic timestamps would likely make things worse rather than better.
7
I believe the timestamp is based off of the machine hosting the bitcoin client that submitted the block, and variance is allowed as not everyone has their computer time synched properly.
Do you know where is the code that performs this function? – smatthewenglish – 2016-09-22T16:47:45.183
7
At least one mining pool deliberately sets timestamps 6 minutes in the future and Block 145045 appears to be from Eligius (the generation transaction is split into multiple addresses).
why do they do that? do they still do it? – smatthewenglish – 2016-09-22T21:14:58.657
is the notion of time in btc still this fuzzy in 2016? has there been any BIP to make this more strictly ordered? – smatthewenglish – 2016-09-22T21:13:59.637