警告：システムの時計を確認してください（助けてください）
「Warning :Check your system data and time , you may not be able to generate or receive the most recent blocks !」という警告が表示される。
これはどういう意味なんだろう？ 接続はわずか2つで、ブロック数は500しかない。
システム時計がずれすぎていると、作成したブロックは拒否され、クライアントは未来の日付で作成されたと見なすブロックを拒否する。
このエラーメッセージに使うより良いテキストの提案はあるだろうか？ 次の人が混乱しにくくなるように。
時計が間違っていて修正する必要があると伝えようとしている。
3つの時刻ソースに依存している：
- システム時計
- 他のノード（システム時計と1時間以内の場合） これらが一致しない場合、
- ユーザー（ユーザーにシステム時計を修正するよう求める）
NTPについても考えたが、こちらの方がより安全だ。
NTPについても考えたが、こちらの方がより安全だ。
個人的には、現代的なシステムでNTPクライアント/デーモンを動かさない理由はないと思う。
このエラーメッセージに使うより良いテキストの提案はあるだろうか？ 次の人が混乱しにくくなるように。
「コンピューターの日付と時刻が正しいか確認してください。時計がずれているとBitcoinは正しく動作しません。」
UNIXタイムスタンプを返す小さなサーバーを用意し、クライアントがそれを取得してクロックドリフト（時刻の差）を計算し、すべてのプロトコル関連の時刻をそのドリフトに基づいて算出する方式がいいだろう。時計はまだ多少ずれる（システム時計でもどのみちずれる）し、完全な同期は得られない（分散システムでは不可能）が、現在の問題は解決するだろう。
コードは約5行で、タイムスタンプを計算する際の単純な算術（加算）だ。
Bitcoinクライアントが追加のNTPクライアント機能で肥大化すべきではないと思う。
冗談じゃない。NTPはちゃんと仕事をしている。他のサービスに時計を変更させるな（Bitcoinも含めて）。適切な仕事には適切なツールを！
サトシ・ナカモトの投稿（2010年9月5日23:36 UTC）このエラーメッセージに使うより良いテキストの提案はあるだろうか？ 次の人が混乱しにくくなるように。
「コンピューターの日付と時刻が正しいか確認してください。時計が間違っているとBitcoinは正しく動作しません。」
ありがとう。
UNIXタイムスタンプを返す小さなサーバーを用意し、クライアントがそれを取得してクロックドリフト（時刻の差）を計算し、すべてのプロトコル関連の時刻をそのドリフトに基づいて算出する方式がいいだろう。時計はまだ多少ずれる（システム時計でもどのみちずれる）し、完全な同期は得られない（分散システムでは不可能）が、現在の問題は解決するだろう。
コードは約5行で、タイムスタンプを計算する際の単純な算術（加算）だ。
サーバーならすでにたくさんあるのに、なぜサーバーを用意するの？
Bitcoinクライアントの肥大化は避けたいし、Bitcoinクライアントがシステム時刻を設定するのは絶対にダメだということには同意する。
しかし、エラーの場合にBitcoinクライアントがログにメッセージを記録し、システム時刻の代わりにネットワーク時刻を使おうとするのは価値があるかもしれない。
既存のサーバーについては、Bitcoinクライアントにはすでにhttpがあるよね？ まあ、今ではほとんどのHTTPサーバーがヘッダーに日付を提供している。例えば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)（この出力形式は、システム時刻を設定したい場合に “date -us” でそのまま使える）
もちろん、Yahooだけに頼るよりも、複数のサイトを確認した方がいいだろう。HTTPサーバーの時刻が正確に設定されている保証はないからね。😊
システム時刻を設定するのはダメだということには全員が同意していると思うが、内部でオフセットを使えば、問題全体を回避できるんじゃないかな？ クライアントを（おおよそ）同期させる方法はすでにあるのだから、それを使えばいいんじゃない？
理解できないのだが、このプログラムがシステム時計を設定すると思っているのだろうか？ そのようなことはしない。
Cdeckerの投稿（2010年9月19日20:14 UTC）システム時刻を設定するのはダメだということには全員が同意していると思うが、内部でオフセットを使えば、問題全体を回避できるんじゃないかな？ クライアントを（おおよそ）同期させる方法はすでにあるのだから、それを使えばいいんじゃない？
他のノードの時刻の中央値に基づく内部オフセットを使用しているが、セキュリティ上の理由から、1時間以上のオフセットは許可していない。1時間以上ずれていることが示された場合は、ユーザーに時計を修正するよう警告する。
理解できないのだが、このプログラムがシステム時計を設定すると思っているのだろうか？ そのようなことはしない。
Cdeckerの投稿（2010年9月19日20:14 UTC）クライアントを（おおよそ）同期させる方法はすでにあるのだから、それを使えばいいんじゃない？
他のノードの時刻の中央値に基づく内部オフセットを使用しているが、セキュリティ上の理由から、1時間以上のオフセットは許可していない。1時間以上ずれていることが示された場合は、ユーザーに時計を修正するよう警告する。
プログラムが時計を設定するという案が出て、何人かが「いや、それはやめておけ」と言ったわけだ。
もう一つの案は、Cdeckerが確認していたように、ローカルの時計が壊れているときにプログラムが「ネットワーク時刻」を使う、というものだった。これは「動作しない」という3.10の挙動に対する改善になる。
Bitcoinはコンピューターの時刻をネットワークに送るべきでは絶対にない。時計が正しく設定されていることを前提にすべきでもない。各ノードはトランザクションが届いた時刻を自分で記録できる。あまりに古いトランザクションが含まれるブロックを拒否したいなら、自由に拒否すればいい。ノード同士で時計を比較する理由はない。古すぎれば全員が拒否する。それが望ましい挙動だ。
Bitcoinはコンピューターの時刻をネットワークに送るべきでは絶対にない。時計が正しく設定されていることを前提にすべきでもない。各ノードはトランザクションが届いた時刻を自分で記録できる。あまりに古いトランザクションが含まれるブロックを拒否したいなら、自由に拒否すればいい。ノード同士で時計を比較する理由はない。古すぎれば全員が拒否する。それが望ましい挙動だ。
ネットワークの大半が受け入れるブロックを誰かが拒否すれば、その者が生成するブロックはすべて無効になり、その視点からはトランザクションも承認を得られなくなる。
これはブロックの時刻の話で、トランザクションの話ではない。ブロックのタイムスタンプは難易度計算に使われるため、現実から大きく外れることは許されない。
サトシ・ナカモトの投稿（2010年9月23日16:28 UTC）理解できないのだが、このプログラムがシステム時計を設定すると思っているのだろうか？ そのようなことはしない。
Cdeckerの投稿（2010年9月19日20:14 UTC）クライアントを（おおよそ）同期させる方法はすでにあるのだから、それを使えばいいんじゃない？
他のノードの時刻の中央値に基づく内部オフセットを使用しているが、セキュリティ上の理由から、1時間以上のオフセットは許可していない。1時間以上ずれていることが示された場合は、ユーザーに時計を修正するよう警告する。
プログラムが時計を設定するという案が出て、何人かが「いや、それはやめておけ」と言ったわけだ。
もう一つの案は、Cdeckerが確認していたように、ローカルの時計が壊れているときにプログラムが「ネットワーク時刻」を使う、というものだった。これは「動作しない」という3.10の挙動に対する改善になる。
プログラムが起動時にインターネットのタイムサーバーを参照して、自前でオフセットを保持するだけでもいいだろう。