バージョン0.3.11アップグレードアラート付き
バージョン0.3.11が利用可能になった。
変更点：
- ロード時のblk*.datの検証
-4wayコードを-march=amdfam10でビルドし、少し高速化- 時計がずれすぎている場合の警告
- 警告/エラー/アラートがgetinfoコマンドでも確認可能
- アラートシステム
アラートシステムは、重要なセキュリティアップデートのためにアップグレードが必要なバージョンを実行している場合、ステータスバーに通知を表示してアラートできる。
アラートに応答して、ノードはセーフモードに入ることもあり、以下のjson-rpcコマンド（自動化されたウェブサイトで使用）を無効にして、アップグレードの機会が得られるまで資金の損失から保護する：sendtoaddress getbalance getreceivedbyaddress getreceivedbylabel listreceivedbyaddress listreceivedbylabel
誤報だと判断してリスクを取りたい場合は、-disablesafemodeスイッチを使って再有効化できる。
これは重要な安全性の改善だ。可能な問題の大部分について、問題が発見されたらすぐに全員に警告し、不正な情報に基づいて行動するのを防ぐことができる。
ノードはアラートに応答して稼働を継続し生成を停止しないため、旧バージョンがフォークを作ろうとするかもしれないが、アラートシステムはユーザーがフォーク内の何かに基づいて行動しないよう警告できる。
ダウンロード：http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.11/
良い話だ。他のスレッドを追っていない人のために言っておくと、アラートは特定の鍵（サトシが保持）で署名されている場合にのみ受け入れられる、という点を強調しておくことが重要だと思う。一般的なノードはアラートを生成できない。
サトシ・ナカモトの投稿（2010年8月27日21:54 UTC）
- -march=amdfam10でビルド。
-4wayが若干高速になる-marchは古いシステムとのABI互換性を壊さないのかな？
その可能性は十分ある。-mtune=XXXXの方が好ましいかもしれない。-march=XXXXはコンパイラーがバイナリはamdfam10でのみ実行されると想定するからだ。
… -march=XXXXはコンパイラーがバイナリはamdfam10でのみ実行されると想定する。
まさにそれが狙いだ。だが-march=amdfam10を使うのは汚いハックだという点には同意する。この場合、ソースから最もコンパクトで効率的なSSE2コードを生成する。よりクリーンな代替手段はインラインアセンブラだろう。
確か、gccの__attribute__を使って関数ごとに-marchを指定することが可能なはずだ。そうすれば、問題の関数だけが最適化され、ユーザーが -4wayを指定しなければ、他のすべてが問題ないはずだ。
ジェフ・ガージックの投稿（2010年8月27日23:35 UTC）… -march=XXXXはコンパイラーがバイナリはamdfam10でのみ実行されると想定する。
まさにそれが狙いだ。だが-march=amdfam10を使うのは汚いハックだという点には同意する。この場合、ソースから最もコンパクトで効率的なSSE2コードを生成する。よりクリーンな代替手段はインラインアセンブラだろう。
で、どのCPUがこれをサポートするの？ 最新のAMDだけ？ そしてこのためにどれだけのシステムを除外することになる？
で、どのCPUがこれをサポートするの？ 最新のAMDだけ？ そしてこのためにどれだけのシステムを除外することになる？
私の知る限り、Phenom、i5、i7だ。これらは128ビットのSSE2命令デコーダーを持ち、そもそも恩恵を受けるCPUはこれらだけで、それ以前のCPUはすべて遅くなる。「AMDのK10でしか動かない」ではなく「コンパイラーに必要な正確なアセンブリコードを生成させつつ、将来的に他のベクトルエンジンをサポートする柔軟性を維持する」と考えてほしい。
BioMikeの投稿（2010年8月28日08:24 UTC）で、どのCPUがこれをサポートするの？ 最新のAMDだけ？ そしてこのためにどれだけのシステムを除外することになる？
私の知る限り、Phenom、i5、i7だ。これらは128ビットのSSE2命令デコーダーを持ち、そもそも恩恵を受けるCPUはこれらだけで、それ以前のCPUはすべて遅くなる。「AMDのK10でしか動かない」ではなく「コンパイラーに必要な正確なアセンブリコードを生成させつつ、将来的に他のベクトルエンジンをサポートする柔軟性を維持する」と考えてほしい。
ああ。なるほど。情報をありがとう。
「バージョン情報」ダイアログはまだ0.3.10.1 betaと表示されている。
「バージョン情報」ダイアログはまだ0.3.10.1 betaと表示されている。
どのOSかな？ WindowsとLinux 64ビット版を実行してAboutダイアログを確認した。
Mac版はまだ0.3.10.1だ。
paveloの投稿（2010年8月28日07:36 UTC）確か、gccの__attribute__を使って関数ごとに-marchを指定することが可能なはずだ。そうすれば、問題の関数だけが最適化され、ユーザーが
-4wayを指定しなければ、他のすべてが問題ないはずだ。
最初の投稿をより具体的に更新した。-4wayコードだけがこの方法でコンパイルされる。
torserversの投稿（2010年8月28日13:00 UTC）「バージョン情報」ダイアログはまだ0.3.10.1 betaと表示されている。
どのOSかな？ WindowsとLinux 64ビット版を実行してAboutダイアログを確認した。
気にしないでくれ。問題ない。 🙄
良い話だ。他のスレッドを追っていない人のために言っておくと、アラートは特定の鍵（サトシが保持）で署名されている場合にのみ受け入れられる、という点を強調しておくことが重要だと思う。一般的なノードはアラートを生成できない。
将来、bitcoinクライアントが複数できたときのことが気になる。メッセージは、様々な作者の公開鍵を持つ様々なクライアントのネットワーク上で送受信されるのかな？ それとも一時的な解決策なのかな？
これは現在技術的にどう実装されているのかな？
アラートはトランザクションと同じ方法でブロードキャストされる。各ノードはアラートを受け入れたら、それをすべてのpeerに送信する。
Bitcoinは別の鍵で署名されたアラートはリレーしない。もし異なるアラート鍵が使われ始めると、どのクライアントでも伝播はあまりよくないかもしれない。