0.3.8 で Bitcoin 生成が壊れた？
何か問題が発生しているのではないかと疑い始めていた。システムがコインの生成をやめたように見えたからである。1日あたり約 1 ブロックだったのが、1 週間でゼロになった。
IRC で ArtForz が、空のウォレットディレクトリで互いにのみ接続された 2 つのノードだけの隔離テストネットを実行してみることを提案した。クアッドコアのシステムを 2 台用意してセットアップした。合計 8000 khash/秒以上のハッシュレートでありながら、約 90分間ブロックが 1 つも生成されていない。これは問題の証拠と言えるだろうか、それともさらなる不運に過ぎないのだろうか？
システムは Linux 64 ビットで、1 台は Intel クアッド Q6600、もう 1 台は AMD クアッド Phenom II 940 である。
公式 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
将来の bitcoin/bitcoind に、ハッシングが正しく動作していることを確認する内部セルフテストがあるといい。専用ハードウェアの様々な選択肢を試す人が増えていく中で、現在我々が持っているのは不確実な「difficulty 1」のポイントツーポイントテストしかないように思える。「既知の正しい」ハードコードされたハッシュシードがあれば、もっと良くなるはずだ。
実行時に「テストベクター」をいくつか持つのはいいかもしれない。だが結局、改造する人間は「ただ遅くなるだけだ！」と言ってテストベクターを取り除くかもしれない（理屈が通っているかは別として）。
SHA バリアント用にきちんと定義されたフックがあれば、テストコードが除去される可能性は減るかもしれない。ただし、世の中のすべての利用者に対してどう動くべきかをフックとして設計する方法は、はっきりとは分からない。GPU コードや SSE コードのように、複数のナンスを並列に試すような場合もサポートする必要がある。
lfmとArtForzが見せてくれた粘り強い調査への敬意として、修復された自分の64ビットLinuxマシンが最初に発見したコインを彼らに送る。 よくやった、お二人さん。（lfm、アドレスを書いてくれ）
将来のbitcoin/bitcoindに、ハッシングが正しく動作していることを確認する内部セルフテストがあるといい。専用ハードウェアの様々な選択肢を試す人が増えていく中で、現在我々が持っているのは不確実な「difficulty 1」のポイントツーポイントテストしかないように思える。「既知の正しい」ハードコードされたハッシュシードがあれば、もっと良くなるはずだ。
ArtForz は実際に BitcoinMiner()を点検するパッチを作っている。http://pastebin.com/YGUcqPYK