Newer block has older age

[duke1839]

I noticed that block number 348096 had an older age by about half a minute from the previous block 348095.  How can this happen or is this just an error on the blockchain site?

[1714135061]

1714135061

[1714135061]

1714135061

[1714135061]

1714135061

[1714135061]

1714135061

[MegaFall]

Just a guess, but there's probably a small amount leniency in the system to compensate for blocks that are found within a minute or two of each other; a latency compensation thing. They were found like 40 seconds apart. 

[matt4054]

Block timestamps are set by the block miner/pool. Since Bitcoin is decentralized, there is no absolute time reference within the network (and there shouldn't be). There will always be clock variations between nodes. The blockchain is all about consensus, and the protocol has a tolerance for next block candidates timestamps: they can be slightly in the future, and even slightly in the past, compared to your local clock and the timestamps of previous blocks already in the chain.

In other words, the timestamp is not a strictly increasing sequence, while the block height (of the main chain) is.

[duke1839]

Block timestamps are set by the block miner/pool. Since Bitcoin is decentralized, there is no absolute time reference within the network (and there shouldn't be). There will always be clock variations between nodes. The blockchain is all about consensus, and the protocol has a tolerance for next block candidates timestamps: they can be slightly in the future, and even slightly in the past, compared to your local clock and the timestamps of previous blocks already in the chain.

In other words, the timestamp is not a strictly increasing sequence, while the block height (of the main chain) is.

Thank you, that makes perfect sense.

[kjj]

Just by memory, I think that the new block's timestamp must be:

1. Later than the mean (median?) of the last 11 blocks.
 AND
2. Not more than 2 hours into the future, based on the local node's notion of time¹.

Requirement 1 means that the clock must move forward, overall.

Requirement 2 is soft.   A block rejected by it will be accepted eventually, assuming that a better one doesn't show up first.  Globally, it limits a miner's ability to mess with the clock.  Without it, a group of miners could agree to run the clock fast, reducing the apparent work, artificially lowering the difficulty, increasing their profits.²

1.  Note that this is node time, which is not necessarily the same as the node's OS time or hardware RTC time.

2.  If you think that this causes a weakness in the system, work through the implications carefully.  The distribution of work between the normal and fast chains is important.

[Cryddit]

I've thought about this...  and not really reached a significant conclusion.

I worry when I get silly time stamps.  It could mean somebody is trying to so some kind of timing attack.  I mean, it doesn't normally mean that, and I'm not aware of any history of such attacks that have been made specifically against Bitcoin, but ....  well, I worry about stuff.

It would make sense, sort of, if nodes did not relay blocks whose timestamp is before the node's local time.  But if that were the case the network would sprout a new attack surface where nodes whose clocks were a minute late or a minute early could be forked off from the rest of the network, possibly for sequences several more blocks deep. 

So tolerating the occasional silly timestamp seems like the lesser evil.