警告：システムを確認してください（助けてください）
「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日 14: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日 11: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の挙動に対する改善になる。
プログラムが起動時にインターネットのタイムサーバーを参照して、自前でオフセットを保持するだけでもいいだろう。