バージョン0.3.11 アップグレードアラート付き

10 件のメッセージ BitcoinTalk サトシ・ナカモト, BioMike, ジェフ・ガージック, tcatm, pavelo, torservers 2010年8月27日 — 2010年8月28日

サトシ・ナカモト（Satoshi Nakamoto） 2010年8月27日原文 · 個別ページ

バージョン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/

BioMike 2010年8月27日原文 · 個別ページ

Quote from: satoshi on August 27, 2010, 09:54:12 PM

バージョン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/

-marchは古いシステムとのABI互換性を壊さないのか？

ジェフ・ガージック（jgarzik） 2010年8月27日原文 · 個別ページ

Quote from: BioMike on August 27, 2010, 10:40:35 PM

Quote from: satoshi on August 27, 2010, 09:54:12 PM

バージョン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/

-marchは古いシステムとのABI互換性を壊さないのか？ Quote from: satoshi on August 27, 2010, 09:54:12 PM バージョン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/

その可能性は十分ある。-mtune=XXXXの方が好ましいかもしれない。-march=XXXXはコンパイラがバイナリはamdfam10でのみ実行されると想定するからだ。

tcatm 2010年8月28日原文 · 個別ページ

Quote from: jgarzik on August 27, 2010, 11:35:26 PM

Quote from: BioMike on August 27, 2010, 10:40:35 PM Quote from: satoshi on August 27, 2010, 09:54:12 PM

-march=amdfam10でビルドし、-4wayがわずかに高速化

-marchは古いシステムとのABI互換性を壊さないのか？

その可能性は十分ある。-mtune=XXXXの方が好ましいかもしれない。-march=XXXXはコンパイラがバイナリはamdfam10でのみ実行されると想定するからだ。

その通りだ。だが-march=amdfam10を使うのは汚いハックだという点には同意する。この場合、ソースから最もコンパクトで効率的なSSE2コードを生成する。よりクリーンな代替手段はインラインアセンブラだろう。

pavelo 2010年8月28日原文 · 個別ページ

確か、gccの__attribute__を使って関数ごとに-marchを指定することが可能なはずだ。そうすれば、問題の関数だけが最適化され、ユーザーが-4wayを指定しなければ、他のすべてが問題ないはずだ。

BioMike 2010年8月28日原文 · 個別ページ

Quote from: tcatm on August 28, 2010, 12:33:35 AM

Quote from: jgarzik on August 27, 2010, 11:35:26 PM

… -march=XXXXはコンパイラがバイナリはamdfam10でのみ実行されると想定することを意味する。

その通りだ。だが-march=amdfam10を使うのは汚いハックだという点には同意する。この場合、ソースから最もコンパクトで効率的なSSE2コードを生成する。よりクリーンな代替手段はインラインアセンブラだろう。 Quote from: jgarzik on August 27, 2010, 11:35:26 PM Quote from: BioMike on August 27, 2010, 10:40:35 PM Quote from: satoshi on August 27, 2010, 09:54:12 PM

-march=amdfam10でビルドし、-4wayがわずかに高速化

-marchは古いシステムとのABI互換性を壊さないのか？

その可能性は十分ある。-mtune=XXXXの方が好ましいかもしれない。-march=XXXXはコンパイラがバイナリはamdfam10でのみ実行されると想定するからだ。

で、どのCPUがこれをサポートするのか？最新のAMDだけか？そしてこのためにどれだけのシステムを除外することになるのか？

tcatm 2010年8月28日原文 · 個別ページ

Quote from: BioMike on August 28, 2010, 08:24:05 AM

Quote from: tcatm on August 28, 2010, 12:33:35 AM Quote from: jgarzik on August 27, 2010, 11:35:26 PM

… -march=XXXXはコンパイラがバイナリをamdfam10でのみ実行されることを期待することを意味する。

まさにそれが望んでいることだ。しかし-march=amdfam10を使うのはダーティハックだということには同意する。この場合、ソースから最もコンパクトで効率的なSSE2コードが生成される。よりクリーンな代替手段はインラインアセンブラだろう。

で、どのCPUがこれをサポートするのか？最新のAMDだけか？そしてこのためにどれだけのシステムを除外することになるのか？

私の知る限り、Phenom、i5、i7だ。128ビットSSE2命令デコーダーを持つ唯一のCPUであり、全く恩恵を受けるのはこれらだけで、それ以前のCPUはすべて遅くなる。「AMDのK10でしか動かない」ではなく「コンパイラに必要な正確なアセンブリコードを生成させつつ、将来的に他のベクトルエンジンをサポートする柔軟性を維持する」と考えてほしい。

BioMike 2010年8月28日原文 · 個別ページ

Quote from: tcatm on August 28, 2010, 10:12:18 AM

Quote from: BioMike on August 28, 2010, 08:24:05 AM

Quote from: tcatm on August 28, 2010, 12:33:35 AM Quote from: jgarzik on August 27, 2010, 11:35:26 PM

… -march=XXXXはコンパイラがバイナリをamdfam10でのみ実行されることを期待することを意味する。

まさにそれが望んでいることだ。しかし-march=amdfam10を使うのはダーティハックだということには同意する。この場合、ソースから最もコンパクトで効率的なSSE2コードが生成される。よりクリーンな代替手段はインラインアセンブラだろう。

で、どのCPUがこれをサポートするのか？最新のAMDだけか？そしてこのためにどれだけのシステムを除外することになるのか？

私の知る限り、Phenom、i5、i7だ。128ビットSSE2命令デコーダーを持つ唯一のCPUであり、全く恩恵を受けるのはこれらだけで、それ以前のCPUはすべて遅くなる。「AMDのK10でしか動かない」ではなく「コンパイラに必要な正確なアセンブリコードを生成させつつ、将来的に他のベクトルエンジンをサポートする柔軟性を維持する」と考えてほしい。 Quote from: BioMike on August 28, 2010, 08:24:05 AM Quote from: tcatm on August 28, 2010, 12:33:35 AM Quote from: jgarzik on August 27, 2010, 11:35:26 PM

… -march=XXXXはコンパイラがバイナリをamdfam10でのみ実行されることを期待することを意味する。

まさにそれが望んでいることだ。しかし-march=amdfam10を使うのはダーティハックだということには同意する。この場合、ソースから最もコンパクトで効率的なSSE2コードが生成される。よりクリーンな代替手段はインラインアセンブラだろう。

で、どのCPUがこれをサポートするのか？最新のAMDだけか？そしてこのためにどれだけのシステムを除外することになるのか？

ああ。なるほど。情報をありがとう。

torservers 2010年8月28日原文 · 個別ページ

「バージョン情報」ダイアログはまだ0.3.10.1 betaと表示されている。

サトシ・ナカモト（Satoshi Nakamoto） 2010年8月28日原文 · 個別ページ

Quote from: torservers on August 28, 2010, 01:00:37 PM

「バージョン情報」ダイアログはまだ0.3.10.1 betaと表示されている。

どのOSだ？WindowsとLinux 64ビット版を実行してAboutダイアログを確認した。

Mac版はまだ0.3.10.1だ。

Quote from: pavelo on August 28, 2010, 07:36:07 AM

確か、gccの__attribute__を使って関数ごとに-marchを指定することが可能なはずだ。そうすれば、問題の関数だけが最適化され、ユーザーが-4wayを指定しなければ、他のすべてが問題ないはずだ。

最初の投稿をより具体的に更新した。-4wayコードだけがこの方法でコンパイルされる。