Bitcoin 0.3.1リリース
これはバグ修正のメンテナンスリリースだ。SourceForgeにアップロード済みだ。Mac OS Xには修正が不要だったため、更新する必要はない。0.3.0のままで問題ない。
ダウンロードリンクはbitcoin.orgにある。
変更点:
- チアゴ・ファリアによるポルトガル語翻訳を追加Windows
- ユーザー名にASCII以外の文字が含まれている場合の22DbRunRecoveryExceptionの修正Linux
- ラズロによる生成スレッドを最低優先度に下げる修正
- libcryptoのリンクに問題がある場合の修正
- ギャビン・アンドレセンによる「ウィンドウシステム起動時に開始」オプションの実装
サトシ、こんにちは。 インストールの前に、バックアップは必要かな？
まあ、バックアップして損はないし、定期的にバックアップするのは良い習慣だが、いや、このインストール前にバックアップは必須ではない。
オッケー、了解 😊
もう数日間計算し続けているから、最初からやり直したくないんだ！！！！
こちらでは、 改善されなかった。 同じ症状のまま。ただしbelownormalに設定できない。アクセスが拒否される！！
編集： おかしなことに、FirefoxやWindowsエクスプローラーはすぐに開く。少しもたつくが。しかしgomezのようなものは開かない！
特定の問題があるとは思わない。多くのものを同時に実行していて、メモリーが一杯になりページファイルを使用しているためにシステムが遅くなっているのだと思う。生成を停止するとCPUが0%に下がることを確認しているので、CPU使用率は確実にすべてアイドル優先度だ。0.3.1にはこれらの問題に影響する変更は含まれていない。
インストール、再インストール、あるいはバックアップのせいでウォレットを失うことが本当に怖い。別のスレッドでは、あるユーザーがウォレットをバックアップした結果、自分のbitcoinをすべて、永遠に失ってしまった。
このスレッドを見てくれ：http://bitcointalk.org/index.php?topic=359.0
バックアップとリストアを正しく行うための手順を一歩ずつまとめてもらえないだろうか。
あいつは自分のコインを二重支払いしようとして、システムがそれを防いだんだ。その過程で、ウォレットファイルを入れ替えてるうちに片方を失くして、使っていなかったコインも失くしちゃったんだよ。
wallet.datをバックアップするだけで十分だ。bitcoin faucetでもらえる無料コインで試してみればいい。
このビルドで私の問題は解決した（追加情報はこのトピックを参照http://bitcointalk.org/index.php?topic=373.0）。
特定の問題があるとは思わない。多くのものを同時に実行していて、メモリーが一杯になりページファイルを使用しているためにシステムが遅くなっているのだと思う。生成を停止するとCPUが0%に下がることを確認しているので、CPU使用率は確実にすべてアイドル優先度だ。0.3.1にはこれらの問題に影響する変更は含まれていない。
ありえる。 だが、決して失礼なつもりではないんだけど、こういう類のパフォーマンス低下はbitcoinを動かしているときにしか出ていない。BOINCはアクティブだが、現在はプロジェクトは何も動かしていない。
メモリー3GB、 キャッシュ1524、 利用可能1573、 空き108。bitcoinを止めるつもりはないが、少し奇妙に思える 😊
何か送ってほしいものはある？
追伸…… bitcoin実行中に余分なディスクのスラッシングには気づいていない 😊
Windows上では、コイン生成の優先度は依然として通常のままだ。BitCoinをコイン生成モードで実行し、CPUを全部食い尽くすもの（例えばCPU Hog: http://www.microtask.ca/cpuhog.html）を起動すると、BitCoinとCPU Hogが50/50でCPUを分け合い、CPU Hogが全CPUを取ってBitCoinがアイドル/低プロセスでのみ動くという状態にはならないことが分かる。khash/sも半分に減っているので、スレッドが通常より低い優先度で動いていないさらなる証拠だ。
事前にコア数を数えておくべきだった 🤐。Windows 2000、XP、Vista 32/64、Windows 7 32/64でテストした結果、バグではないことを確認した。
Linuxクライアント（64ビット）では、「閉じる時に最小化」がまだトレイに最小化する（しばらくすると複数のトレイアイコンを生成してXサーバーがハングする）。
しかし、スレッドの優先度は全て適切にniceされているようだ。CPUを全て使っているスレッドはnice 19で、0や2の他のスレッドはCPUを使っていないので、システムはレスポンシブに感じる。
[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
1 S knightmb 13676 13591 13682 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 S knightmb 13676 13591 13683 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 S knightmb 13676 13591 13685 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 S knightmb 13676 13591 13686 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 S knightmb 13676 13591 13687 0 9 82 2 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 R knightmb 13676 13591 13689 70 9 99 19 - 113704 - 14:52 pts/1 00:09:34 ./bitcoin
1 R knightmb 13676 13591 13714 71 9 99 19 - 113704 - 14:53 pts/1 00:09:39 ./bitcoin
1 R knightmb 13676 13591 13924 72 9 99 19 - 113704 - 14:53 pts/1 00:08:19 ./bitcoin
1 R knightmb 13676 13591 13314 73 9 99 19 - 113704 - 14:53 pts/1 00:08:19 ./bitcoin
1 R knightmb 13676 13591 13114 74 9 99 19 - 113704 - 14:53 pts/1 00:08:19 ./bitcoin
1 R knightmb 13676 13591 13984 75 9 99 19 - 113704 - 14:53 pts/1 00:09:19 ./bitcoin
1 R knightmb 13676 13591 13214 76 9 99 19 - 113704 - 14:53 pts/1 00:09:09 ./bitcoin
1 R knightmb 13676 13591 13917 77 9 99 19 - 113704 - 14:53 pts/1 00:08:12 ./bitcoin
1 R knightmb 13676 13591 13919 78 9 99 19 - 113704 - 14:53 pts/1 00:08:39 ./bitcoin
1 R knightmb 13676 13591 13934 79 9 99 19 - 113704 - 14:53 pts/1 00:08:51 ./bitcoin
1 R knightmb 13676 13591 13114 80 9 99 19 - 113704 - 14:53 pts/1 00:08:39 ./bitcoin
1 R knightmb 13676 13591 13624 81 9 99 19 - 113704 - 14:53 pts/1 00:09:11 ./bitcoin
1 R knightmb 13676 13591 13224 82 9 99 19 - 113704 - 14:53 pts/1 00:08:39 ./bitcoin
1 R knightmb 13676 13591 13374 83 9 99 19 - 113704 - 14:53 pts/1 00:08:55 ./bitcoin
1 R knightmb 13676 13591 13261 84 9 99 19 - 113704 - 14:53 pts/1 00:09:43 ./bitcoin
1 R knightmb 13676 13591 13171 85 9 99 19 - 113704 - 14:53 pts/1 00:08:55 ./bitcoin
1 R knightmb 13676 13591 13741 86 9 99 19 - 113704 - 14:53 pts/1 00:08:23 ./bitcoin
1 R knightmb 13676 13591 13371 87 9 99 19 - 113704 - 14:53 pts/1 00:09:42 ./bitcoin
1 R knightmb 13676 13591 13690 88 9 99 19 - 113704 - 14:53 pts/1 00:08:39 ./bitcoin
1 R knightmb 13676 13591 13234 89 9 99 19 - 113704 - 14:53 pts/1 00:08:33 ./bitcoin
1 R knightmb 13676 13591 13703 90 9 99 19 - 113704 - 14:53 pts/1 00:08:38 ./bitcoin
1 R knightmb 13676 13591 13991 91 9 99 19 - 113704 - 14:53 pts/1 00:08:39 ./bitcoin「Start BitCoin on window system startup」は何をするものなのか、正確にはわからないんだけど？
ライブラリエラーについて、古めのLinuxクライアント（1つはたった1年前のもの）で /usr/lib/libstdc++.so.6 ‘GLIBCXX_3.4.11’ not foundが出る。ファイルを確認したところ、libstdc++.so.10にリンクされているが、十分なバージョンかどうかわからない。
ごめん、これはほとんど「？？」状態だ。 完全なバカじゃないつもりだが、大部分はまるで頭に入ってこない！！ 😊
listreceivedbyaddressとgetreceivedbyaddressコマンドがbitcoindのヘルプで重複している。（0.3.0でも同様。）
listreceivedbyaddressとgetreceivedbyaddressコマンドがbitcoindのヘルプで重複している。（0.3.0でも同様。）
うん！ きっとそうなんだろうね！！ もう言ったが、まったくわからない！ 一体何の話をしているんだ？？？
Windows上では、コイン生成の優先度は依然として通常のままだ。BitCoinをコイン生成モードで実行し、CPUを全部食い尽くすもの（例えばCPU Hog:
http://www.microtask.ca/cpuhog.html）を起動すると、BitCoinとCPU Hogが50/50でCPUを分け合い、CPU Hogが全CPUを取ってBitCoinがアイドル/低プロセスでのみ動くという状態にはならないことが分かる。khash/sも半分に減っているので、スレッドが通常より低い優先度で動いていないさらなる証拠だ。
これを再現できなかった。デュアルプロセッサーなので、2つのメモリーホグを実行した。タスクマネージャーによると、BitcoinのCPU使用率は0%だった。khash/secメーターはCPUを取得できなかったため更新されず、止まったままだった。
デュアルプロセッサーなの？ シングルプロセッサーのホグを実行していたんじゃないよね？
knightmbの投稿（2010年7月15日19:37 UTC）Windows上では、コイン生成の優先度は依然として通常のままだ。BitCoinをコイン生成モードで実行し、CPUを全部食い尽くすもの（例えばCPU Hog:
http://www.microtask.ca/cpuhog.html）を起動すると、BitCoinとCPU Hogが50/50でCPUを分け合い、CPU Hogが全CPUを取ってBitCoinがアイドル/低プロセスでのみ動くという状態にはならないことが分かる。khash/sも半分に減っているので、スレッドが通常より低い優先度で動いていないさらなる証拠だ。これを再現できなかった。デュアルプロセッサーなので、2つのメモリーホグを実行した。タスクマネージャーによると、BitcoinのCPU使用率は0%だった。khash/secメーターはCPUを取得できなかったため更新されず、止まったままだった。
デュアルプロセッサーなの？ シングルプロセッサーのホグを実行していたんじゃないよね？
LOL、おそらくその通りだ。周りにPCがありすぎて、どれがシングルコア、デュアルコア、クアッド、8コアかを把握するのが難しい。シングルプロセッサーPCで再テストする。
ああ、その通り、問題なく動く。コア数を先に数えなかった自分に、額をぴしゃり。というわけで優先度のバグは取り下げる。投稿を編集しておく。Windows 2000、XP、Vista、7で問題なく動作する。
Linuxクライアント（64ビット）では、「閉じる時に最小化」がまだトレイに最小化する（しばらくすると複数のトレイアイコンを生成してXサーバーがハングする）。
最初の投稿をこの修正を含むLinux用rc2へのリンクで更新した。修正されているか確認してほしい。ありがとう！
http://www.bitcoin.org/download/bitcoin-0.3.1.rc2-linux.tar.gz
listreceivedbyaddressとgetreceivedbyaddressコマンドがbitcoindのヘルプで重複している。（0.3.0でも同様。）
はい、バグだ。次のバージョンで修正する必要がある。
Linuxでは、0.3.0は生成時にnice値が0になるが、0.3.1では生成スレッドがnice値19になり、他のスレッドは0のままだ。良さそうだ。
「Start BitCoin on window system startup」は何をするものなのか、正確にはわからないんだけど？
Windowsでは、Bitcoin.exeをシステムレジストリのHKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run、または代替としてHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Runに登録するべきだ。
どちらも起きていないようだ。だが「Startup」フォルダーには入った。それはいかにもWindows 95っぽい（冗談だ……Microsoftはこれをめちゃくちゃにしてしまっていて、笑えるどころではない）。レジストリ設定を勧める理由はいくつかあり、ほとんどのソフトウェアがその場所に登録するという事実もそのひとつだ。個人的にはStartupフォルダーの方が見栄えが良く、Windowsのほとんどのソフトウェアが「そう振る舞うべき」だと思っているとしても、だ。
Windowsでこの新バージョンの完全なフォレンジックは行っていないが、Windowsインストーラを使った私のインストールは問題なく進んだようだ。
しかし、スレッドの優先度は全て適切にniceされているようだ。CPUを全て使っているスレッドはnice 19で、0や2の他のスレッドはCPUを使っていないので、システムはレスポンシブに感じる。
確認した。bitcoindは確かにniceになった。
どちらも起きていないようだ。だが「Startup」フォルダーには入った。それはいかにもWindows 95っぽい（冗談だ……Microsoftはこれをめちゃくちゃにしてしまっていて、笑えるどころではない）。レジストリ設定を勧める理由はいくつかあり、ほとんどのソフトウェアがその場所に登録するという事実もそのひとつだ。個人的にはStartupフォルダーの方が見栄えが良く、Windowsのほとんどのソフトウェアが「そう振る舞うべき」だと思っているとしても、だ。
どちらでもいける。スタートアップフォルダーの利点は、すでにBitcoinのディレクトリとアンインストーラーを消してしまっている場合でも、エンドユーザーが通常のUI（regeditではなく）で目で見て手動で削除できることだ。手動で削除しても、Bitcoinが執拗に再追加し続けることはない。
OpenOfficeも、リンクをスタートアップフォルダーに入れる例の一つだ。
knightmbの投稿（2010年7月15日20:15 UTC）Linuxクライアント（64ビット）では、「閉じる時に最小化」がまだトレイに最小化する（しばらくすると複数のトレイアイコンを生成してXサーバーがハングする）。
最初の投稿をこの修正を含むLinux用rc2へのリンクで更新した。修正されているか確認してほしい。ありがとう！
http://www.bitcoin.org/download/bitcoin-0.3.1.rc2-linux.tar.gz
サトシ、バグを修正したんじゃなくて、トレイ最小化コードを丸ごと削除しただけだ。オプションにしてもらえないかな？ 元のバグは発生していないし、トレイ最小化機能をとても気に入っている。
非公開スイッチ -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クライアントは「ネットワーク」から自分を切り離し、他のすべてのクライアントが自分たちだけでネットワーク全体だと思い込んでいる。Windowsクライアントでnetstat -a -nを実行すると、内部クライアントとIRCブートストラップチャンネルにしか接続しておらず、外部の他の誰にもほとんど接続していないことが分かる。これが起きていると分かるのは、ブロック数がローカルネットワークの外（世界の他のインターネット）で実際に起きていることから遅れ始めるからだ。
自己崩壊ループのようなものだろうか？ Linuxクライアントではこの問題は起きない。処理できる限りの数まで、喜んで接続し、また接続を受け入れる。悪意のある人がいれば、Windowsクライアントに対する一種のDoSと言えるかもしれない。
良い指摘だ。8台以上のLANノードを1つのゲートウェイノードに接続する場合は、ゲートウェイノードが着信接続を受信できるように設定した方が良い。そうしないと、ゲートウェイノードが8つ以上の接続を持っている間は、新しい外向き接続を追加しようとしない。接続している外部ノードが出入りしても、それらを置き換える新しい外向き接続を作成しない。着信接続を受け入れられるようにすれば、他の多くのノードがあなたに接続してくるので問題ない。
良い指摘だ。8台以上のLANノードを1つのゲートウェイノードに接続する場合は、ゲートウェイノードが着信接続を受信できるように設定した方が良い。そうしないと、ゲートウェイノードが8つ以上の接続を持っている間は、新しい外向き接続を追加しようとしない。接続している外部ノードが出入りしても、それらを置き換える新しい外向き接続を作成しない。着信接続を受け入れられるようにすれば、他の多くのノードがあなたに接続してくるので問題ない。
Windowsクライアントにはポート8333を開いた静的IPがあり、ゲートウェイデバイスから他のピアに接続し、他のピアも接続してくるのが見えた。しかし8を超えると、外向きのピア接続を止め、しばらくすると受信ピアも止まった。WAN上の外部よりもLAN上のピアだけを気にしているようだ。Linuxクライアントの動作は異なる。50人が接続していても、外向きの接続を求め続け、受信ピアも入ってくる。
これは自分のように何百台ものPCを使える人だけの問題だが、逆に言えば、1台のクライアントに8回以上接続するPCをセットアップすれば、しばらくするとかわいそうなWindowsクライアントは、ネットワーク上でブロックを解いているつもりが、実は過去に閉じ込められた独自のマトリックス世界に吸い込まれることになる。
もちろんこれは理論上の攻撃で、心配して眠れなくなるようなものではないが、将来のために提起しておく。これを無効化する最も簡単な方法は、IPの自己チェックコードを入れることだ。基本的に、デュアルノード/クライアントモードで実行している時に、LAN/同一IPアドレスなどからではない8つ以上の接続があることを確認する必要がある。
異なるシステムに存在しない多くの依存関係のためだ。可能な限り静的リンクする方が簡単だ。サイズもそれほど増えない。
サイズ（静的バイナリは自分の場合8倍大きい）が問題ではなく、セキュリティだと思う。
Boost、OpenSSL、Berkeley DBはUNIXシステムではかなり一般的で（多くのものが依存している）、wxWidgets（唯一の難点は、Bitcoinが安定版ではなく現在の開発ブランチを使っていること）もそうだ。第二に、静的リンクは常に実行できるとは限らない（自分の場合、libpng-1.2を読み込もうとするが、システムにはlibpng-1.4があり、静的版は読み込みに失敗する）。第三に、OpenSSLにはセキュリティの問題がなかったわけではないので、静的コンパイルにより、システムが更新された安全なバージョンを提供していても、人々はセキュリティに問題のあるバージョンを使い続けることになる。
Windows 0.3.1 rc1とLinux 0.3.1 rc2をSourceForgeにアップロードし、ホームページのリンクを更新した。
最初の投稿に記載されている問題に該当しない限り、0.3.1に更新する必要はない。既に動作している場合は、0.3.0のままで構わない。
knightmbの投稿（2010年7月15日20:15 UTC）Linuxクライアント（64ビット）では、「閉じる時に最小化」がまだトレイに最小化する（しばらくすると複数のトレイアイコンを生成してXサーバーがハングする）。
最初の投稿をこの修正を含むLinux用rc2へのリンクで更新した。修正されているか確認してほしい。ありがとう！
http://www.bitcoin.org/download/bitcoin-0.3.1.rc2-linux.tar.gz
新しいリリース候補をテストしている。「閉じるときに最小化」が誤ってトレイに最小化される問題は解決された。Xサーバーのクラッシュも起きていない、いいね！ あとはあのトレイ機能をまた動作させられればいいんだが 😉