(context post by Gavin Andresen)

BitcoinのP2Pネットワークはさまざまなサービス拒否攻撃を受ける可能性がある。

はい、言った。

修正方法について建設的な提案があるのか、それともできるからという理由で壊すのを楽しむタイプの人間なのか？

頭の中で浮かんでいるアイデアで、うまくいくかもしれないしうまくいかないかもしれないもの：

• クライアント同士が、単位時間あたりいくつのトランザクションを受け入れるかを相互に伝える。クライアントがそれ以上送ってきたら（多少の誤差範囲内で）、切断する。一般的なユーザーの推定トランザクション数と現在のユーザー数の推定に基づいたデフォルト値をコンパイル時に設定する。

• クライアント間の接続プロセスの一部としてある程度のプルーフ・オブ・ワークを要求する（「シビル」攻撃の防止に役立つ）。

これは活発な研究分野だ。例えば次を参照：http://scholar.google.com/scholar?q=ddos+attacks+by+subverting+membership

[Deleted] Quote from: davidonpda on August 11, 2010, 04:19:43 PM Quote from: gavinandresen on August 11, 2010, 04:10:56 PM

• クライアント間の接続プロセスの一部としてある程度のプルーフ・オブ・ワークを要求する（「シビル」攻撃の防止に役立つ）。

これは素晴らしいアイデアではないか？Hashcashのような？

トランザクションの文字列をハッシュし、プルーフ・オブ・ワーク付きでなければならないようにする。例えば、最新のPCで計算に5秒かかるようにする。POWのチェックはBitcoinと同様に簡単で非常に速いが、攻撃者が無限のCPUパワーを持っていない限り、プルーフ・オブ・ワークなしのランダムデータによるフラッド攻撃を阻止できる。

実は初回接続時に1分から3分のプルーフ・オブ・ワークを考えていたのであって、トランザクション送信時ではないが、ネットワークに送信されるすべてのトランザクションに何らかのプルーフ・オブ・ワークを要求するのは非常に興味深いアイデアだ！実装も簡単なはずだ（トランザクションにnonceと完全または部分的なハッシュを追加する）…

Quote from: gavinandresen on August 11, 2010, 04:40:07 PM [Deleted] Quote from: davidonpda on August 11, 2010, 04:19:43 PM

Quote from: gavinandresen on August 11, 2010, 04:10:56 PM

• クライアント間の接続プロセスの一部としてある程度のプルーフ・オブ・ワークを要求する（「シビル」攻撃の防止に役立つ）。

これは素晴らしいアイデアではないか？Hashcashのような？

トランザクションの文字列をハッシュし、プルーフ・オブ・ワーク付きでなければならないようにする。例えば、最新のPCで計算に5秒かかるようにする。POWのチェックはBitcoinと同様に簡単で非常に速いが、攻撃者が無限のCPUパワーを持っていない限り、プルーフ・オブ・ワークなしのランダムデータによるフラッド攻撃を阻止できる。

実は初回接続時に1分から3分のプルーフ・オブ・ワークを考えていたのであって、トランザクション送信時ではないが、ネットワークに送信されるすべてのトランザクションに何らかのプルーフ・オブ・ワークを要求するのは非常に興味深いアイデアだ！実装も簡単なはずだ（トランザクションにnonceと完全または部分的なハッシュを追加する）…

残念ながら、実装は簡単だが、効果的であるためには互換性を壊す変更にならざるを得ない。

古いクライアントは知らないのでプルーフ・オブ・ワークを送信しない。だから攻撃者は自分のクライアントバージョンを308と偽れる — この保護機能を知らないほど古いバージョンだと。そうするとノードは、古いクライアントのサポートを打ち切ってこの種の攻撃に対して安全になるか、古いクライアントのサポートを続けてこの攻撃に対して脆弱なままでいるかを選ばなければならない。

やるべきでないとは言わないが、互換性を壊す変更を行う前に、重要な互換性を壊す変更のリストをまとめるべきだと思う。ユーザーは毎日のようにアップグレードを求められるのを嫌う。

