0.3.1リリース候補、テストしてください
これはバグ修正のメンテナンスリリースだ。SourceForgeにアップロード済みだ。Mac OS Xには修正の必要がなかったため、更新は不要だ。0.3.0のままで問題ない。
ダウンロードリンクはbitcoin.orgにある。
変更点：
- Tiago Fariaによるポルトガル語翻訳を追加 Windows
- ユーザー名に非ASCII文字が含まれている場合の22DbRunRecoveryExceptionの修正 Linux
- Laszloによる生成スレッドを最低優先度に下げる修正
- libcryptoのリンク問題が発生している場合の修正
- Gavin Andresenによる「ウィンドウシステム起動時に開始」オプションの実装
これはバグ修正のメンテナンスリリースだ。SourceForgeにアップロード済みだ。Mac OS Xには修正が不要だったため、更新する必要はない。0.3.0のままで問題ない。
ダウンロードリンクはbitcoin.orgにある。
変更点:
- Tiago Fariaによるポルトガル語翻訳を追加 Windows
- ユーザー名にASCII以外の文字が含まれている場合の22DbRunRecoveryExceptionの修正 Linux
- Laszloによる生成スレッドを最低優先度に下げる修正
- libcryptoのリンクに問題がある場合の修正
- Gavin Andresenによる「ウィンドウシステム起動時に開始」オプションの実装
サトシ、 インストール前にバックアップが必要だろうか？
Quote from: satoshi on July 15, 2010, 05:23:48 PM
バックアップしておいて損はないし、定期的にバックアップするのは良い習慣だが、インストール前にバックアップが必須というわけではない。
了解 Smiley
もう数日間計算し続けているから、最初からやり直したくないんだ！！！！
コイン生成する前にコンピュータに完全なブロックチェーンが必要だ。まだブロックチェーンの途中なら、まだコインを生成できない。
何ブロックまで来ているか確認するには、ステータスバーの下部にある吹き出しにマウスを合わせればいい。 または https://www.bitcoin.org/en/network でネットワーク全体のブロック数を確認できる。
こちらでは、 改善されなかった。 同じ症状のまま。ただしbelownormalに設定できない。アクセスが拒否される！！
編集： おかしなことに、 FirefoxやWindowsエクスプローラーはすぐに開く。少しもたつくが。しかしgomezのようなものは開かない！
特定の問題があるとは思わない。多くのものを同時に実行していて、メモリが一杯になりページファイルを使用しているためにシステムが遅くなっているのだと思う。生成を停止するとCPUが0%に下がることを確認されたので、CPU使用率は確実にすべてアイドル優先度だ。0.3.1にはこれらの問題に影響する変更は含まれていない。
Windows上では、コイン生成の優先度は依然として通常のままだ。BitCoinをコイン生成モードで実行し、CPUを全部食い尽くすもの（例えばCPU Hog: http://www.microtask.ca/cpuhog.html）を起動すると、BitCoinとCPU Hogが50/50でCPUを分け合い、CPU Hogが全CPUを取ってBitCoinがアイドル/低プロセスでのみ動くという状態にはならないことが分かる。khash/sも半分に減っているので、スレッドが通常より低い優先度で動いていないさらなる証拠だ。
事前にコア数を数えておくべきだった Lips sealed。Windows 2000、XP、Vista 32/64、Windows 7 32/64でテストした結果、バグではないことを確認した。
Linuxクライアント（64ビット）では、「閉じる時に最小化」がまだトレイに最小化する（しばらくすると複数のトレイアイコンを生成してXサーバーがハングする）。
しかし、スレッドの優先度は全て適切にniceされているようだ。CPUを全て使っているスレッドはnice 19で、0や2の他のスレッドはCPUを使っていないので、システムはレスポンシブに感じる。 Code:[knightmb@KnightMB ~]$ ps -eflL | grep bitcoin 0 S knightmb 13676 13591 13676 0 9 80 0 - 113704 poll_s 14:52 pts/1 00:00:02 ./bitcoin 1 S knightmb 13676 13591 13681 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin …
「Start BitCoin on window system startup」が何をするのか正確にはわからないが？
ライブラリエラーについて、古めのLinuxクライアント（1つはたった1年前のもの）で**/usr/lib/libstdc++.so.6 ‘GLIBCXX_3.4.11’ not found**が出る。ファイルを確認したところ、libstdc++.so.10にリンクされているが、十分なバージョンかどうかわからない。
申し訳ないが、これはほとんどちんぷんかんぷんだ！！ 完全なバカじゃないが、大部分は理解の範疇を超えている！！ Smiley
ああ、わかった。ありがとう！ フォルダやら何やらのパスが分からなかった。一部を読み落としていたかもしれない！ Smiley
Quote from: knightmb on July 15, 2010, 07:37:10 PM
Windowsでは、コイン生成の優先度はまだ通常のままです。BitCoinをコイン生成モードで実行し、CPUをすべて使い切るもの（例えばCPU hog: http://www.microtask.ca/cpuhog.html）を起動すると、CPU HogがすべてのCPUを使いBitCoinがアイドル/低優先度でのみ実行されるのではなく、BitCoinとCPU hogがCPUを50/50で共有しているのがわかります。khash/sも半減しており、スレッドが通常より低い優先度で実行されていないことのさらなる証拠です。
これを再現できなかった。デュアルプロセッサなので、2つのメモリホグを実行した。タスクマネージャーによると、BitcoinのCPU使用率は0%だった。khash/secメーターはCPUを取得できなかったため更新されず、止まったままだった。
デュアルプロセッサか？シングルプロセッサのホグを実行していたのではないか？
Quote from: satoshi on July 15, 2010, 09:40:34 PM Quote from: knightmb on July 15, 2010, 07:37:10 PM
Windows上では、コイン生成の優先度は依然として通常のままだ。BitCoinをコイン生成モードで実行し、CPUを全部食い尽くすもの（例えばCPU Hog: http://www.microtask.ca/cpuhog.html）を起動すると、BitCoinとCPU Hogが50/50でCPUを分け合い、CPU Hogが全CPUを取ってBitCoinがアイドル/低プロセスでのみ動くという状態にはならないことが分かる。khash/sも半分に減っているので、スレッドが通常より低い優先度で動いていないさらなる証拠だ。
事前にコア数を数えておくべきだった Lips sealed。Windows 2000、XP、Vista 32/64、Windows 7 32/64でテストした結果、バグではないことを確認した。
LOL、おそらくその通りだ。周りにPCがありすぎて、どれがシングルコア、デュアルコア、クアッド、8コアかを把握するのが難しい。シングルプロセッサPCで再テストする。
ああ、その通り、問題なく動く。コア数を先に数えなかった自分を叩く。というわけで優先度のバグは取り下げる。投稿を編集しておく。Windows 2000、XP、Vista、7で問題なく動作する。
Quote from: knightmb on July 15, 2010, 08:15:46 PM
Linuxクライアント（64ビット）では、「閉じる時に最小化」がまだトレイに最小化します（しばらくするとトレイアイコンを複数生成してXサーバーがハングします）。
最初の投稿をこの修正を含むLinux用rc2へのリンクで更新した。修正されているか確認してほしい。ありがとう！
http://www.bitcoin.org/download/bitcoin-0.3.1.rc2-linux.tar.gz
Quote from: db on July 15, 2010, 08:39:08 PM
listreceivedbyaddressとgetreceivedbyaddressコマンドがbitcoindのヘルプで重複しています。（0.3.0でも同様。）
はい、バグだ。次のバージョンで修正する必要がある。
Quote from: knightmb on July 15, 2010, 08:15:46 PM
Linuxクライアント（64ビット）では、「閉じる時に最小化」がまだトレイに最小化する（しばらくすると複数のトレイアイコンを生成してXサーバーがハングする）。
しかし、スレッドの優先度は全て適切にniceされているようだ。CPUを全て使っているスレッドはnice 19で、0や2の他のスレッドはCPUを使っていないので、システムはレスポンシブに感じる。 Code:[knightmb@KnightMB ~]$ ps -eflL | grep bitcoin 0 S knightmb 13676 13591 13676 0 9 80 0 - 113704 poll_s 14:52 pts/1 00:00:02 ./bitcoin 1 S knightmb 13676 13591 13681 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin …
「Start BitCoin on window system startup」が何をするのか正確にはわからないが？
ライブラリエラーについて、古めのLinuxクライアント（1つはたった1年前のもの）で**/usr/lib/libstdc++.so.6 ‘GLIBCXX_3.4.11’ not found**が出る。ファイルを確認したところ、libstdc++.so.10にリンクされているが、十分なバージョンかどうかわからない。
確認した。bitcoindは確かにniceになった。
Quote from: satoshi on July 15, 2010, 10:07:35 PM Quote from: knightmb on July 15, 2010, 08:15:46 PM
Linuxクライアント（64ビット）では、「閉じる時に最小化」がまだトレイに最小化する（しばらくすると複数のトレイアイコンを生成してXサーバーがハングする）。
しかし、スレッドの優先度は全て適切にniceされているようだ。CPUを全て使っているスレッドはnice 19で、0や2の他のスレッドはCPUを使っていないので、システムはレスポンシブに感じる。 Code:[knightmb@KnightMB ~]$ ps -eflL | grep bitcoin 0 S knightmb 13676 13591 13676 0 9 80 0 - 113704 poll_s 14:52 pts/1 00:00:02 ./bitcoin 1 S knightmb 13676 13591 13681 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin …
「Start BitCoin on window system startup」が何をするのか正確にはわからないが？
ライブラリエラーについて、古めのLinuxクライアント（1つはたった1年前のもの）で**/usr/lib/libstdc++.so.6 ‘GLIBCXX_3.4.11’ not found**が出る。ファイルを確認したところ、libstdc++.so.10にリンクされているが、十分なバージョンかどうかわからない。
サトシ、バグを修正したんじゃなくて、トレイ最小化コードを丸ごと削除しただけだ。オプションにしてもらえないか？ 元のバグは発生していないし、トレイ最小化機能をとても気に入っている。
非公開スイッチ -minimizetotray を付けて実行すると、オプションメニューからそのオプションが利用可能になる。
修正方法がわからない。wxWidgets、GTK、またはGnomeの内部深くにある何かの問題だ。
x86 GentooのLinuxシステムで0.3.1を独自のmakefileでビルドした（静的クライアントではなくダイナミッククライアントをビルドする）。0.3.0よりスムーズに動作するようだ。
ちなみに、標準のmakefileが静的バージョンをビルドするのはなぜだろう？
Windowsクライアントで、他のクライアントを手動で（-connectオプションで）たくさん接続すると、8を超えるとWindowsクライアントが「外部」接続を切って、最初の8つ以上の内部マシンだけをネットワーク全体と思い込むことに気づいた人はいるだろうか？
Linuxクライアントをゲートウェイとして使っていたので気づかなかったが、Windowsクライアントで試したところ、最初は約10接続あったが、直接接続する50クライアントを追加した後、数は最終的に「内部クライアント」だけに落ちていった。
こうなると、ブロック数が増えなくなる。基本的にWindowsクライアントは「ネットワーク」から自分を切り離し、他のすべてのクライアントが自分たちだけでネットワーク全体だと思い込んでいる。
自己崩壊ループのようなものだろうか？ Linuxクライアントではこの問題は起きない。50人が接続していても、外向きの接続を求め続け、受信ピアも入ってくる。悪意のある人がいれば、Windowsクライアントに対する一種のDoSと言えるかもしれない。
良い指摘だ。8台以上のLANノードを1つのゲートウェイノードに接続する場合は、ゲートウェイノードが着信接続を受信できるように設定した方が良い。そうしないと、ゲートウェイノードが8つ以上の接続を持っている間は、新しい外向き接続を追加しようとしない。接続している外部ノードが出入りしても、それらを置き換える新しい外向き接続を作成しない。着信接続を受け入れられるようにすれば、他の多くのノードがあなたに接続してくるので問題ない。
Quote from: satoshi on July 16, 2010, 05:26:17 PM
良い指摘だ。8台以上のLANノードを1つのゲートウェイノードに接続するなら、ゲートウェイノードが受信接続を受けられるよう設定すべきだ。そうでないと、ゲートウェイノードが8つ以上の接続を持っている間、新しい外向き接続を試みない。接続していた外部ノードが入れ替わっても、代わりの外向き接続を作らない。受信接続を受け入れられるなら、他から十分な接続がある。
Windowsクライアントにはポート8333を開いた静的IPがあり、ゲートウェイデバイスから他のピアに接続し、他のピアも接続してくるのが見えた。しかし8を超えると、外向きのピア接続を止め、しばらくすると受信ピアも止まった。WAN上の外部よりもLAN上のピアだけを気にしているようだ。Linuxクライアントの動作は異なる。50人が接続していても、外向きの接続を求め続け、受信ピアも入ってくる。
これは自分のように何百台ものPCを使える人だけの問題だが、逆に言えば、1台のクライアントに8回以上接続するPCをセットアップすれば、しばらくするとかわいそうなWindowsクライアントは、ネットワーク上でブロックを解いているつもりが、実は過去に閉じ込められた独自のマトリックス世界に吸い込まれることになる。
もちろんこれは理論上の攻撃で、心配して眠れなくなるようなものではないが、将来のために提起しておく。これを無効化する最も簡単な方法は、IPの自己チェックコードを入れることだ。基本的に、デュアルノード/クライアントモードで実行している時に、LAN/同一IPアドレスなどからではない8つ以上の接続があることを確認する必要がある。
Quote from: satoshi on July 16, 2010, 03:09:59 PM
さまざまなシステムにない依存関係のため。できるものを静的リンクした方が簡単だ。サイズはそれほど増えない。
サイズ（静的バイナリは自分の場合8倍大きい）が問題ではなく、セキュリティだと思う。
Boost、OpenSSL、Berkeley DBはUNIXシステムではかなり一般的で（多くのものが依存している）、wxWidgets（唯一の主張は、Bitcoinが安定版ではなく現在の開発ブランチを使っていること）もそうだ。第二に、静的リンクは常に実行できるとは限らない（自分の場合、libpng-1.2を読み込もうとするが、システムにはlibpng-1.4があり、静的版は読み込みに失敗する）。第三に、OpenSSLにはセキュリティの問題がなかったわけではないので、静的コンパイルにより、システムが更新された安全なバージョンを提供していても、人々はセキュリティに問題のあるバージョンを使い続けることになる。