How is mining time validated?

1

New target is calculated from the T(new_block-1) - T(new_block-2016). Here T is the time miner mined the block.

Miner itself sets this time for the block.

Thus miner can falsify this time.

I see a rule that this time:

Must be strictly greater than the median time of the previous 11 blocks. Full nodes will not accept blocks with headers more than two hours in the future according to their clock.

Is this the mechanism used to prevent time falsification (thus target falsification)?

Is this mechanism itself enough? If yes, how so?

croraf

Posted 2017-10-27T20:39:02.017

Reputation: 1 112

1Try and work through it. If more than half of all miners (by mining power) are dishonest, the network is screwed anyway. So assuming that more than half of all miners are honest, what happens if an attacker submits a block whose timestamp is (1) far in the past, or (2) far in the future? – Nate Eldredge – 2017-10-27T21:25:48.550

Good comment. (2 - easier) far future it will simply get rejected because of 2h limit. Why such a big limit, something like 15 minutes should be enough, especially because time propagation delays? – croraf – 2017-10-28T08:42:56.400

(1) A mining pool can mine 5-6 blocks in a row. If he puts them in the far past they are rejected as being lower than median. If the last block is at height N, he can put them somewhere around N-11. This gives a timing error of some 11 blocks. As difficulty is adjusted every 2016 blocks, this will give an error of some 11/2016 which is low. Is this correct? – croraf – 2017-10-28T08:52:56.233

Answers

1

In Bitcoin the median time past (as in your quote) is used for all operations where the clock matters which limits the effect of any given miners timestamp. Miners can skew the timestamp of their block quite heavily with no ill effect to the network, some previous mining optimisations involved skewing the timestamp forward to avoid needing to do expensive operations to load a new merle root.

There's one exception where some nastiness can occur, which is an off by one error in the difficulty window calculation which means the timestamp of a single block falls outside the calculation window. This is generally known as the timewarp attack, but isn't a significant threat in the real world, it is useful for abusively resetting the difficulty on the test network if it is too high however.

Anonymous

Posted 2017-10-27T20:39:02.017

Reputation: 10 054

Asked: 2017-10-27T20:39:02.017

Viewed: 134 times

Active: 2017-10-27T21:27:10.473