What is with these Bitcoin blocks?

[Bitcoin_Arena]

When you look at the timestamp of Block 826742, it's as though it got confirmed before Block 826743, yet they appear otherwise in the block order. Can someone help explain this?



Block 826741: https://mempool.space/block/00000000000000000002acc5da3f7656f24cd7af3a7e3dd4613077dcaea38a51 ---> Timestamp: ‎2024-01-22 01:44
Block 826742: https://mempool.space/block/00000000000000000003551a74fcab62511a381f2913313a5314ca78085435f7 ---> Timestamp: ‎2024-01-22 01:48
Block 826743: https://mempool.space/block/00000000000000000002acc5da3f7656f24cd7af3a7e3dd4613077dcaea38a51 ---> Timestamp: ‎2024-01-22 01:46

[Zaguru12]

Timestamp do not need to be accurate order as the requirements for a block ordering must be the block height, as such the timestamp can for a previous block can be lower than that of a higher a block because the timestamp rules is that it needs to be in the median of the time stamp of the last 11 blocks according to bitcoin wiki. The time stamp is just used to calculate the difficulty and not necessarily the block order.

In this case it might be that the mempool.space node received the block 826743 before the block 826742 because there is no way that the block 826743 would have been mined before the 826742 because the latter needs the block header of the former. The real mined time isn’t classified by the timestamp

[BlackBoss_]

Bitcoin block timestamp protection rules.

It is a good article to understand about this. The protection has two rules, Median Past Time (MPT) Rule; Future Block Time Rule.

The Future Block Time Rule is coded in this line.
https://github.com/bitcoin/bitcoin/blob/4daadce36cfe9baa63c4d7d70de027add03a00df/src/chain.h#L22

Code:

static constexpr int64_t MAX_FUTURE_BLOCK_TIME = 2 * 60 * 60;

[ranochigo]

In this case it might be that the mempool.space node received the block 826743 before the block 826742 because there is no way that the block 826743 would have been mined before the 826742 because the latter needs the block header of the former. The real mined time isn’t classified by the timestamp

The time stated is the timestamp of the block and not the received time. As you have identified, the block timestamp doesn’t have to be sequential. Hence, it would be perfectly fine for the timestamp of a future block to come before the timestamp of an earlier block so long as it fulfils the Median Past Time.

Pools would usually try to broadcast the block immediately, or with minimal delay and propagation should he under a minute as well.

[LoyceV]

Even with NTP, internet lag can cause time diffences between systems. I can imagine that, if the time stamp would matter, it could lead to a race between miners to have a timestamp farthest in the future.

[ranochigo]

Even with NTP, internet lag can cause time diffences between systems. I can imagine that, if the time stamp would matter, it could lead to a race between miners to have a timestamp farthest in the future.

It would probably create too many forks, each node has a different range of acceptable time when considering the network adjusted time. Each node would also see a different set of valid blocks.

[LoyceV]

Each node would also see a different set of valid blocks.

Good point. Mostly ignoring the block time was a very good idea