Block 811273/74 mined before block 811272

[Bitcoin Smith]

While I was checking the mempool status, I noticed something unusual the block 811273 mined before 811272. As far as I know the blocks are supposed to be mined in the sequential order.



I am sure there should be a logical explanation for this, and can't figure it out on my own, so turned towards bitcointalk community.

[1714466674]

1714466674

[1714466674]

1714466674

[albert0bsd]

The problem should be only a network delay.

Block  811272 was mined by an unknow miner, this miner may have some slow network connection or simple mempool.space recive the data before from someone else node in the network.

Edit

Code:

curl -sSL "https://mempool.space/api/block/0000000000000000000129f389dc62ed91ad78866539ac77b0d9b9a3487b5b89"

{"id":"0000000000000000000129f389dc62ed91ad78866539ac77b0d9b9a3487b5b89","height":811272,"version":612671488,"timestamp":1696800518,"tx_count":1768,"size":1800947,"weight":3992906,"merkle_root":"c21c2a518141b7fb88280cd5f862fd74a746621827ff05835e2e839d68d34b0a","previousblockhash":"0000000000000000000115a254aefecb901263a802f2092ce81c5d642b24e927","mediantime":1696795285,"nonce":3370511648,"bits":386197775,"difficulty":57321508229258.04}

curl -sSL "https://mempool.space/api/block/0000000000000000000137eb33e954c41b692e73edad2f44885146a03ec60c8d"

{"id":"0000000000000000000137eb33e954c41b692e73edad2f44885146a03ec60c8d","height":811273,"version":549453824,"timestamp":1696800386,"tx_count":794,"size":2048344,"weight":3990001,"merkle_root":"c1aa0b3ffcb09a6df1ae067c857ecfcf573f8bb831654856216cf84545dff070","previousblockhash":"0000000000000000000129f389dc62ed91ad78866539ac77b0d9b9a3487b5b89","mediantime":1696796411,"nonce":2327133999,"bits":386197775,"difficulty":57321508229258.04}

I realize that what i said is incorrect.

Block 811272 - timestamp 1696800518
Block 811273 - timestamp 1696800386

Acording to the book, Mastering Bitcoin, Page 249 - Mining and the Hashing Race

However, this was easily resolved by updating the block timestamp to
account for the elapsed time. Because the timestamp is part of the header, the change
would allow miners to iterate through the values of the nonce again with different
results.

The minners can change the timestamp a little without affect the mining process

[digaran]

811272 was probably mined by Satoshi, (unknown), lol. You can use a different time in your block when you mine it, though only a few minutes would be accepted by the network I guess, don't know the exact number.

[albert0bsd]

I guess, don't know the exact number.

I am looking for the exact number but i don't find it, maybe it can vary up to 10 minutes ?

[hosseinimr93]

I am looking for the exact number but i don't find it, maybe it can vary up to 10 minutes ?

The timestamp of the block must be between the median of the timestamps of the last 11 blocks and the median of the timestamps of the nodes you have connected to plus 2 hours.

For more details, click here to read the article about block timestamp on bitcoin wiki.

[philipma1957]

I am looking for the exact number but i don't find it, maybe it can vary up to 10 minutes ?

The timestamp of the block must be between the median of the timestamps of the last 11 blocks and the median of the timestamps of the nodes you have connected to plus 2 hours.

For more details, click here to read the article about block timestamp on bitcoin wiki.

So if we were having a very slow stretch of blocks we could push 20 minutes and if we were in a hot streak we could be at 5 minutes.

Those would likely be the far extremes 5 to 20 could work

[Bitcoin Smith]

I am looking for the exact number but i don't find it, maybe it can vary up to 10 minutes ?

The timestamp of the block must be between the median of the timestamps of the last 11 blocks and the median of the timestamps of the nodes you have connected to plus 2 hours.

For more details, click here to read the article about block timestamp on bitcoin wiki.

These rules of mining process are literally new knowledge for me, I hope this can't affect bitcoin network co-ordination and validity of the block no matter what. I am not sure often occur even if it's allowed under the miner's limits, so what I noticed is something rare I believe.

