本当に Wine での実行を続けない方がいい。データベースエラーが出ている（db.log）。おそらく新規インストールに転送する儀式的な手順は、データベース破損に対処するために編み出したものだろう。未確認ブロックを失う方法があるとすれば、データベースエラーが原因だろう。Linux ビルドで見つかった問題は修正できる。Berkeley DB の深い部分にある Wine の非互換性は修正不可能だ。
Linux ビルドの GCC 4.3.3 は、Windows の GCC 3.4.5 よりも SHA-256 コードをうまく最適化したのだと思う。最適な SHA-256 コードを探していた時、手動でチューニングされた高度に最適化された SHA1 コードはたくさんあったが、SHA-256 についてはまだそれほど多くなかった。MinGW を 4.3.x にアップグレードして同じ土俵に立てるか見てみるべきだな。
NewLibertyStandardのメール（2009年11月9日 18:00 UTC）
この Linux ビルドに貢献した皆さん、本当によい仕事をしてくれました ! 苦労に感謝します。 ビットコインが熟成し始めたので、 Wine 上の Windows 版と比較してコイン生成性能が同等以上か劣るか判断がつくまで、当面 Linux クライアントを使い続けます。
2009年11月9日午前8:59、Liberty Standard
多重起動したい別の場面は、ビットコインのアップグレード時です。 旧版のビットコインでは生成チェックボックスを外し、別データディレクトリで新版のビットコインを起動して採掘を開始します。 旧アプリのコインが熟成したら新アプリに送って、それから旧アプリを閉じます。 既存データを引き継いだ上書きアップグレードよりも、クリーンインストールの方を好みます。
2009年11月9日午前7:42、Satoshi Nakamoto <satoshin@gmx.com
サトシ・ナカモトのメール（2009年11月9日 05:42 UTC）ありがとう、何が起こったか分かった。最初のノードが 遅かったため、他の全員にもブロックを要求してしまい、全体が 詰まっただけだ。これは修正できる。正しいやり方を少し考える 必要がある。
未確認の状態でシャットダウンしてもリスクはない。トランザクションや新しいブロックを作成すると、すぐにネットワークにブロードキャストされる。 その後の確認数/#の増加は結果を監視しているだけだ。 その間にあなたのノードが承認を促進するために何かをすることはない。