また、メッセージリレープロトコルがどう動作するか分からない。各ノードが最初のノードが提供したのと同じnonceとハッシュでそのTxをリレーすればいいだろう。重複トランザクションは本質的に無効なのでハッシュの「再利用」の危険はない（ただしノードに嫌がらせはできる）。

検出とブラックリスト機能のコードも有用だろう。あるIPが一定時間内に一定数の無効なトランザクションを送信してきたら、切断してそのIPからの接続を一定期間拒否する。再接続後にまたやったら、より長期間ブロックする…といった具合に。

Quote from: gavinandresen on August 11, 2010, 04:10:56 PM

• クライアント同士が、単位時間あたりいくつのトランザクションを受け入れるかを相互に伝える。クライアントがそれ以上送ってきたら（多少の誤差範囲内で）、切断する。一般的なユーザーの推定トランザクション数と現在のユーザー数の推定に基づいたデフォルト値をコンパイル時に設定する。

• クライアント間の接続プロセスの一部としてある程度のプルーフ・オブ・ワークを要求する（「シビル」攻撃の防止に役立つ）。

最終的には後者を実施しなければならないだろうということに同意する。あなたが指摘した理由が、私のDHTソリューションに欠陥がある原因だ。興味深いことに、これはすべて前者の制約を実装できないことの副作用だ。

検証ノードが任意にトランザクションを無視することを許可すると、すべての検証ノードがすべてのトランザクションを受信し記録するという重要な要件を破る危険がある。現在の前提は、すべての検証者がすべてのトランザクションを受信し記録しようとすることだ。トランザクションが不均一に遅延し、ブロックを完成させたノードに見逃された場合、統計的にそのトランザクションは後続のブロックに記録されると推定される。ただし、それにはトランザクションを継続的に再ブロードキャストして通過を確実にする必要がある。

仮にthroughputが正しく、ノードが「10ブロック期間に5トランザクションしか受け付けない」と言うことにメリットがあるとしよう。その場合でも他のノードから拒否できないブロックを生成するが、最小限のブロックごとに未記録トランザクションのバックログが増加する。これにより追加の再送信が発生し、帯域幅の問題を悪化させる。

実質的に、制限されたノードが引き起こした問題を補償するために、制限のないノードに頼ることになる。制限されたノードが問題を引き起こし、他のノードより少ない検証と記録作業しかしていないなら、なぜブロック生成に対して同等に報酬を受けるべきなのか？それは非生産的だ。

むしろ「すべてのトランザクションを記録するか、検証者になれない！」と言う方がいい。検証者が減れば全体の帯域幅使用量が減る。不正者の発見も容易になる。

----追伸----

ゼロ知識による完全性の証明とは、競合する検証者が、既知の未処理トランザクションの99%を含まないプルーフ・オブ・ワークブロックを拒否することだ。

そこまで破壊的な変更にする必要はない。新しいノードは、PoWなしのトランザクションの受け入れを拒否し始める前に、ほとんどのノードがすでにアップグレードされるまで長い間古いトランザクションを受け入れることができる。あるいは、常に古いトランザクションを受け入れるが、期間あたりの数を制限することもできる。

トランザクションへのPoWについて何度も考えたが、通常は0.01のトランザクション手数料が本質的に同様でより良いという結論に至る。0.01は基本的にProof-of-workだが、無駄にならない。ただし、問題が大量のトランザクションの検証である場合、PoWの方が高速にチェックできるだろう。

より一般的な包括的な部分解決策は、受信ブロック数の異常な減少を検出するアイデアを実装することだ。そうすれば、攻撃者がDoS攻撃から利益を得るにはネットワークパワーのかなりの部分が必要になる。

Quote from: gavinandresen on August 11, 2010, 04:10:56 PM

BitcoinのP2Pネットワークはさまざまな種類のサービス拒否攻撃を受ける可能性がある。

はい、そう言った。 +1

この時点でのデモンストレーションテストは、すでにわかっていることを示すだけで、システムの強化から運用上の火消しに開発時間を転用させるだけだろう。