ソケットがエラーを起こしても切断されない可能性のあった箇所をいくつか修正した。接続が再びデッドになった場合、切断して再接続するようになるはずだ。フォールバックとして非活動タイムアウトも実装した。
初期ブロックダウンロードの遅さに対する部分的な修正も含まれている。
追加した debug.log 情報を得るために、「-debug」スイッチを付けて実行してくれ。問題がさらにある場合に役立つ。
linux-0.1.6-test2.tar.bz2 12,134,012 バイト
ダウンロード：
http://rapidshare.com/files/305231818/linux-0.1.6-test2.tar.bz2.html
何が起こったか分かった。すべてのソケットが何らかの理由でデッドになった。 ネットワークとの通信がなかったのに、8 つのゾンビ接続があったため、まだオンラインだと 思い込んでブロックの生成を続けていた。これが起きている時は、ブロックが他の人の ブロックが間に入ることなく連番になっていることで分かる： 2/unconfirmed 3/unconfirmed 4/unconfirmed 5/unconfirmed 6 blocks 7 blocks
6 ブロック連続であなただけがブロックを見つけるというのは現実的ではない。
終了して再起動した時、接続してあなたがいない間にネットワークが見つけた 45 ブロックをダウンロードした。 あなたのブロックはすぐにネットワークにブロードキャストされなかったため、ネットワークはそれらなしで進んだ。
Wine 上でもまったく同じ問題があったようだな。 Linux のソケットハンドリングに何かがあり、いずれの場合もそれが影響しているようだ。
調査を始める。 最終的に問題の根本原因を見つけられない場合は、メッセージの不在を監視して切断する何らかのメカニズムを作る必要がある。 今のところの回避策は、より頻繁に終了して再起動することだけだ。
あなたのノード接続のうち 1 つを除いてすべてが同時にデッドになり、1 つがその少し後にデッドになった。 IRC はまだ動いていたので、インターネットからオフラインになったわけではない。
ブロックのステータスは熟成まで「#/unconfirmed」と表示すべきだろうか（119/unconfirmed から 120 blocks へ）。 ブロックについては、数字の意味がトランザクションほど強くない。
自分自身のブロックを確認としてカウントしないようにすることは改善になると思う。 欠点は、異なるノードで表示されるステータス番号が一致しなくなることだ。 ステータス番号はブロックの熟成カウントダウンとも連動しなくなる。 より軽い選択肢としては、すべての確認が自分自身のものである場合のみ特別扱いすることだ。
NewLibertyStandardのメール（2009年11月10日 15:10 UTC）熟成中のコインを 6 セットも失いました ! 熟成中のビットコインが 10 セットありました。 最後のセットは 0:22 頃に生成されたものです。 ビットコインが固まる前に 2/未確認まで進んでいました。 10:10 の時点で、 0:22 に生成されたビットコインはまだ 2/未確認のままでした。 あなたがコインを失うことはないと言ってくれていたので、ビットコインを終了して再起動しました。 よかった点として、終了も起動も非常に滑らかでした。 しかし残念なことに、ブロックが更新された時に、 6 セット分のビットコインを失いました。 4 セットはまだ未確認でしたが、 2 セットは確認済みでした。 そして、そのどれもが跡形もなく消えています。 「Show Generated Coins」オプションが利用可能になった今、失敗したビットコイン生成も戻してくれるとよいかもしれません。 あのビットコインたちが空気の中に消えていったというのが、とにかく気に入りません。 今のところまだ Linux ビルドを動かしていますが、直近 24 時間に生成した 10 セットのうち 6 セットが消えた今、 Wine 版が急に魅力的に見え始めています。 debug.log を添付しています。
2009年11月10日午前 1:45、Liberty Standard <newlibertystandard@gmail.com mailto:newlibertystandard@gmail.com> の書き込み：
Linux ビルドはこの 20 時間でビットコインを十分な量生成できていますし、データベースエラーについてのあなたの説明も信じていますので、今後は Linux ビルドを使い続けるつもりです。 Linux ビルドで少し困った点が一つあって、ファンが 50% から 100% に上がってしまいました。:-P CPU 制限はかけられると分かっていますので、耐えられなくなって生成量の減少を許容できるなら、そのうち CPU 制限をかけるかもしれません。 あるいは、もっと音楽を聴くことにすべきかもしれません……
未確認の状態でシャットダウンしてもリスクはない。 トランザクションや新しいブロックを作成すると、すぐにネットワークにブロードキャストされる。その後の 確認数/#の増加は結果を監視しているだけだ。 その間にあなたのノードが承認を促進するために 何かをすることはない。