Thanks for the heads-up guys, hope others too learn about this possibility is accepted in the bitcoin network.

[o_e_l_e_o]

This is not unusual OP, and there is absolutely no requirement for block timestamps to be in order. Block ordering is based on block height, and not on timestamps. The timestamps are only used to calculate difficulty (and as an additional nonce field), nothing more, and so do not need to be accurate beyond a few hours. For example:

145044 - 15:46
145045 - 16:05
145046 - 16:00
145047 - 15:53
145048 - 16:04
145049 - 16:08

the median of the timestamps of the nodes you have connected to plus 2 hours.

That's not quite right. The timestamps of nodes you are connected to are used to adjust your own local time, provided those timestamps are within 70 minutes of your own local time.

So if we were having a very slow stretch of blocks we could push 20 minutes and if we were in a hot streak we could be at 5 minutes.

With an average block time of 10 minutes, timestamps can fall within a 3 hour window.

[DaveF]

The best way someone once said about it is that time is an illusion. We process linear time, all the blockchain cares about is the block and when that node saw it NOT the time it saw it but WHEN.
WHEN is not a time, it's just the fact that it was the NEXT block it saw.

The time / date is was mined is not at all important to the blockchain so long as it falls in the time period allowed. BUT, and this is an important BUT it's really just a field of information. If the block is valid and it was the next one the nodes saw, then it's valid.

-Dave

[philipma1957]

This is not unusual OP, and there is absolutely no requirement for block timestamps to be in order. Block ordering is based on block height, and not on timestamps. The timestamps are only used to calculate difficulty (and as an additional nonce field), nothing more, and so do not need to be accurate beyond a few hours. For example:

145044 - 15:46
145045 - 16:05
145046 - 16:00
145047 - 15:53
145048 - 16:04
145049 - 16:08

the median of the timestamps of the nodes you have connected to plus 2 hours.

That's not quite right. The timestamps of nodes you are connected to are used to adjust your own local time, provided those timestamps are within 70 minutes of your own local time.

So if we were having a very slow stretch of blocks we could push 20 minutes and if we were in a hot streak we could be at 5 minutes.

With an average block time of 10 minutes, timestamps can fall within a 3 hour window.

Thank you I misunderstood the time parameters. Had a bad math day. I have seen 2-5 minutes a few times. So for some reason I dropped out to 2 hour add-on

[o_e_l_e_o]

If the block is valid and it was the next one the nodes saw, then it's valid.

I appreciate you are trying to simplify things for your explanation, but you have done so in a way that makes an incorrect statement.

When a node saw a block is irrelevant to whether or not that block is valid. Orphan blocks (using the real meaning of the term "orphan block", i.e. a block which does not have a parent, and not a stale block as most people (incorrectly) use the term orphan block to refer to) are valid blocks but with an unknown parent. In these cases the node in question sees the completely valid orphan block first, and then sees the parent block(s) later (although this should not happen anymore since we swapped to headers first syncing). And then there are also stales blocks. I could see a block at height 800,000 and accept it, then see a second block at height 800,000 and reject it, but the second block ends up becoming the accepted block when it is mined upon. And of course during the IBD blocks aren't actually downloaded in order.

Blocks are chained together by each block's header containing the previous block's block hash. That's all. It doesn't matter what the timestamp is, or what order the blocks were seen or downloaded by your node, or how fast the blocks were transmitted through the network, or anything else. Just a chain of hashes all the way back to the genesis block.

[BlackHatCoiner]

My node received block 811272 4 minutes earlier than 811273 and 9 minutes earlier than 811274. That confirms they were mined in sequential order. The real mined time isn't determined by the timestamp. It is neither determined by the time my node received the blocks, but it is definitely a more accurate approach.

Orphan blocks

But is this what's going on here? I don't know how the mempool.space software works, but if you were to receive an orphan block, it wouldn't make sense to consider it part of the chain as shown in the image; not until the parent comes up. So how does mempool.space treat time? With block timestamp I suppose.

[o_e_l_e_o]

But is this what's going on here?

