<p>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. </p>

<p>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 <a href="https://litecoin.info/Time_warp_attack" rel="nofollow noreferrer">timewarp attack</a>, 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. </p>

CC BY-SA 3.0
2017-10-27T21:27:10.473Z
2017-10-27T21:27:10.473Z
Claris
<p>New target is calculated from the T(new_block-1) - T(new_block-2016).
Here T is the time miner mined the block.</p>

<p>Miner itself sets this time for the block.</p>

<p>Thus miner can falsify this time.</p>

<p>I see a rule that this time: </p>

<blockquote>
  <p>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.</p>
</blockquote>

<p>Is this the mechanism used to prevent time falsification (thus target falsification)?</p>

<p>Is this mechanism itself enough? If yes, how so?</p>

CC BY-SA 3.0
2017-10-27T21:25:48.550Z
Try 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
CC BY-SA 3.0
2017-10-28T08:42:56.400Z
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
CC BY-SA 3.0
2017-10-28T08:52:56.233Z
(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
<block><mining-theory><proof-of-work>
How is mining time validated?
croraf
# How is mining time validated?

(Asked by: username_0 on 2017-10-27)

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?

**Tags:** block, mining-theory, proof-of-work

> **Comments:**
> **username_1**: Try 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?  
> **username_0**: 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?  
> **username_0**: (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?  

---

## 1 answers

### Answer by username_2 on 2017-10-27. Score: 1 | Accepted answer

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](https://litecoin.info/Time_warp_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.


---

