バージョン 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日 12: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日 14:35 UTC）… -march=XXXXはコンパイラーがバイナリはamdfam10でのみ実行されると想定する。
まさにそれが望むことだ。しかし同意する。-march=amdfam10を使うのはダーティハックだ。この場合、ソースから最もコンパクトで効率的なSSE2コードを生成する。よりクリーンな代替案はインラインアセンブラだろう。
で、どの CPU がこれをサポートするのか？ 最新の AMD だけか？ そしてこのためにどれだけのシステムを除外することになるのか？
で、どの CPU がこれをサポートするのか？ 最新の AMD だけか？ そしてこのためにどれだけのシステムを除外することになるのか？
私の知る限り、Phenom、i5、i7 だ。128 ビット SSE2 命令デコーダーを持つ唯一の CPU であり、全く恩恵を受けるのはこれらだけで、それ以前の CPU はすべて遅くなる。「AMD の K10 でしか動かない」ではなく「コンパイラーに必要な正確なアセンブリコードを生成させつつ、将来的に他のベクトルエンジンをサポートする柔軟性を維持する」と考えてほしい。
BioMikeの投稿（2010年8月27日 23: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月27日 22:36 UTC）確か、gcc の__attribute__を使って関数ごとに-march を指定することが可能なはずだ。そうすれば、問題の関数だけが最適化され、ユーザーが
-4wayを指定しなければ、他のすべてが問題ないはずだ。
最初の投稿をより具体的に更新した。-4way コードだけがこの方法でコンパイルされる。
torserversの投稿（2010年8月28日 13:00 UTC）「About」ダイアログがまだ 0.3.10.1 beta と表示している。
どのOSだ？ WindowsとLinuxの64bit版を実行してaboutダイアログを確認したが。
気にしないでくれ。問題ない。 🙄
良い話だ。他のスレッドを追っていない人のために言っておくと、アラートは特定の鍵（サトシが保持）で署名されている場合にのみ受け入れられる、という点を強調しておくことが重要だと思う。一般的なノードはアラートを生成できない。
将来、bitcoin クライアントが複数できたときのことが気になる。メッセージは、様々な作者の公開鍵を持つ様々なクライアントのネットワーク上で送受信されるのか？ それとも一時的な解決策なのか？
これは現在技術的にどう実装されているのか？