Bitcoin Forum
December 09, 2016, 09:52:49 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Fake time atack on Bitcoin difficulty adjustment system - possible or not?  (Read 1559 times)
dmiii
Newbie
*
Offline Offline

Activity: 14

Alice (wondering)


View Profile
June 17, 2011, 11:51:42 AM
 #1

Hi all. Bitcoin is a very interesting phenomenon we have never seen before (or I have missed out some historical spirals Smiley ), 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...

1B1tBpNEeKztTtQ2HUB2PUYcv5taBXctSX
1481277169
Hero Member
*
Offline Offline

Posts: 1481277169

View Profile Personal Message (Offline)

Ignore
1481277169
Reply with quote  #2

1481277169
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Insti
Sr. Member
****
Offline Offline

Activity: 294


Firstbits: 1duzy


View Profile
June 17, 2011, 12:45:20 PM
 #2

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
Sr. Member
****
Offline Offline

Activity: 253


View Profile
June 17, 2011, 12:58:21 PM
 #3

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
Moderator
Legendary
*
qt
Offline Offline

Activity: 2030



View Profile
June 17, 2011, 02:22:37 PM
 #4

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
Sr. Member
****
Offline Offline

Activity: 406


View Profile WWW
June 17, 2011, 07:33:07 PM
 #5

But what if nobody find a block on 2 hours? Network goes to s**t?
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2030



View Profile
June 17, 2011, 08:02:52 PM
 #6

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
Newbie
*
Offline Offline

Activity: 14

Alice (wondering)


View Profile
June 18, 2011, 11:00:36 PM
 #7

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.

1B1tBpNEeKztTtQ2HUB2PUYcv5taBXctSX
foo
Sr. Member
****
Offline Offline

Activity: 409



View Profile
June 19, 2011, 06:26:27 AM
 #8

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.

I know this because Tyler knows this.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!