I’ve at all times been underneath the impression {that a} block’s timestamp represents the second at which a block was discovered.
It’s, although not with that a lot accuracy. The protocol permits for a roughly 3-hour window round that timestamp (1 hour prior to now, 2 hours sooner or later).
For this to be true, it could appear that the time header area have to be modified together with nonce and presumably different fields within the mining loop(s).
In apply, miners do that, however not really contained in the mining loop. Fashionable mining chips can churn by means of your entire 232 nonce area of a given block candidate in underneath a second, at which level they should obtain new work from the controller anyway. That new work can imply a change in extranonce (contained in the coinbase transaction), rolling of the timestamp, or one thing else.
However I do not see that there’s something implementing {that a} miner does this.
The one exhausting consensus rule is that the timestamp of a block is strictly bigger than the median of the timestamps of the 11 blocks earlier than it. Underneath regular circumstances, which means the timestamp will be as much as an hour prior to now.
There may be an extra acceptance rule, the place nodes won’t settle for blocks whose timestamp is greater than 2 hours into the longer term in comparison with their very own native clock, on the time it’s acquired. This is not a consensus rule per se, as native clocks are subjective, and violating this rule does not imply the block is completely rejected; simply quickly not acceptable. Nonetheless, this implies it’s usually not useful for miners to deliberately set timestamps sooner or later (until maybe when it’s many miners directly doing so, making this akin to a egocentric mining assault).
Can anybody succinctly state what the block time time area actually represents?
The time the block was mined, inside a precision of hours. Often it is extra exact than that, however this can’t be relied upon.
