Pages:
Author

Topic: Warning : Check your system clock (help me) (Read 16977 times)

administrator
Activity: 5222
Merit: 13032
March 11, 2011, 11:55:14 PM
#31
There's no documented way to make it synchronize more than once a week

It is documented:
http://technet.microsoft.com/en-us/library/cc773263%28WS.10%29.aspx

You need to change this registry value:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\NtpServer
Change the server flag from 0x9 to 0x0. Then you'll update using "smart adjustments" like normal NTP clients. You could also instead change W32Time\TimeProviders\NtpClient\SpecialPollInterval to update more frequently.
hero member
Activity: 588
Merit: 500
I suspect most of the nodes on the network right now are NTP synchronized, though I expect chaos will ensue once we have large numbers of unsynchronized nodes joining the network.
Well, the mainstream OSes (OSX, Windoze and increasingly Linux) all incorporate some kind of time synchronization, so that shouldn't be an issue. I wouldn't put money on it, though (especially not Bitcoins, since I ain't got none yet :-)

Windows by default only synchronizes once a week, and that's only IF the feature is enabled. There's no documented way to make it synchronize more than once a week, and a computer clock can drift quite a bit in that time, especially if the onboard battery is low or dead.

And that's not taking into account the number of people who intentionally desynchronize their clocks in order to play mind games with themselves.
member
Activity: 98
Merit: 20
I suspect most of the nodes on the network right now are NTP synchronized, though I expect chaos will ensue once we have large numbers of unsynchronized nodes joining the network.
Well, the mainstream OSes (OSX, Windoze and increasingly Linux) all incorporate some kind of time synchronization, so that shouldn't be an issue. I wouldn't put money on it, though (especially not Bitcoins, since I ain't got none yet :-)
hero member
Activity: 588
Merit: 500
I suspect most of the nodes on the network right now are NTP synchronized, though I expect chaos will ensue once we have large numbers of unsynchronized nodes joining the network.
member
Activity: 98
Merit: 20
Just remind me why Bitcoin cares about the time? Is it just to change the difficulty to target a certain average block rate or something more fundamental?

It seems to be quite a bit of hassle for not very much benefit.

Can't the client manage just by measuring time intervals with the actual absolute time value being unused? I imagine that the effects of any systematic drift would be unimportant compared to currently accepted hash-rate related variability.

ByteCoin

I'm late to the party, I know, but I'll answer this anyway.

It's quite important for controlling the rate of coin generation. Every 2016 blocks, the computer calculates the difference in time between the most recent block, and the block 2015 before it. The target is exactly two weeks; if the actual time was longer, then the difficulty is reduced. If the actual time was less than two weeks (as just happened a couple of days ago) then the difficulty is increased.
sr. member
Activity: 458
Merit: 250
Fix your date, time AND time zone.

You're absolutely correct about timezone, thanks. (I guess the brain goes numb installing windows - again)
hero member
Activity: 588
Merit: 500
Hi, I am getting this message every time Bitcoin opens: "Please check that your computer's date and time are correct. If your clock is wrong Bitcoin will not work properly." My clock is correct, but I have just installed Win 7 and I am using the Bitcoin data files from the previous Vista install. I tried deleting wallet.dat but it still complains. Any suggestions?

Fix your date, time AND time zone.
sr. member
Activity: 458
Merit: 250
Hi, I am getting this message every time Bitcoin opens: "Please check that your computer's date and time are correct. If your clock is wrong Bitcoin will not work properly." My clock is correct, but I have just installed Win 7 and I am using the Bitcoin data files from the previous Vista install. I tried deleting wallet.dat but it still complains. Any suggestions?
sr. member
Activity: 416
Merit: 277
Just remind me why Bitcoin cares about the time? Is it just to change the difficulty to target a certain average block rate or something more fundamental?

It seems to be quite a bit of hassle for not very much benefit.

Can't the client manage just by measuring time intervals with the actual absolute time value being unused? I imagine that the effects of any systematic drift would be unimportant compared to currently accepted hash-rate related variability.

ByteCoin
newbie
Activity: 53
Merit: 0
There must be a way to do away with real world time. It is an anonymity risk to give up your computer clock's time,

In what way is that a risk?

Is your perception of the risk related to how many bits of precision the time is "given up" ?  For example, any computer synced with a network time server should be accurate to the second.  What about if the time stamp is only given up to the minute?  Or 5 minutes?

It sounds like you believe there is some uniquely identifiable data contained in the time.  If so, then less precision (seconds or minutes instead of nanoseconds) removes that risk.

In addition, since nobody else on the network knows how long it takes you to "give up your computer clock's time" then they have no way to correlate the value they receive to the value in your computer clock with any degree of precision.

And finally, your computer clock's time is not treated as privileged data by anything else.  Why should bitcoin treat it specially?
joe
member
Activity: 64
Merit: 10
If someone rejects a block that most of the network accepts, won't the rejecting nodes eventually give up on the rejecting branch and move to the longer branch that accepted it?

If you reject a block, then all blocks after it are also invalid from your point of view, no matter how many other people accept them. If this was not the case, then an attacker could create bitcoins out of thin air by getting more than 50% of the network's CPU power. This effect was demonstrated when the overflow bug was fixed: even though 0.3.10 nodes were in the minority, they rejected all blocks produced by old clients (which contained a fraudulent and impossible transaction for 184 billion bitcoins).

This is not quite the case for timestamp issues, but there is a similar effect. If your clock is off, you won't accept any new blocks, as they'll all be too far in the future. You'll eventually get the blocks when they are no longer too far in the future, but you'll still be unable to generate because your view of the "latest valid block" is wrong.

Quote
The same problem would happen if someone double spends a coin, and nodes disagree on which one came in first. The majority will make a longer chain and the minority nodes will have no choice but to jump over.

You don't reject blocks for transaction timing/ordering issues.

There must be a way to do away with real world time. It is an anonymity risk to give up your computer clock's time, and it shouldn't be necessary to get a transaction or block confirmed on the bitcoin network. If nodes want to compute some time deltas against their own clocks, that's fine, but again, no one should have to fess up to their computer's absolute clock time in order for the system to work right.
administrator
Activity: 5222
Merit: 13032
If someone rejects a block that most of the network accepts, won't the rejecting nodes eventually give up on the rejecting branch and move to the longer branch that accepted it?

If you reject a block, then all blocks after it are also invalid from your point of view, no matter how many other people accept them. If this was not the case, then an attacker could create bitcoins out of thin air by getting more than 50% of the network's CPU power. This effect was demonstrated when the overflow bug was fixed: even though 0.3.10 nodes were in the minority, they rejected all blocks produced by old clients (which contained a fraudulent and impossible transaction for 184 billion bitcoins).

This is not quite the case for timestamp issues, but there is a similar effect. If your clock is off, you won't accept any new blocks, as they'll all be too far in the future. You'll eventually get the blocks when they are no longer too far in the future, but you'll still be unable to generate because your view of the "latest valid block" is wrong.

Quote
The same problem would happen if someone double spends a coin, and nodes disagree on which one came in first. The majority will make a longer chain and the minority nodes will have no choice but to jump over.

You don't reject blocks for transaction timing/ordering issues.
joe
member
Activity: 64
Merit: 10
Bitcoin should absolutely not be sending the computer's time to the network. Nor should it depend on the clock being set properly. Each node can keep track of when they see transactions come through. If they want to reject a block because it contains a transaction they saw too long ago, then they are free to reject it; no reason for the nodes to compare each other's clocks. If it's too old they will all reject it, which is what we want.

If someone rejects a block that most of the network accepts, then all of the blocks that they produce will be invalid and transactions won't gain confirmations from their perspective.

This is about times of blocks, not transactions. Block timestamps are used for the difficulty calculation, so they can't be too far off from reality.

If someone rejects a block that most of the network accepts, won't the rejecting nodes eventually give up on the rejecting branch and move to the longer branch that accepted it? The same problem would happen if someone double spends a coin, and nodes disagree on which one came in first. The majority will make a longer chain and the minority nodes will have no choice but to jump over.

The same argument goes for difficulty. I don't understand why difficulty is centralized. Again, each node should independently determine what the difficulty is, and reject blocks that don't meet the mark for that difficulty. As long as most nodes reach the same conclusion for difficulty, all nodes will eventually jump over the the chain of the majority.
legendary
Activity: 1708
Merit: 1010
I don't understand, are you under the impression that the program sets the system clock?  It doesn't.

We already have ways to synchronize (approximately) the clients, so why not make use of that?
We use an internal offset based on the median of other nodes' times, but for security reasons we don't let them offset us by more than an hour.  If they indicate we're off by more than an hour, then we resort to alerting the user to fix their clock.

It was proposed that the program set the clock, and several of us said, "no, don't do that."

Another proposal, which Cdecker was confirming, was for the program to use the "network time" when the local computer time was broken.  This would be an enhancement to the 3.10 behavior of not working.


Could just have the program check an Internet timeserver upon startup, and keep an offset for itself.

administrator
Activity: 5222
Merit: 13032
Bitcoin should absolutely not be sending the computer's time to the network. Nor should it depend on the clock being set properly. Each node can keep track of when they see transactions come through. If they want to reject a block because it contains a transaction they saw too long ago, then they are free to reject it; no reason for the nodes to compare each other's clocks. If it's too old they will all reject it, which is what we want.

If someone rejects a block that most of the network accepts, then all of the blocks that they produce will be invalid and transactions won't gain confirmations from their perspective.

This is about times of blocks, not transactions. Block timestamps are used for the difficulty calculation, so they can't be too far off from reality.
joe
member
Activity: 64
Merit: 10
Bitcoin should absolutely not be sending the computer's time to the network. Nor should it depend on the clock being set properly. Each node can keep track of when they see transactions come through. If they want to reject a block because it contains a transaction they saw too long ago, then they are free to reject it; no reason for the nodes to compare each other's clocks. If it's too old they will all reject it, which is what we want.
newbie
Activity: 53
Merit: 0
I don't understand, are you under the impression that the program sets the system clock?  It doesn't.

We already have ways to synchronize (approximately) the clients, so why not make use of that?
We use an internal offset based on the median of other nodes' times, but for security reasons we don't let them offset us by more than an hour.  If they indicate we're off by more than an hour, then we resort to alerting the user to fix their clock.

It was proposed that the program set the clock, and several of us said, "no, don't do that."

Another proposal, which Cdecker was confirming, was for the program to use the "network time" when the local computer time was broken.  This would be an enhancement to the 3.10 behavior of not working.
founder
Activity: 364
Merit: 7423
September 23, 2010, 11:28:25 AM
#14
I don't understand, are you under the impression that the program sets the system clock?  It doesn't.

We already have ways to synchronize (approximately) the clients, so why not make use of that?
We use an internal offset based on the median of other nodes' times, but for security reasons we don't let them offset us by more than an hour.  If they indicate we're off by more than an hour, then we resort to alerting the user to fix their clock.
LZ
legendary
Activity: 1722
Merit: 1072
P2P Cryptocurrency
September 19, 2010, 10:39:55 PM
#13
Agreed. There is no need to set the system time.
We only need to use correct time in the program.
hero member
Activity: 489
Merit: 505
September 19, 2010, 03:14:08 PM
#12
I think we all agree that setting the system time is a no go, but why can't we just use an offset internally and just circumvent the whole issue? We already have ways to synchronize (approximately) the clients, so why not make use of that?
Pages:
Jump to: