Warning : Check your system clock (help me)

12 messages BitcoinTalk icaro, Satoshi Nakamoto, MoonShadow, Insti, Cdecker, BioMike, agaumoney, LZ August 31, 2010 — September 23, 2010
icaro August 31, 2010 Source · Permalink

Warning :Check your system data and time , you may not be able to generate or receive the most recent blocks !

What does it mean ? I’m just with 2 connections and 500 blocks.

MoonShadow August 31, 2010 Source · Permalink

If your system clock is too far off, blocks that you create would be rejected, and your client will reject any blocks that it views have been created with a future date.

Satoshi Nakamoto September 5, 2010 Source · Permalink

Any suggestions for better text to put for this error message so the next person will be less likely to be confused?

It’s trying to tell them their clock is wrong and they need to correct it.

It’s relying on 3 time sources:

  1. the system clock
  2. the other nodes, if within an hour of the system clock if those disagree, then
  3. the user (asking the user to fix the system clock)

I’ve thought about NTP, but this is more secure.

Insti September 6, 2010 Source · Permalink

I dont think the bitcoin client should start bloating itsself with additional NTP client functionality.

Insti September 6, 2010 Source · Permalink

Quote from: satoshi on September 05, 2010, 11:36:20 PM

Any suggestions for better text to put for this error message so the next person will be less likely to be confused?

“Please check that your computers date and time are correct. If your clock is wrong Bitcoin will not work properly.”

Cdecker September 6, 2010 Source · Permalink

I’d go for a small server that returns a unix timestamp, the client fetches it, computes the clock drift (difference in time) and all the protocol related times are based on that drift. The clocks would still drift a little (they’d do it anyway on the system clock) and we would not get perfect synchronization (impossible in distributed systems), but it would solve our current problems.

The code is about 5 lines and some simple math (sums) when calculating the timestamps.

BioMike September 6, 2010 Source · Permalink

Quote from: Insti on September 06, 2010, 12:48:08 PM

I dont think the bitcoin client should start bloating itsself with additional NTP client functionality.

Hell no, NTP does a good job. Don’t have other services changing the clock (also counts for bitcoin). Right tool for the right job!

Satoshi Nakamoto September 6, 2010 Source · Permalink

Quote from: Insti on September 06, 2010, 12:51:37 PM Quote from: satoshi on September 05, 2010, 11:36:20 PM

Any suggestions for better text to put for this error message so the next person will be less likely to be confused?

“Please check that your computer’s date and time are correct. If your clock is wrong Bitcoin will not work properly.” Thanks.

agaumoney September 9, 2010 Source · Permalink

Quote from: Cdecker on September 06, 2010, 12:54:07 PM

I’d go for a small server that returns a unix timestamp, the client fetches it, computes the clock drift (difference in time) and all the protocol related times are based on that drift. The clocks would still drift a little (they’d do it anyway on the system clock) and we would not get perfect synchronization (impossible in distributed systems), but it would solve our current problems.

The code is about 5 lines and some simple math (sums) when calculating the timestamps.

Why a server when so many are already out there?

I’d agree that we don’t want bitcoin client bloat, and definitely NO WAY the bitcoin client should be setting the system time.

But maybe it is worth it in the error case for the bitcoin client to put a message in the log and attempt to use a network time instead of system time.

As for the servers out there, the bitcoin client already has http, right? Well, most http servers now provide the date in their headers. For example, in python: Code:import os, re, urllib info = urllib.urlopen(‘http://www.yahoo.com/‘).info() regx = r’Date:\s+[A-Z][a-z]{2}, (\d{1,2}) ([A-Z][a-z]{2}) (\d{1,4}) (\d\d:\d\d:\d\d)’ d, M, Y, T = re.search(regx,str(info)).groups() m = 1+“JanFebMarAprMayJunJulAugSepOctNovDec”.index(M)/3 print ‘%04d.%02d.%02d-%s’ % (int(Y), m, int(d), T)

(that output format happens to work with “date -us” if you did want to set some system time)

of course it would be better to check a couple of sites rather than relying on just yahoo to keep their http server time set properly. Smiley

Cdecker September 19, 2010 Source · Permalink

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?

LZ September 20, 2010 Source · Permalink

Agreed. There is no need to set the system time. We only need to use correct time in the program.

Satoshi Nakamoto September 23, 2010 Source · Permalink

I don’t understand, are you under the impression that the program sets the system clock?  It doesn’t.

Quote from: Cdecker on September 19, 2010, 08:14:08 PM

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.