No, but I never said it was. I'm just pointing out that you used to be able to receive blocks without knowing anything about their parent(s), and so using the order your node first sees blocks as the order those blocks were mined would lead to incorrect results.

[pooya87]

My node received block 811272 4 minutes earlier than 811273 and 9 minutes earlier than 811274. That confirms they were mined in sequential order.

To be clear in the blockchain blocks can only be mined in sequential order because block (n+1) must have a reference to block (n) (the 32 byte previous block hash field in each block header) that can only be known if block (n) is already mined.

[NotATether]

Blocks are chained together by each block's header containing the previous block's block hash. That's all. It doesn't matter what the timestamp is, or what order the blocks were seen or downloaded by your node, or how fast the blocks were transmitted through the network, or anything else. Just a chain of hashes all the way back to the genesis block.

But it's not good if the timestamps are intentionally set wrongly. I hope this was just an accident, because network speed by itself cannot delay block propagation between miners and other nodes on high-speed networks by two whole minutes.

Most likely it was an instance of buggy software used by the miner (or mining pool).

[o_e_l_e_o]

But it's not good if the timestamps are intentionally set wrongly.

Beyond an active timewarp attack (which has never happened), then it does not matter at all.

I hope this was just an accident, because network speed by itself cannot delay block propagation between miners and other nodes on high-speed networks by two whole minutes.

The speed of block propagation is completely unrelated to the timestamps you see here.

Foundry, which mined block 811,273 must have seen block 811,272 first, as there is no other way they could have mined on top of it without knowing about it first. Therefore, the would also have known the timestamp of 811,272, and they would also have known that their timestamp was 2 minutes earlier. But as I've explained above, it literally doesn't matter, and so they are not going to invalidate their block header and lose the block reward by changing the timestamp and trying to mine a new block header from scratch.

It's maybe worth pointing out that the next block, 811,274, also has a timestamp 1 minute earlier than 811,272. So it's actually more likely that 811,272 was mined with a timestamp in the future, rather than 811,273 and 811,274 were both mined with a timestamp in the past. But again, it does not matter at all.

[NotATether]

But it's not good if the timestamps are intentionally set wrongly.

Beyond an active timewarp attack (which has never happened), then it does not matter at all.

I know that it doesn't matter for security reasons, but lets say you were making a dashboard or some other application that fetches blocks along with their block times. Or more realistically, fetching transaction confirm times from the blocktime. Then an event like this happens.

It basically means that the blocktime is an unreliable indicator for transaction settlement dates, and an additional timer has to be placed in the application for the purposes of accounting for user deposit times.

[o_e_l_e_o]

Or more realistically, fetching transaction confirm times from the blocktime.

Well then that person has misunderstood how bitcoin works. Timestamp (nor when your node first saw a transaction or block) has never been an accurate measurement of when something happened. If it was, we wouldn't need a blockchain at all, since we could all easily agree on ordering based solely on time.

It basically means that the blocktime is an unreliable indicator for transaction settlement dates

Correct. It is only accurate to an (on average) 3 hour window.

[BlackHatCoiner]

No, but I never said it was. I'm just pointing out that you used to be able to receive blocks without knowing anything about their parent(s), and so using the order your node first sees blocks as the order those blocks were mined would lead to incorrect results.

Got it, but it seems weird if an orphaned block was prompted to the user interface like that. It should not, until the parent is found. Treating orphaned blocks as valid (until further notice) is part of the backend anyway.

Correct. It is only accurate to an (on average) 3 hour window.

How did you work out that? Timestamp must be between the median of the last 11 blocks plus a second, and 2 hours in the future (local node time). Is it that it that the median is usually an hour ago?

[o_e_l_e_o]

How did you work out that? Timestamp must be between the median of the last 11 blocks plus a second, and 2 hours in the future (local node time). Is it that it that the median is usually an hour ago?

Correct.

The median of the last 11 blocks, assuming the timestamps are in order, is the timestamp of the 6th last block. Assuming an average of 10 minutes, then the 6th last block is an hour ago.

Obviously this is just an an average, though, and at time of writing the median of the last 11 blocks is actually 70 minutes ago.