When exactly is the time in a block updated?

[fevir]

Hi all,

Block mining is the fine art of hashing a block header. The block header contains, amongst other fields, a time field. This field contains a timestamp that is updated 'every few seconds', according to https://en.bitcoin.it/wiki/Block_hashing_algorithm and many other sources.

However, it is unclear what is meant with 'a few'. Is it 2 seconds? Or 10 seconds? Perhaps 42 seconds?
Also, is there any documented reference on the exact number of seconds after which the timestamp in a block is updated?

Thanks.

Fevir

[odolvlobo]

The timestamp may or may not be accurate. It is up to the miner. There is no requirement regarding the time stamp except that it must be within 1 or 2 hours of the actual time (actually it is a little more complicated than that). Miners may also use it to vary the hash.

[Quantus]

I would also like to understand how this works. The time stamp is used to build the block before you start hashing it right? Why would you stop hashing just to rebuild the block again with a new time stamp "Every few seconds"?
It only happens once for each new block. But a new time stamp is generated (by the software or the OS) every few secs. This is adjustable for performance I bet. Idfk not a programmer.
instead of "every few seconds" it should be "upon request" I mean you could generate a new time stamp every sec if you wanted  to but it don't need to be exact. I"m not even sure why its needed at all.

[Quantus]

The timestamp may or may not be accurate. It is up to the miner. There is no requirement regarding the time stamp except that it must be within 1 or 2 hours of the actual time (actually it is a little more complicated than that). Miners may also use it to vary the hash.

So miners can vary the time stamp, the transaction IDs and even the block version number to tweak the output during hashing to gain mining efficiency?

[dserrano5]

So miners can vary the time stamp, the transaction IDs and even the block version number to tweak the output during hashing to gain mining efficiency?

You don't gain any efficiency by changing the data that is hashed. It only means that if you run out nonces, you can change the timestamp and start over again.

[Coding Enthusiast]

TimeStamp in a block is just the miner's system time and date in Unix. After they mine a block, they add the TimeStamp to the header and finish up. Maybe what the documentation says means it has the accuracy of a few seconds as in "the code updates the TimeStamp variable right before finishing and hashing the block".

And it can be different, if I am not mistaken there can be blocks with bigger block height with TimeStamp which is lower than previous ones. And that is because TimeStamp has a 2 hour room for mistake.
Example:
145044: 2011-09-12 15:46:39     
145045: 2011-09-12 16:05:07
145046: 2011-09-12 16:00:05 // ~5 minutes before prior block
145047: 2011-09-12 15:53:36 // ~7 & ~12 minutes before 2 prior blocks
145048: 2011-09-12 16:04:06 // after 2 prior blocks but still before 145045
Ref.

So miners can vary the time stamp, the transaction IDs and even the block version number to tweak the output during hashing to gain mining efficiency?

You can't just change transaction IDs, TXID is just a double SHA of raw transactions and you need to change the signatures to change the TXID and changing anything about it makes the tx invalid!

P.S. I suggest moving this topic to "Development & Technical Discussion" board.

[fevir]

After they mine a block, they add the TimeStamp to the header and finish up.

That would change the hash of the block header, and most likely will render the new hash invalid. From what I understand, the timestamp is included in the block header before a hash is calculated.

Back to the topic question, there seems to be no specific value for 'every few seconds'. I'm wondering if the Wiki is correct, since a miner can simply add the current timestamp, start mining, and (when a hash is found within 10 minutes) publish the block. Agree on using the timestamp as an additional source in combination with the nonce.

[-ck]

All mining pools use stratum for communicating these days. The stratum spec indicates that an update must be sent out within 2 minutes. Most pools send out updates every 60 seconds (ckpool based ones every 30 seconds).  With each stratum update the block time is updated to the local clock time. Some mining hardware still rolls this time forward to increase the range of data it can hash without creating more base work to hash off, thus the time is artificially moved forwards - though this is less common these days. The bitcoin protocol allows time to be up to 10 minutes before and 2 hours after the current time which is why the rolling forwards is done. Thus the time in the block is only weakly correlated with the true time at best, and can be sometimes a long way off. Some blocks even have a time in the past compared to blocks that are mined before them.

[Quantus]

All mining pools use stratum for communicating these days. The stratum spec indicates that an update must be sent out within 2 minutes. Most pools send out updates every 60 seconds (ckpool based ones every 30 seconds).  With each stratum update the block time is updated to the local clock time. Some mining hardware still rolls this time forward to increase the range of data it can hash without creating more base work to hash off, thus the time is artificially moved forwards - though this is less common these days. The bitcoin protocol allows time to be up to 10 minutes before and 2 hours after the current time which is why the rolling forwards is done. Thus the time in the block is only weakly correlated with the true time at best, and can be sometimes a long way off. Some blocks even have a time in the past compared to blocks that are mined before them.

So if the mining network was ever decimated by an catastrophic attack no one would ever be able to mine a block again; because no one would be able to mine a block (unless they had a huge amount of hardware) in 2 hours. I mean like if 90% of hardware was bricked and all the mining pools were knocked offline. It would be really hard to restart the network with the difficultly set so freaking high. The time limit would not help matters is what I'm saying.

[-ck]

So if the mining network was ever decimated by an catastrophic attack no one would ever be able to mine a block again; because no one would be able to mine a block (unless they had a huge amount of hardware) in 2 hours. I mean like if 90% of hardware was bricked and all the mining pools were knocked offline. It would be really hard to restart the network with the difficultly set so freaking high. The time limit would not help matters is what I'm saying.

No I believe it's the time stamp on the block relative to what nodes think the current real time is.