Bitcoin Forum

what happend?

Block 733862 is before 733863?

i mean in time

733862 has 27/04/2022 - 20:24:30 UTC

733863 has 27/04/2022 - 20:22:44 UTC

You want 2 to come before 1 in counting order?

Spam

Sorry a bit unclear:

i mean in time

733862 has 27/04/2022 - 20:24:30 UTC

733863 has 27/04/2022 - 20:22:44 UTC

some pools use the timestamp as a 'extranonce'

the time stamp can still be valid as long as its within a couple hours of the other block
so some use it as a variable to quickly make more combinations the nonce can cycle through without editing any of the transactions

thank you for your explanation ;D

The limits placed on the timestamp of a block are anywhere between the median timestamp of the last 11 blocks (plus one second), and 2 hours in to the future based on the adjusted network time (which is the average time of all the nodes your node is connected to). Because of this range, timestamps from later blocks can sometimes come before earlier blocks.

You can see the relevant code here: https://github.com/bitcoin/bitcoin/blob/bd616bc16a3a7f70f60ca5034b5a91e5ac89ac9d/src/validation.cpp#L3465-L3471

It doesn't necessarily have to be used as extranonce to be different than the real time. Timestamps are set by the individual computer (there is no universal clock in some centralized server that we use) and all computer times all around the world don't have the same time. Sometimes the clock is just wrong. One could be ahead and another behind hence causing such time differences in block headers.

This time difference in time stamp is as a result of the differences in the computing process of the blocks and if let say block A have a time stamp bigger than block B it simply means block A got mined before block be even though block be have a few second below Block A. It make no difference in the long run as long as their both got confirmed within the same time circle.

This isn't correct. The timestamp is unrelated to the verification of the blocks, which is what I assume you mean by the "computing process". As I've explained above, there is a range of a few hours the timestamp can fall within and still be valid, and there is nothing stopping later blocks being stamped as earlier than preceding blocks.

The timestamps also say nothing about the order in which the blocks were mined. Each subsequent block (based on block height) builds on the previous block. It's not possible for a block to be mined earlier but then not broadcast until after other blocks have been found.

but it is possible.. it just depends on WHO gets the first block broadcast to  them..
EG if a few mining pools collude to share their block solutions to build upon, but agree to not broadcast these to the wider network straight away.. then they can ,

then they can 'jump' forward the blockheight by 2 blocks when they suddenly decide its time to broadcast 2 blocks

Even if the pools do that, they still have to first set the timestamp and them mine one block at a time which means the timestamp of each mined block becomes immutable and is still following the same consensus rules as any other block that is broadcast normally.

It is not possible to do so with a single block, which is what my reply says. If you mine a block in secret and do not broadcast it until another block is already accepted at that height, then your block will be rejected. You can only do this if you mine a chain with more proof of work, but that is irrelevant to the discussion here regarding timestamps.

The user above seems to be suggesting that block 733,873 was mined before block 733,872 because it has an earlier timestamp, but there was a delay in it being broadcast or "processed", as he put it. This is not possible.