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?

Improve this question
3
  • 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?
    – Nate Eldredge
    Commented Oct 27, 2017 at 21:25
  • 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
    Commented Oct 28, 2017 at 8:42
  • (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
    Commented Oct 28, 2017 at 8:52

1 Answer 1

Reset to default
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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.