アラートシステムの開発
アラートシステムの作成に取り組んでいる。アラートはネットワークを通じてブロードキャストされ、バージョン番号の範囲に適用される。アラートメッセージは私だけが持つ秘密鍵で署名される。
ノードはアラートに対して2つのことを行える：
- ステータスバーに警告メッセージを表示する。
- json-rpcインターフェースの金銭処理メソッドがエラーを返すようにする。
オーバーフローバグやユーザーが受信した支払いを信頼できないフォークのような場合、アラートによって旧バージョンがアップグレードするまでほぼ安全に保たれるはずだ。手動のユーザーは受信した支払いを確認する際にステータスバーの警告に気付くはずであり、json-rpcのセーフモードはアップグレードされるまで自動化されたウェブサイトがこれ以上取引を行うのを停止する。
アラート中にエラーを返すjson-rpcメソッドは： sendtoaddress getbalance getreceivedbyaddress getreceivedbylabel listreceivedbyaddress listreceivedbylabel
@mizerydearia、引用ボタンの方が返信ボタンより見つけやすいと思うよ。
で、理論的にはこれは<ある政府>がサトシを逮捕して鍵の引き渡しを要求し（あるいは彼のコンピュータから取得し）、ネットワーク全体をシャットダウンできる最初の制御システムということか？
それとも不可能なのか？<ある政府>はどこまでできるのか？
だめだ！ そんなことをしたら、鍵を渡すまで拷問されるぞ、サトシ！
冗談はさておき、その鍵に停止する力があるなら、そのクライアントは動かさない。
1人がメッセージを送信できるというアイデア自体が好きではない。今はその人を信頼していても、後で信頼しなくなるかもしれないし、別の人になるかもしれないし、拷問/買収/脅迫されるかもしれない。
3.10にまだ切り替えていない人が多いのを見ての発想だろうか？
十分に多くの異なる実装があり、どれも過半数にならなければ、オーバーフローのようなバグは不適切にコーディングされたクライアントにのみ問題を引き起こし、チェーン全体には影響しない。新しいクライアントを書く人がほとんどあなたのコードをコピーすれば、問題はそのまま残る。しかしゼロから書かれていれば、問題は重複しない。
複数の実装があったら悪夢だと言っていなかったか？ なぜそう言ったか思い出せないが。
Quote from: FreeMoney on August 23, 2010, 05:23:13 AM
だめだ！ そんなことをしたら、鍵を渡すまで拷問されるぞ、サトシ！
冗談はさておき、その鍵に停止する力があるなら、そのクライアントは動かさない。
1人がメッセージを送信できるというアイデア自体が好きではない。今はその人を信頼していても、後で信頼しなくなるかもしれないし、別の人になるかもしれないし、拷問/買収/脅迫されるかもしれない。
3.10にまだ切り替えていない人が多いのを見ての発想だろうか？
十分に多くの異なる実装があり、どれも過半数にならなければ、オーバーフローのようなバグは不適切にコーディングされたクライアントにのみ問題を引き起こし、チェーン全体には影響しない。新しいクライアントを書く人がほとんどあなたのコードをコピーすれば、問題はそのまま残る。しかしゼロから書かれていれば、問題は重複しない。
複数の実装があったら悪夢だと言っていなかったか？ なぜそう言ったか思い出せないが。
オープンソースだ！ サトシを信頼しないか、強制されると思うなら、サトシの鍵を自分の鍵に置き換えれば、自分のノードをシャットダウンする権限は自分だけが持てる。
Quote from: lfm on August 23, 2010, 05:28:14 AM
Quote from: FreeMoney on August 23, 2010, 05:23:13 AM
1人がメッセージを送信できるというアイデア自体が好きではない。今はその人を信頼していても、後で信頼しなくなるかもしれないし、別の人になるかもしれないし、拷問/買収/脅迫されるかもしれない。
オープンソースだ！ サトシを信頼しないか、強制されると思うなら、サトシの鍵を自分の鍵に置き換えれば、自分のノードをシャットダウンする権限は自分だけが持てる。 Quote from: FreeMoney on August 23, 2010, 05:23:13 AM だめだ！ そんなことをしたら、鍵を渡すまで拷問されるぞ、サトシ！
冗談はさておき、その鍵に停止する力があるなら、そのクライアントは動かさない。
1人がメッセージを送信できるというアイデア自体が好きではない。今はその人を信頼していても、後で信頼しなくなるかもしれないし、別の人になるかもしれないし、拷問/買収/脅迫されるかもしれない。
3.10にまだ切り替えていない人が多いのを見ての発想だろうか？
十分に多くの異なる実装があり、どれも過半数にならなければ、オーバーフローのようなバグは不適切にコーディングされたクライアントにのみ問題を引き起こし、チェーン全体には影響しない。新しいクライアントを書く人がほとんどあなたのコードをコピーすれば、問題はそのまま残る。しかしゼロから書かれていれば、問題は重複しない。
複数の実装があったら悪夢だと言っていなかったか？ なぜそう言ったか思い出せないが。
全員が鍵を変更したり新しいバージョンにアップグレードしたりするのは大変な作業だ。0.3.0やおそらくそれ以前の古いバージョンをまだ使っている人がいることからも、それは認識されるべきだ。
Quote from: nimnul on August 23, 2010, 03:46:07 PM
- CentOS用パッケージ :-) アップデートが簡単になる
- メッセージ機能は実装しない
- RSS/メール/Jabberで通知してくれ
それは中央集権的すぎる/検閲されやすい/ハッキングされやすい。サトシだけが持つ特定の秘密鍵で署名されたメッセージのアイデアは理想的だ。任意のノードで導入でき、分散型の手段で広がる。
Quote from: mizerydearia on August 23, 2010, 08:50:04 AM
Quote from: lfm on August 23, 2010, 05:28:14 AM
Quote from: FreeMoney on August 23, 2010, 05:23:13 AM
1人がメッセージを送信できるというアイデア自体が好きではない。今はその人を信頼していても、後で信頼しなくなるかもしれないし、別の人になるかもしれないし、拷問/買収/脅迫されるかもしれない。
オープンソースだ！ サトシを信頼しないか、強制されると思うなら、サトシの鍵を自分の鍵に置き換えれば、自分のノードをシャットダウンする権限は自分だけが持てる。 Quote from: FreeMoney on August 23, 2010, 05:23:13 AM だめだ！ そんなことをしたら、鍵を渡すまで拷問されるぞ、サトシ！
冗談はさておき、その鍵に停止する力があるなら、そのクライアントは動かさない。
1人がメッセージを送信できるというアイデア自体が好きではない。今はその人を信頼していても、後で信頼しなくなるかもしれないし、別の人になるかもしれないし、拷問/買収/脅迫されるかもしれない。
3.10にまだ切り替えていない人が多いのを見ての発想だろうか？
十分に多くの異なる実装があり、どれも過半数にならなければ、オーバーフローのようなバグは不適切にコーディングされたクライアントにのみ問題を引き起こし、チェーン全体には影響しない。新しいクライアントを書く人がほとんどあなたのコードをコピーすれば、問題はそのまま残る。しかしゼロから書かれていれば、問題は重複しない。
複数の実装があったら悪夢だと言っていなかったか？ なぜそう言ったか思い出せないが。
全員が鍵を変更したり新しいバージョンにアップグレードしたりするのは大変な作業だ。0.3.0やおそらくそれ以前の古いバージョンをまだ使っている人がいることからも、それは認識されるべきだ。 Quote from: lfm on August 23, 2010, 05:28:14 AM Quote from: FreeMoney on August 23, 2010, 05:23:13 AM
1人がメッセージを送信できるというアイデア自体が好きではない。今はその人を信頼していても、後で信頼しなくなるかもしれないし、別の人になるかもしれないし、拷問/買収/脅迫されるかもしれない。
オープンソースだ！ サトシを信頼しないか、強制されると思うなら、サトシの鍵を自分の鍵に置き換えれば、自分のノードをシャットダウンする権限は自分だけが持てる。
設定ファイルかコマンドラインスイッチの単純なオプションであれば、大した労力はかからない。デフォルトでなくてもいい。オプトイン方式でもいい。緊急時に問題を起こさない保険として歓迎する人もいるだろう。
これについてヒステリックになるほど心配性なのであれば、ステータスバーに警告メッセージが表示されたらウェブサイトとフォーラムを確認するくらい心配性なはずだ。
オーバーフローバグのような別のバグが発生した場合、自動化されたウェブサイトが管理者が何が起きているか確認して対応を決定できるまで取引を停止することが重要だと思う。誤報だと判断してリスクを取りたい場合は、「-disablesafemode」スイッチを使える。
Quote from: satoshi on August 24, 2010, 11:51:12 PM
これについてヒステリックになるほど心配性なのであれば、ステータスバーに警告メッセージが表示されたらウェブサイトとフォーラムを確認するくらい心配性なはずだ。
オーバーフローバグのような別のバグが発生した場合、自動化されたウェブサイトが管理者が何が起きているか確認して対応を決定できるまで取引を停止することが重要だと思う。誤報だと判断してリスクを取りたい場合は、「-disablesafemode」スイッチを使える。
http://www.bitcoin.org/wiki/doku.php?id=man_page を見つけたが、-disablesafemodeへの言及がない。追加すべきではないか！また、-4wayなど他のオプションも追加すべきだ。
Quote from: satoshi on August 24, 2010, 11:51:12 PM
これについてヒステリックになるほど心配性なのであれば、ステータスバーに警告メッセージが表示されたらウェブサイトとフォーラムを確認するくらい心配性なはずだ。
オーバーフローバグのような別のバグが発生した場合、自動化されたウェブサイトが管理者が何が起きているか確認して対応を決定できるまで取引を停止することが重要だと思う。誤報だと判断してリスクを取りたい場合は、「-disablesafemode」スイッチを使える。
では、管理者はbitcoindからどのような警告を受けるのか？debug.logからgrepできるものがあるのか？それともRPC呼び出しが特定のエラーを返すのか？ユニットテストのためにローカルでこれを強制的に発生させる方法はあるのか？
Quote from: satoshi on August 24, 2010, 11:51:12 PM
これについてヒステリックになるほど心配性なのであれば、ステータスバーに警告メッセージが表示されたらウェブサイトとフォーラムを確認するくらい心配性なはずだ。
オーバーフローバグのような別のバグが発生した場合、自動化されたウェブサイトが管理者が何が起きているか確認して対応を決定できるまで取引を停止することが重要だと思う。誤報だと判断してリスクを取りたい場合は、「-disablesafemode」スイッチを使える。
分散型の匿名取引システムを作り、信頼に依存せず強力な暗号技術を使うサトシが、我々を心配性と呼んでいる（笑）
自分のPCで動いているソフトウェアへのリモート操作を望まないのは、心配性ではなく常識だと思う。もちろん良いアイデアではあるが、ユーザーが明示的に要求した場合にのみ有効にすべきだ。オプトアウトではなくオプトインにすべきだ。この2つには大きな違いがある（Facebookに聞いてみるとよい）。デフォルトで有効になっていると、多くの人がその存在に気づかないことを前提とした、悪用可能な・悪意ある機能として認識されるだろう。そして、そうした懸念は正当化されないとは言えない……あなたがコミュニティの最善の利益を心に持っていることは確かだが、このシステムはいかなる中央の信頼にも依存しないよう設計されたものであり、その原則を破るべきではない。
この機能を有効にするために、-disablesafemodeでユーザーに無効化を期待するのではなく、-enablesafetyを使うのはどうか？自分のソフトウェアがリモートアラートに応答するようにしたいなら、明示的に有効にすべきであり、そうすれば自分が何をしているか認識し、自分の意思で行っていることが保証される。デフォルトで有効になっていると、多くの人はこの「機能」が有効であることに気づかず、リモートによる無効化を信頼の裏切りと受け取るかもしれない……もしこの可能性を知らずにソフトウェアが突然動かなくなり、許可を与えていない誰かによってリモートで無効にされたことを発見したら、自分なら確実にそう感じる。
この提案を検討してもらえると嬉しい……ありがとう
Quote from: Macho on August 25, 2010, 03:03:03 AM
Quote from: satoshi on August 24, 2010, 11:51:12 PM
これについてヒステリックになるほど心配性なのであれば、ステータスバーに警告メッセージが表示されたらウェブサイトとフォーラムを確認するくらい心配性なはずだ。
オーバーフローバグのような別のバグが発生した場合、自動化されたウェブサイトが管理者が何が起きているか確認して対応を決定できるまで取引を停止することが重要だと思う。誤報だと判断してリスクを取りたい場合は、「-disablesafemode」スイッチを使える。
分散型の匿名取引システムを作り、信頼に依存せず強力な暗号技術を使うサトシが、我々を心配性と呼んでいる（笑）
自分のPCで動いているソフトウェアへのリモート操作を望まないのは、心配性ではなく常識だと思う。もちろん良いアイデアではあるが、ユーザーが明示的に要求した場合にのみ有効にすべきだ。オプトアウトではなくオプトインにすべきだ。この2つには大きな違いがある（Facebookに聞いてみるとよい）。デフォルトで有効になっていると、多くの人がその存在に気づかないことを前提とした、悪用可能な・悪意ある機能として認識されるだろう。そして、そうした懸念は正当化されないとは言えない……あなたがコミュニティの最善の利益を心に持っていることは確かだが、このシステムはいかなる中央の信頼にも依存しないよう設計されたものであり、その原則を破るべきではない。
この機能を有効にするために、-disablesafemodeでユーザーに無効化を期待するのではなく、-enablesafetyを使うのはどうか？自分のソフトウェアがリモートアラートに応答するようにしたいなら、明示的に有効にすべきであり、そうすれば自分が何をしているか認識し、自分の意思で行っていることが保証される。デフォルトで有効になっていると、多くの人はこの「機能」が有効であることに気づかず、リモートによる無効化を信頼の裏切りと受け取るかもしれない……もしこの可能性を知らずにソフトウェアが突然動かなくなり、許可を与えていない誰かによってリモートで無効にされたことを発見したら、自分なら確実にそう感じる。
この提案を検討してもらえると嬉しい……ありがとう
同意するが、ソースからコンパイルする場合、
rpc.cpp Code:!mapArgs.count(“-disablesafemode”) を Code:mapArgs.count(“-safemode”) に変更するだけで
Code:// Observe lockdown throw runtime_error(strWarning); となる。 コードはこちらで確認できる：http://bitcoin.svn.sourceforge.net/viewvc/bitcoin/trunk/rpc.cpp?revision=142&view=markup
-enablesafetyを使ったときだけエラーを表示するのは少し奇妙だ。これが起きると安全でない、あるいはセキュリティ上問題があるのだろうか？
http://www.bitcoin.org/wiki/doku.php?id=api
コードを理解した限りでは、getinfo、help、stop、getgenerate、setgenerate以外の http://www.bitcoin.org/wiki/doku.php?id=api のメソッドを使用する際、かつ警告がある場合：
-disablesafemodeが実行中のプロセスに渡されていれば、警告は表示されない -disablesafemodeが実行中のプロセスに渡されていなければ、警告が表示される
http://www.cplusplus.com/reference/std/stdexcept/runtime_error/
Quote from: mizerydearia on August 25, 2010, 09:14:31 AM
Quote from: Macho on August 25, 2010, 03:03:03 AM
Quote from: satoshi on August 24, 2010, 11:51:12 PM
これについてヒステリックになるほど心配性なのであれば、ステータスバーに警告メッセージが表示されたらウェブサイトとフォーラムを確認するくらい心配性なはずだ。
オーバーフローバグのような別のバグが発生した場合、自動化されたウェブサイトが管理者が何が起きているか確認して対応を決定できるまで取引を停止することが重要だと思う。誤報だと判断してリスクを取りたい場合は、「-disablesafemode」スイッチを使える。
分散型の匿名取引システムを作り、信頼に依存せず強力な暗号技術を使うサトシが、我々を心配性と呼んでいる（笑）
自分のPCで動いているソフトウェアへのリモート操作を望まないのは、心配性ではなく常識だと思う。もちろん良いアイデアではあるが、ユーザーが明示的に要求した場合にのみ有効にすべきだ。オプトアウトではなくオプトインにすべきだ。この2つには大きな違いがある（Facebookに聞いてみるとよい）。デフォルトで有効になっていると、多くの人がその存在に気づかないことを前提とした、悪用可能な・悪意ある機能として認識されるだろう。そして、そうした懸念は正当化されないとは言えない……あなたがコミュニティの最善の利益を心に持っていることは確かだが、このシステムはいかなる中央の信頼にも依存しないよう設計されたものであり、その原則を破るべきではない。
この機能を有効にするために、-disablesafemodeでユーザーに無効化を期待するのではなく、-enablesafetyを使うのはどうか？自分のソフトウェアがリモートアラートに応答するようにしたいなら、明示的に有効にすべきであり、そうすれば自分が何をしているか認識し、自分の意思で行っていることが保証される。デフォルトで有効になっていると、多くの人はこの「機能」が有効であることに気づかず、リモートによる無効化を信頼の裏切りと受け取るかもしれない……もしこの可能性を知らずにソフトウェアが突然動かなくなり、許可を与えていない誰かによってリモートで無効にされたことを発見したら、自分なら確実にそう感じる。
この提案を検討してもらえると嬉しい……ありがとう
同意するが、ソースからコンパイルする場合、
rpc.cpp Code:!mapArgs.count(“-disablesafemode”) を Code:mapArgs.count(“-safemode”) に変更するだけで
Code:// Observe lockdown throw runtime_error(strWarning); となる。 コードはこちらで確認できる：http://bitcoin.svn.sourceforge.net/viewvc/bitcoin/trunk/rpc.cpp?revision=142&view=markup
-enablesafetyを使ったときだけエラーを表示するのは少し奇妙だ。これが起きると安全でない、あるいはセキュリティ上問題があるのだろうか？
http://www.bitcoin.org/wiki/doku.php?id=api
コードを理解した限りでは、getinfo、help、stop、getgenerate、setgenerate以外の http://www.bitcoin.org/wiki/doku.php?id=api のメソッドを使用する際、かつ警告がある場合：
-disablesafemodeが実行中のプロセスに渡されていれば、警告は表示されない -disablesafemodeが実行中のプロセスに渡されていなければ、警告が表示される
http://www.cplusplus.com/reference/std/stdexcept/runtime_error/
それはポイントではない。ソースコードを変更するほど勤勉なら、-disablesafetyスイッチを適用するほど勤勉でもあるだろう。はるかに簡単だ。ここでの問題は公式クライアントのデフォルト動作だ。多くの人はただ新しいバージョンがあることに気づき、ダウンロードしてインストールするだけで、この新しいリモートコントロールが挿入されたことに気づかない。
ソースコードを調べたりフォーラムで公然と議論されたと言うのは、Facebookが「でもアカウント削除オプションがあります。利用規約のセクション76、346行目、so-appalling-that-nobody-would-ever-click-itという名前のリンクの下にあります。ページ2でキャプチャを解いて、ダイアログを確認してください。それでアカウントが無効になり、1週間ログインしなければ削除されます」と言うようなものだ。要するに…実際には誰もやらない…それがバッドウェアの振る舞いであり、Bitcoinにバッドウェアになってほしくない。
リモートセーフティ無効化機能がある場合、それを有効にしているすべてのユーザーは、それが何をするか知った上で意識的に有効にすべきだ。GUIクライアントでは有効化を促すダイアログを表示し、何をするか説明すればいい。デーモンの場合は同じ目的を果たす警告を表示すればいい。シンプルで効率的で全員が満足する。ユーザーを尊重し、ユーザーのために働くソフトウェアはそうあるべきだ。ほとんどの人は何をするか理解すれば有効にするだろう…しかしユーザーが望んでいることを確認せずにこの機能をこっそり入れるのは、ユーザーのために決定を下すことであり、私は自分のために決定を下されるのが好きではない Wink
これについて知っているのはフォーラムを読んでいるからだが、将来はどうか？（そしてフォーラムを読まない人はどうか）別の「機能」が挿入されて、通知もされず、何をするか説明もされず、望むかどうか聞かれないのか？それは好きではない…自分のCPU上のソフトウェアが何をしているか知りたいし、合理的な努力で情報を提供し、動作を認識していることを保証してくれなければ、バッドウェアと見なす。
少なくともそれが私の視点だ…そして修正は極めて簡単だ Wink
リモートで任意のアクションを実行することはできない。アラートシステムにもっと多くのことをさせるべきだと提案した他の投稿者に反応しているのかもしれないな？
アラートがある場合、以下のjson-rpcメソッドがエラーを返す： sendtoaddress getbalance getreceivedbyaddress getreceivedbylabel listreceivedbyaddress listreceivedbylabel
残りの14メソッドは通常通り機能する。
より安全なオプションがデフォルトで有効であるべきだと考えている。サーバーが取引を続け、受信しているお金がオーバーフローバグのお金のようなものかもしれないというアラートを無視したい場合は、スイッチを使えるが、お金を失っても他人を責めないでほしい。
アラートを有効にしたままの最悪のケースでは、アップグレードするか-disablesafeモードスイッチを追加するまでサイトが取引を停止する。
ノードが本来リスクにさらされるはずの時に一時的なダウンタイムで驚かされる方が、泥棒に在庫をすべて奪われて驚かされるよりましだ。
いつか、長期間新しいバグが見つからず、何も見つからないまま徹底的なセキュリティレビューが行われた時には、これを縮小できる。これが永遠の恒久的な方法だと主張しているわけではない。まだベータソフトウェアだ。
RPCコールが返すエラーは何か？そしてもっと重要なのは、これをどうシミュレートできるか？サーバーを劣化モードで起動するフラグを追加できないか？
Quote from: BioMike on August 23, 2010, 05:15:43 AM
@mizerydearia、引用ボタンの方が返信ボタンより見つけやすいと思うよ。
で、理論的にはこれは<ある政府>がサトシを逮捕して鍵の引き渡しを要求し（あるいは彼のコンピュータから取得し）、ネットワーク全体をシャットダウンできる最初の制御システムということか？
それとも不可能なのか？<ある政府>はどこまでできるのか？
サトシへのいくつかの修辞的な質問：
ウォーターボーディングに耐えられるか？ 電気ショックに耐えられるか？ あらゆる形態の拷問に？ 最後に、ひょっとしてジャック・バウアーか？ 真面目に。
Quote from: jimbobway on August 25, 2010, 04:45:22 PM
Quote from: BioMike on August 23, 2010, 05:15:43 AM
@mizerydearia、引用ボタンの方が返信ボタンより見つけやすいと思うよ。
で、理論的にはこれは<ある政府>がサトシを逮捕して鍵の引き渡しを要求し（あるいは彼のコンピュータから取得し）、ネットワーク全体をシャットダウンできる最初の制御システムということか？
それとも不可能なのか？<ある政府>はどこまでできるのか？
サトシへのいくつかの修辞的な質問：
ウォーターボーディングに耐えられるか？ 電気ショックに耐えられるか？ あらゆる形態の拷問に？ 最後に、ひょっとしてジャック・バウアーか？ 真面目に。 Quote from: BioMike on August 23, 2010, 05:15:43 AM @mizerydearia、引用ボタンの方が返信ボタンより見つけやすいと思うよ。
で、理論的にはこれは<ある政府>がサトシを逮捕して鍵の引き渡しを要求し（あるいは彼のコンピュータから取得し）、ネットワーク全体をシャットダウンできる最初の制御システムということか？
それとも不可能なのか？<ある政府>はどこまでできるのか？
では、理論的にこれは<ある政府>がSatoshiを逮捕して鍵を引き渡すよう（またはコンピュータから取得して）要求し、ネットワーク全体をシャットダウンできる最初の制御システムですか？
それとも不可能ですか？<ある政府>はどこまでできるでしょうか？
Satoshiへのいくつかの修辞的な質問：
ウォーターボーディングに耐えられますか？ 電気ショックに耐えられますか？ すべての形態の拷問に？ 最後に、あなたはもしかしてJack Bauerですか？本気で。 アラートシステムに関して、誰が気にするのか？鍵ができることは、サイト所有者が-disablesafemodeスイッチを追加するかアップグレードするまで、6つのjson-rpcコマンドを一時的に無効にすることだけだ。すべてのノードは稼働し続け生成を続け、ネットワークは維持される。私が不在でも、スクリプトキディでも2文字追加してアラートシステムを無効にする新バージョンを作る方法を理解できる。一時的な不便でしかない。
Quote from: BioMike on August 23, 2010, 05:15:43 AM
@mizerydearia、引用ボタンの方が返信ボタンより見つけやすいと思うよ。
で、理論的にはこれは<ある政府>がサトシを逮捕して鍵の引き渡しを要求し（あるいは彼のコンピュータから取得し）、ネットワーク全体をシャットダウンできる最初の制御システムということか？
それとも不可能なのか？<ある政府>はどこまでできるのか？
これが、反対している人々が何を言っているかわかっていないと思わせる理由だ。「ネットワーク全体をシャットダウン」することはできない。
Quote from: nelisky on August 25, 2010, 01:28:32 AM
Quote from: satoshi on August 24, 2010, 11:51:12 PM
これについてヒステリックになるほど心配性なのであれば、ステータスバーに警告メッセージが表示されたらウェブサイトとフォーラムを確認するくらい心配性なはずだ。
オーバーフローバグのような別のバグが発生した場合、自動化されたウェブサイトが管理者が何が起きているか確認して対応を決定できるまで取引を停止することが重要だと思う。誤報だと判断してリスクを取りたい場合は、「-disablesafemode」スイッチを使える。
では、管理者はbitcoindからどのような警告を受けるのか？debug.logからgrepできるものがあるのか？それともRPC呼び出しが特定のエラーを返すのか？ユニットテストのためにローカルでこれを強制的に発生させる方法はあるのか？
getinfoには、ステータスバーに表示されるアラートメッセージやその他のエラーを表示する新しいフィールドがある。
RPCメソッドは、エラー説明「Safe mode: 」に続いてアラートで指定された追加テキストを含むjson-rpcエラーを返す。
あなたのために「-testsafemode」スイッチを追加した。SVN rev 145だ。
これらは非常に新しいもので、まだ変更される可能性がある。
Quote from: mizerydearia on August 25, 2010, 12:11:50 AM
Quote from: satoshi on August 24, 2010, 11:51:12 PM
誤報だと判断してリスクを取りたい場合は、「-disablesafemode」スイッチを使えばよい。
http://www.bitcoin.org/wiki/doku.php?id=man_page を見つけたが、-disablesafemodeへの言及がない。追加すべきではないか！また、-4wayなど他のオプションも追加すべきだ。
多くのスイッチは意図的にドキュメント化されていない。機能がまだ開発中だったり、名前がまだ確定していなかったり、リリース向けでないテストコードだったりする場合だ。
-4wayは最終的に自動検出に置き換えられるべきだ。
Quote from: satoshi on August 25, 2010, 04:56:15 PM
Quote from: jimbobway on August 25, 2010, 04:45:22 PM Quote from: BioMike on August 23, 2010, 05:15:43 AM
@mizerydearia、引用ボタンの方が返信ボタンより見つけやすいと思う。
では、理論的にこれは<ある政府>がSatoshiを逮捕して鍵を引き渡すよう（またはコンピュータから取得して）要求し、ネットワーク全体をシャットダウンできる最初の制御システムですか？
それとも不可能ですか？<ある政府>はどこまでできるでしょうか？
Satoshiへのいくつかの修辞的な質問：
ウォーターボーディングに耐えられますか？ 電気ショックに耐えられますか？ すべての形態の拷問に？ 最後に、あなたはもしかしてJack Bauerですか？本気で。 アラートシステムに関して、誰が気にするのか？鍵ができることは、サイト所有者が-disablesafemodeスイッチを追加するかアップグレードするまで、6つのjson-rpcコマンドを一時的に無効にすることだけだ。すべてのノードは稼働し続け生成を続け、ネットワークは維持される。私が不在でも、スクリプトキディでも2文字追加してアラートシステムを無効にする新バージョンを作る方法を理解できる。一時的な不便でしかない。
Quote from: BioMike on August 23, 2010, 05:15:43 AM
つまり、理論上はこれは最初の制御システムで、<ある政府>がサトシ・ナカモトを逮捕して鍵を渡すよう要求し（あるいは彼のコンピュータから取得し）、ネットワーク全体をシャットダウンできるということか？ それとも不可能なのか？<ある政府>はどこまでできる？
これが、反対している人々が何を言っているかわかっていないと思わせる理由だ。「ネットワーク全体をシャットダウン」することはできない。 Quote from: BioMike on August 23, 2010, 05:15:43 AM @mizerydearia、引用ボタンの方が返信ボタンより見つけやすいと思うよ。
で、理論的にはこれは<ある政府>がサトシを逮捕して鍵の引き渡しを要求し（あるいは彼のコンピュータから取得し）、ネットワーク全体をシャットダウンできる最初の制御システムということか？
それとも不可能なのか？<ある政府>はどこまでできるのか？
この変更/アイデアに反対したことは一度もない。可能かどうか、どの程度まで可能かを聞いているだけだ。 情報を得ることの何が悪いのか？ Wink
Quote from: satoshi on August 25, 2010, 05:59:30 PM
Quote from: nelisky on August 25, 2010, 01:28:32 AM
では、管理者はbitcoindからどのような警告を受け取りますか？debug.logからgrepできるものはありますか？それともRPC呼び出しが特定のエラーを発生させますか？ユニットテストサービスのために、ローカルでこれを強制的に発生させる方法はありますか？
getinfoには、ステータスバーに表示されるアラートメッセージやその他のエラーを表示する新しいフィールドがある。
RPCメソッドは、エラー説明「Safe mode: 」に続いてアラートで指定された追加テキストを含むjson-rpcエラーを返す。
あなたのために「-testsafemode」スイッチを追加した。SVN rev 145だ。
これらは非常に新しいもので、まだ変更される可能性がある。
Quote from: mizerydearia on August 25, 2010, 12:11:50 AM
http://www.bitcoin.org/wiki/doku.php?id=man_pageを見つけましたが、-disablesafemodeへの参照がありません。追加すべきでしょう！また、-4wayなど他のものも追加すべきです。
多くのスイッチは意図的にドキュメント化されていない。機能がまだ開発中だったり、名前がまだ確定していなかったり、リリース向けでないテストコードだったりする場合だ。
-4wayは最終的に自動検出に置き換えられるべきだ。 Quote from: nelisky on August 25, 2010, 01:28:32 AM Quote from: satoshi on August 24, 2010, 11:51:12 PM
これについてヒステリックになるほど心配性なのであれば、ステータスバーに警告メッセージが表示されたらウェブサイトとフォーラムを確認するくらい心配性なはずだ。
オーバーフローバグのような別のバグが発生した場合、自動化されたウェブサイトが管理者が何が起きているか確認して対応を決定できるまで取引を停止することが重要だと思う。誤報だと判断してリスクを取りたい場合は、「-disablesafemode」スイッチを使える。
では、管理者はbitcoindからどのような警告を受けるのか？debug.logからgrepできるものがあるのか？それともRPC呼び出しが特定のエラーを返すのか？ユニットテストのためにローカルでこれを強制的に発生させる方法はあるのか？
完璧だ、問題なく動作する。ありがとう。
Quote from: BioMike on August 25, 2010, 06:23:45 PM
Quote from: satoshi on August 25, 2010, 04:56:15 PM Quote from: BioMike on August 23, 2010, 05:15:43 AM
で、理論的にはこれは<ある政府>がサトシを逮捕して鍵の引き渡しを要求し（あるいは彼のコンピュータから取得し）、ネットワーク全体をシャットダウンできる最初の制御システムということか？
これを見ると、反対している人たちは何を言っているか分かっていないと思える。「ネットワーク全体をシャットダウン」することはできない。
この変更/アイデアに反対したことは一度もない。可能かどうか、どの程度まで可能かを聞いているだけだ。 情報を得ることの何が悪いのか？ Wink Quote from: satoshi on August 25, 2010, 04:56:15 PM Quote from: jimbobway on August 25, 2010, 04:45:22 PM Quote from: BioMike on August 23, 2010, 05:15:43 AM
@mizerydearia、引用ボタンの方が返信ボタンより見つけやすいと思う。
では、理論的にこれは<ある政府>がSatoshiを逮捕して鍵を引き渡すよう（またはコンピュータから取得して）要求し、ネットワーク全体をシャットダウンできる最初の制御システムですか？
それとも不可能ですか？<ある政府>はどこまでできるでしょうか？
Satoshiへのいくつかの修辞的な質問：
ウォーターボーディングに耐えられますか？ 電気ショックに耐えられますか？ すべての形態の拷問に？ 最後に、あなたはもしかしてJack Bauerですか？本気で。 アラートシステムに関して、誰が気にするのか？鍵ができることは、サイト所有者が-disablesafemodeスイッチを追加するかアップグレードするまで、6つのjson-rpcコマンドを一時的に無効にすることだけだ。すべてのノードは稼働し続け生成を続け、ネットワークは維持される。私が不在でも、スクリプトキディでも2文字追加してアラートシステムを無効にする新バージョンを作る方法を理解できる。一時的な不便でしかない。
Quote from: BioMike on August 23, 2010, 05:15:43 AM
つまり、理論上はこれは最初の制御システムで、<ある政府>がサトシ・ナカモトを逮捕して鍵を渡すよう要求し（あるいは彼のコンピュータから取得し）、ネットワーク全体をシャットダウンできるということか？ それとも不可能なのか？<ある政府>はどこまでできる？
これが、反対している人々が何を言っているかわかっていないと思わせる理由だ。「ネットワーク全体をシャットダウン」することはできない。
申し訳ない、あなたの投稿は確かに声明ではなく質問だった。