0.3.8でBitcoin生成が壊れた？ （64ビット）
何か問題が発生しているのではないかと疑い始めていた。システムがコインの生成をやめたように見えたからだ。1日あたり約1ブロックだったのが、1週間でゼロになった。
IRCでArtForzが、空のウォレットディレクトリで互いにのみ接続された2つのノードだけの隔離テストネットを実行してみることを提案した。クアッドコアのシステムを2台用意してセットアップした。合計8000 khash/秒以上のハッシュレートでありながら、約90分間ブロックが1つも生成されていない。これはもう問題の証拠だろうか、それともまた単に運が悪いだけだろうか？
システムはLinux 64ビットで、1台はIntelクアッドQ6600、もう1台はAMDクアッドPhenom II 940である。
自分でコンパイルした？ makefile.unixにdefineがある。-DCRYPTOPP_DISABLE_SSE2のようなものだ。それを消してくれ。でないとSHA256_Transformが初期状態を返す。私も0.3.6に切り替えたとき同じ問題が起きた。
自分でコンパイルした？ makefile.unixにdefineがある。-DCRYPTOPP_DISABLE_SSE2のようなものだ。それを消してくれ。でないとSHA256_Transformが初期状態を返す。私も0.3.6に切り替えたとき同じ問題が起きた。
それが問題の根っこのようだ。そうなると、0.3.8に付いてきたLinuxの64ビット版のバイナリさえ、間違ってコンパイルされていたんだと思う。
それが問題の根っこのようだ。そうなると、0.3.8に付いてきたLinuxの64ビット版のバイナリさえ、間違ってコンパイルされていたんだと思う。
私のところでも、それで直ったようだ。
編集:
修正したLinuxのビルドをhttp://www.alloscomp.com/bitcoin/binaries/release-r123-2010-08-08/ に上げた。どうぞ！
それで何が変わるのか、正直よく分からない。そもそもなぜそのdefineが作られたのか不思議だ。コードは、SSE2のCPUで動いているかどうかを自分で判断できるはずだ。私の4xSSE2のハッシュ関数を0.3.6の元の関数と比べていて気づいたんだが、つまり0.3.6以降の64ビット版のビルドは、どれも1枚もコインを生成できなかったということだ。なぜmakefileにそのdefineを入れたのか、サトシが教えてくれるかもしれない。
公式0.3.8 Linux 64bitバイナリでDebian sid上で「楽しい」gdbセッションをしたところだ。同じバグ。SHA256Transformからの戻り値の出力状態が常に初期状態と同じだ。で…公式0.3.8 64bit Linuxバイナリ（bin/64にあるもの）で本当にブロックを生成した人はいるのか？ ああ、それとsvnの変更ログをざっと見たところ、そのバグはおそらくr118 = 0.3.6から存在していた。ああ、それと公式バイナリをstripするのが良いアイデアだなんて、一体どこのどいつが思ったんだ？ ディスアセンブラでSHA256Transformを探すのに30分も無駄にした。
公式0.3.8 Linux 64bitバイナリでDebian sid上で「楽しい」gdbセッションをしたところだ。同じバグ。SHA256Transformからの戻り値の出力状態が常に初期状態と同じだ。で…公式0.3.8 64bit Linuxバイナリ（bin/64にあるもの）で本当にブロックを生成した人はいるのか？ ああ、それとsvnの変更ログをざっと見たところ、そのバグはおそらくr118 = 0.3.6から存在していた。ああ、それと公式バイナリをstripするのが良いアイデアだなんて、一体どこのどいつが思ったんだ？ ディスアセンブラでSHA256Transformを探すのに30分も無駄にした。
いい仕事だ！ サトシにPMを送る頃だな。
苦労への報酬として5.01を送った。
32ビットLinuxビルドは自分でビルドしようとしない人にとっては問題ないようだ。正しくビルドされた64ビット版よりも数パーセント遅いだけだ。
そのフラグはSSE2を持っていないかもしれない古い32ビットマシン向けに入れられたのだろう。残念ながら、SSE2なしの64ビットx86_64というものは存在しないので、条件付きコンパイルにより中身が空になり、何もしない関数が生成された。
そのフラグはSSE2を持っていないかもしれない古い32ビットマシン向けに入れられたのだろう。残念ながら、SSE2なしの64ビットx86_64というものは存在しないので、条件付きコンパイルにより中身が空になり、何もしない関数が生成された。
cmakeなどを使うべきだというもう一つの論拠だ。
SSE2はわずか2%の高速化しか追加せず、互換性の問題に見合わないと判断した。より安全なオプションを選ぼうとしていた。
Crypto++が実行時にSSE2を使用するかどうかを決定しているようには見えない。ブロックカウントパラメーターを決定するためにSSE2を検出する箇所が1つあるが、SSE2関連の部分はすべてコンパイル時の#ifdefであり、実行時にどのように切り替わるかわからない。見ている場所が間違っているのかもしれない。
すべてのmakefileでSSE2を有効にすべきだろうか？ 64ビットでコンパイルする人がいる場合はそうしなければならないようだ。
Linux 0.3.8リリースの64ビット部分を再コンパイルする。
SSE2はわずか2%の高速化しか追加せず、互換性の問題に見合わないと判断した。
その点は理解できる。非SSE2マシンではクライアントがクラッシュするから、だよね？ 実際にはどちらが簡単かによる。互換性を壊すような機能を有効にすると、痛い目に遭うのは非技術系のクライアントユーザーだけだ。彼らの視点からすると、なぜか動かないとしか思えない。
ビルドのメモを充実させた方がいいと思う。例えば（64ビットシステムでコンパイルする場合は、この部分を必ず行うこと）のように。
一つのソースブランチで複数のオペレーティングシステムにクロスコンパイルするのは常に厄介な話だ。 😄
cmakeなどを使うべきだというもう一つの論拠だ。
その通りだ。
最終的にはビルドに関するすべての煩わしさを解消し、win/unix 32/64ビットのすべてのプラットフォームの組み合わせで信頼できるビルド手順を確立するつもりだ。
そういえば、現在Windows向けのx64ビルドに取り組んでいるが、64ビットMSVCではX86_SHA256_HashBlocks関数がプロジェクトに存在しない外部定義に委ねられていることに気づいた。元のCryptoPPライブラリでは別のasmモジュールにあるようだ。Windows上でx64をビルドしている人たちは、C言語ソースのshaバージョンを使用するようにdefineを設定しているのだろうか？
再ビルドした64ビット版のLinux用0.3.8.1をアップロードした。難易度1でテストを実行し、ブロックが生成された。
ダウンロード：http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/bitcoin-0.3.8.1-linux.tar.gz/download
lfmとArtForzが見せた名探偵ぶりへの敬意として、修復された自分の64ビットLinuxマシンが最初に発見したコインを彼らに送る。よくやった、お二人さん。（lfm、アドレスを書いてくれ）
将来のbitcoin/bitcoindに、ハッシングが正しく動作していることを確認する内部セルフテストがあるといい。専用ハードウェアの様々な選択肢を試す人が増えていく中で、現在我々が持っているのは不確実な「difficulty 1」のポイントツーポイントテストしかないように思える。「既知の正しい」ハードコードされたハッシュシードがあれば、もっと良くなるはずだ。
lfmとArtForzが見せた名探偵ぶりへの敬意として、修復された自分の64ビットLinuxマシンが最初に発見したコインを彼らに送る。よくやった、お二人さん。（lfm、アドレスを書いてくれ）
ここに：1HKXYYPCzQptzJsaq2nt8xUgsWNVFRfJWDあるいはここに：75.158.131.108
Ground Loop将来のbitcoin/bitcoindに、ハッシングが正しく動作していることを確認する内部セルフテストがあるといい。専用ハードウェアの様々な選択肢を試す人が増えていく中で、現在我々が持っているのは不確実な「difficulty 1」のポイントツーポイントテストしかないように思える。「既知の正しい」ハードコードされたハッシュシードがあれば、もっと良くなるはずだ。
うん、実行時に「テストベクター」をいくつか持つのはいいかもしれない。だが結局、改造する人間は「ただ遅くなるだけだ！」と言ってテストベクターを取り除くかもしれない（理屈が通っているかは別として）。
SHAバリアント用にきちんと定義されたフックがあれば、テストコードが除去される可能性は減るかもしれない。世の中のすべての利用者にうまく働くフックを、どう設計すればいいのかは、はっきりとは分からない。GPUコードやSSEコードのように、複数のナンスを並列に試すような場合もサポートする必要がある。
lfmとArtForzが見せた名探偵ぶりへの敬意として、修復された自分の64ビットLinuxマシンが最初に発見したコインを彼らに送る。 よくやった、お二人さん。（lfm、アドレスを書いてくれ）
将来のbitcoin/bitcoindに、ハッシングが正しく動作していることを確認する内部セルフテストがあるといい。専用ハードウェアの様々な選択肢を試す人が増えていく中で、現在我々が持っているのは不確実な「difficulty 1」のポイントツーポイントテストしかないように思える。「既知の正しい」ハードコードされたハッシュシードがあれば、もっと良くなるはずだ。
ArtForzは実際にBitcoinMiner()を点検するパッチを作っている。http://pastebin.com/YGUcqPYK