Fake time atack on Bitcoin difficulty adjustment system - possible or not?

[dmiii]

Hi all. Bitcoin is a very interesting phenomenon we have never seen before (or I have missed out some historical spirals ), so it`s the first thing of that kind and may be vulnerable to unpredicted attack concepts. One of them is given below:

Can anybody explain what will happen after such scenario:
- Computer A is mining BTCs
- It has it's system clock adjusted, said, five hours ahead.
- Suddenly this computer generates the 2016'th block on the current difficulty.
- The new block is signed (including generation time && new difficulty) and published to other peers.

Will the new difficulty smaller than it should be? Or Bitcoin system has some mechanism to handle this case?

I've studied project wiki, original article and other sources and did not find any answer.

If such atack is possible, attacker may adjust system time to +1 day, + 2 week and so on, dropping new difficulty in such way.

The probability of such situation is not so low as may seem, because most miners don't like difficulty jumps. So, this people are likely to install hacked bitcoin miners, which will generate blocks with wrong timestamps and thus lower difficulty. But in this case Bitcoin system may be destroyed...

[1715217211]

1715217211

[1715217211]

1715217211

[Insti]

I'm pretty sure this has been discussed before. (I searched but could not find a good link.)

Blocks have to be within a certain time window (+/- 2 hours maybe?) of the last block to be valid.
If you're winning enough blocks to be able to drift the time in your desired direction you may as well just be directly manipulating the transactions you're including.

[pc]

But the goal isn't to manipulate the transactions, the goal is to manipulate the difficulty so that more blocks could get mined so more rewards are available. Doesn't every miner have an incentive to set their clock slightly ahead, so that difficulty is slightly less, at least for the one difficulty adjustment period that they start doing this for? (And once they do, they need to keep on doing it to keep it from making up the adjustment later.)

I doubt there's a real "attack" here, but it should be understood by everyone that the timestamp in blocks is really only accurate to within whatever the acceptable window is.

[gmaxwell]

But the goal isn't to manipulate the transactions, the goal is to manipulate the difficulty so that more blocks could get mined so more rewards are available. Doesn't every miner have an incentive to set their clock slightly ahead, so that difficulty is slightly less, at least for the one difficulty adjustment period that they start doing this for? (And once they do, they need to keep on doing it to keep it from making up the adjustment later.)

I doubt there's a real "attack" here, but it should be understood by everyone that the timestamp in blocks is really only accurate to within whatever the acceptable window is.

No, but this is one of the reasons difficulty is adjusted only every 2016 blocks instead of e.g. every block.

https://en.bitcoin.it/wiki/Protocol_rules  block messages #5 

"Block timestamp must not be more than two hours in the future"  (compared to network time)

So the most miners can advance the clock is two hours in a window of 2016 blocks... giving a maximum improvement of about half a percent when hashrate is stationary.   Doing so will also bring about the reward halving earlier, so its even less attractive if you expect to have a greater share of hash power in the future.

Network time ought to be hard to manipulate, though it isn't currently. But the most you can manipulate network time is -/+70 minutes of the nodes local clocks.

[kr105]

But what if nobody find a block on 2 hours? Network goes to s**t?

[gmaxwell]

But what if nobody find a block on 2 hours? Network goes to s**t?

No.

You should read the code. It's much easier to read it than it is to come up with a legit attack...

The constraint isn't 2 hours since the last block, it's two hours ahead of the the current network time, not the last block time.

[dmiii]

Thanks for answers. Have one more question.

The constraint isn't 2 hours since the last block, it's two hours ahead of the the current network time, not the last block time.

How does system deal with local time? e.g. +2 GMT and -4 GMT.

[foo]

Thanks for answers. Have one more question.

The constraint isn't 2 hours since the last block, it's two hours ahead of the the current network time, not the last block time.

How does system deal with local time? e.g. +2 GMT and -4 GMT.

Everything is in UTC, of course.