1
I was taking data from the BTC Blockchain with a custom script. I found something really weird.
Block nr. 24668 was created at 2009-10-09 23:02:57
Block nr. 24669 was created at 2009-10-10 00:15:48
Block nr. 24670 was created at 2009-10-09 23:15:43
Now tell me, how it's possible that block 24670 is 'younger' than the 24669? I already checked and all the blockchain explorer websites show exactly this data.
Thank you for your attention,
Mattia
0
A block's timestamp should only be treated as an approximate time that the block was mined. There is no way to enforce a miner to include 'the actual time', because it is impossible for the network to ascertain the truth of this. So instead, the network imposes a rule that the timestamp must adhere the following rules in order to be considered valid:
(The info below is copy/pasted from the Bitcoin.org developer reference)
The block time is a Unix epoch time when the miner started hashing the header (according to the miner). Must be strictly greater than the median time of the previous 11 blocks. Full nodes will not accept blocks with headers more than two hours in the future according to their clock.
Thus, it is possible for a block at height N to have a timestamp that comes after the the timestamp of the block at height N+1, as long as it follows these rules otherwise.
"Full nodes will not accept blocks with headers more than two hours in the future according to their clock." that is not entirely correct AFAIK. It should not be more than two hours from the 'network adjusted time'. When you connect to a node, the node sends a time stamp and you store the difference between the time returned to you by the node and your current local clock. Then after connecting to all nodes you calculate the median deviation between your clock and the network clock. At any point you calculate 'network adjusted time' by adding your local time to the median dev noted earlier – Ugam Kamat – 2019-05-21T18:19:20.523
See this: "Why don't the timestamps in the block chain always increase? "
– KappaDev – 2019-05-21T00:34:14.793