icaro (OP)
Newbie
Offline
Activity: 1
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 31, 2010, 12:55:44 PM Last edit: October 18, 2010, 05:41:14 PM by satoshi |
|
Warning :Check your system data and time , you may not be able to generate or receive the most recent blocks ! What does it mean ? ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) I'm just with 2 connections and 500 blocks.
|
|
|
|
MoonShadow
Legendary
Offline
Activity: 1708
Merit: 1010
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 31, 2010, 01:27:53 PM |
|
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.
|
"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."
- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
|
|
|
satoshi
Founder
Sr. Member
Offline
Activity: 364
Merit: 7058
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
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?
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.
|
|
|
|
BioMike
Legendary
Offline
Activity: 1658
Merit: 1001
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 06, 2010, 05:19:29 AM |
|
I've thought about NTP, but this is more secure.
IMHO there is no reason for a modern system to not run a NTP client/daemon.
|
|
|
|
Insti
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 294
Merit: 252
Firstbits: 1duzy
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 06, 2010, 12:48:08 PM |
|
I dont think the bitcoin client should start bloating itsself with additional NTP client functionality.
|
|
|
|
Insti
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 294
Merit: 252
Firstbits: 1duzy
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 06, 2010, 12:51:37 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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
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.
|
|
|
|
BioMike
Legendary
Offline
Activity: 1658
Merit: 1001
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 06, 2010, 05:25:18 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
Founder
Sr. Member
Offline
Activity: 364
Merit: 7058
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 06, 2010, 09:41:06 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.
|
|
|
|
ribuck
Donator
Hero Member
Offline
Activity: 826
Merit: 1060
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 07, 2010, 11:14:20 AM |
|
Thanks.
Thank you Satoshi for sneaking that possessive apostrophe into "computer's date"!
|
|
|
|
agaumoney
Newbie
Offline
Activity: 53
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 09, 2010, 04:34:57 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: 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](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
Cdecker
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 19, 2010, 08:14:08 PM |
|
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
Legendary
Offline
Activity: 1722
Merit: 1072
P2P Cryptocurrency
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 20, 2010, 03:39:55 AM |
|
Agreed. There is no need to set the system time. We only need to use correct time in the program.
|
My OpenPGP fingerprint: 5099EB8C0F2E68C63B4ECBB9A9D0993E04143362
|
|
|
satoshi
Founder
Sr. Member
Offline
Activity: 364
Merit: 7058
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 23, 2010, 04:28:25 PM |
|
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.
|
|
|
|
agaumoney
Newbie
Offline
Activity: 53
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 12, 2010, 06:33:31 PM |
|
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.
|
|
|
|
joe
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 64
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 13, 2010, 06:34:15 AM |
|
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.
|
|
|
|
theymos
Administrator
Legendary
Offline
Activity: 5292
Merit: 13204
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 13, 2010, 12:28:31 PM |
|
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.
|
1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
|
|
|
MoonShadow
Legendary
Offline
Activity: 1708
Merit: 1010
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 13, 2010, 06:13:41 PM |
|
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.
|
"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."
- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
|
|
|
joe
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 64
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 13, 2010, 09:57:45 PM |
|
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.
|
|
|
|
theymos
Administrator
Legendary
Offline
Activity: 5292
Merit: 13204
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 13, 2010, 10:38:14 PM |
|
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. 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.
|
1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
|
|
|
|