Block #180966 has a timestamp of 2012-05-20 23:02:53.
Block #180967 has a timestamp of 2012-05-20 23:02:13.
How has the software permitted a later block to have an earlier timestamp than its predecessor?
-
Related: bitcoin.stackexchange.com/questions/915/… – Pacerier Jun 17 '12 at 20:52
The root cause of this is that without a central authority, it's impossible to know for sure what the current time is.
The protocol rejects blocks with a timestamp earlier than the median of the timestamps from the previous 11 blocks or later than 2 hours after the current network time. Any other timestamp is acceptable. Note that 'network time' may differ from the actual time, since the bitcoin network attempts to correct for incorrect clock settings by taking the median of the time reported by all connected peers as the network time.
You can read about an attack that this makes possible here:
By announcing inaccurate timestamps when connecting to a node, an attacker can alter a node's network time counter and deceive it into accepting an alternate block chain. This could significantly increase the chances of a successful double-spend, drain a node's computational resources, or simply slow down the transaction confirmation rate.
answered May 21 '12 at 1:18
-
I realize this is a very old post but I would ask if this vulnerability still exists? – Jeff Dec 29 '17 at 10:34
-
1I'm not sure, but I see no reason why it shouldn't. The rules didn't change. – Chris Moore Dec 31 '17 at 1:22
-
If it is still a vulnerability I am guessing there is a way to protect against it or it is not a serious one -- BTC has survived many assaults since 2012. – Jeff Dec 31 '17 at 2:35
-
@Jeff Seems like it is still a problem, and not easy enough to fix in a decade. For proposals, see e.g. (Short Paper) Towards More Reliable Bitcoin Timestamps \- IEEE Conference Publication or Achieving reliable timestamp in the bitcoin platform \| SpringerLink – nealmcb May 30 at 16:36
