Next scheduled rescrape ... never
Version 1
Last scraped
Edited on 27/04/2025, 17:28:51 UTC
Adding to what mcdouglasx have said
 
The timestamp is typically set by the miner when they create the block which is included in the block header.
The seconds you seeing is the precise seconds the miner chose typically when they started mining.

Quote
I get that it was at 13:43:43, and if I run this on my bitcoin node:
Code:
getblockheader “000000000000000000000000000216c973567f221c6cd61036fb71dfcc830b3e1041207f”
(hash of block 893254).
I get exactly the same time, in epoch.
That's because it was considered valid and falls under the validity rule that was mentioned by mcdouglasxhence became immutable like other data in the block.


After 6 minutes of mining, do I still have 11:54:19 in the header of block 23? If I manage to successfully mine the block, I will be transmitting to the network a block with a timestamp that corresponds to when I finished checking that block 22 was correct. Not approximately when I mined block 23.

If I do some thinking to try to solve the problem, I could solve it just by updating the timestamp I'm mining to the current timestamp, every ~30 seconds while I'm mining. That means that if I've been mining block 23 for 6 minutes, that means I've changed the block header timestamp 12 times. So, if I manage to mine a block, I would be transmitting to the network a mined block with a timestamp that says that block was mined max 30 seconds ago.

But this is an assumption of mine, I have not yet found how many seconds a miner updates the timestamp to the current one, during the mining process.
Like I have been stated above there's no specific time just a range that the timestamp must be greater than the median timestamp of the previous 11 blocks
And less than or equal to the network-adjusted time plus 2 hours
So 6 minutes is stillcan be  considered valid it and the broadcasted time would still be 11:54:19 as long as you don't update it.

Miners typically stick with the start timeframe except for specific reasons like block 23 been found or seems like it's pastfailing to meet the validity rule or miners clock diverging from network time or simple New Block been found. 

Quote
I would be transmitting to the network a mined block with a timestamp that says that block was mined max 30 seconds ago.
Logical but too expensive with no benefit.
Original archived Re: Doubt regarding the functioning of the Bitcoin network.
Scraped on 27/04/2025, 16:58:49 UTC
Adding to what mcdouglasx have said
 
The timestamp is set by the miner when they create the block which is included in the block header.
The seconds you seeing is the precise seconds the miner chose typically when they started mining.

Quote
I get that it was at 13:43:43, and if I run this on my bitcoin node:
Code:
getblockheader “000000000000000000000000000216c973567f221c6cd61036fb71dfcc830b3e1041207f”
(hash of block 893254).
I get exactly the same time, in epoch.
That's because it was considered valid and falls under the validity rule that was mentioned by mcdouglasx.


After 6 minutes of mining, do I still have 11:54:19 in the header of block 23? If I manage to successfully mine the block, I will be transmitting to the network a block with a timestamp that corresponds to when I finished checking that block 22 was correct. Not approximately when I mined block 23.

If I do some thinking to try to solve the problem, I could solve it just by updating the timestamp I'm mining to the current timestamp, every ~30 seconds while I'm mining. That means that if I've been mining block 23 for 6 minutes, that means I've changed the block header timestamp 12 times. So, if I manage to mine a block, I would be transmitting to the network a mined block with a timestamp that says that block was mined max 30 seconds ago.

But this is an assumption of mine, I have not yet found how many seconds a miner updates the timestamp to the current one, during the mining process.
Like have been stated above there's no specific time just a range that the timestamp must be greater than the median timestamp of the previous 11 blocks
And less than or equal to the network-adjusted time plus 2 hours
So 6 minutes is still considered valid and the broadcasted time would still be 11:54:19 as long as you don't update it.

Miners typically stick with the start timeframe except for specific reasons like block 23 been found or seems like it's past the validity rule.

Quote
I would be transmitting to the network a mined block with a timestamp that says that block was mined max 30 seconds ago.
Logical but too expensive with no benefit.