Bitcoin の潜在的な弱点に関する専用の議論はどこか
「もし……だったら？」と質問でき、すべてのアイデアを一箇所に集められる場が欲しい。
例えば。
生成ノードはすべてのトランザクションを受信する必要はないように思える。 必要なデータは前のブロックハッシュだけだ。 そうだろう？
次に。 ほぼすべての公開アクセス可能なノードに接続できるだろう？ そのアドレスを収集し、ほぼすべてのノードへの接続を確立できる。 そして望むだけのデータを送りつけることができる。 例えば、膨大な量の偽の（あるいはそうでない）トランザクション。 大量の（おそらく無効な）トランザクション（あるいは別のゴミデータ）を受信・検証させることで、 ノードの生成能力を絞ることは可能ではないか？
もしそれが可能なら、難易度を下げることができるのではないか？ 長期間これを行えば良い。 自分のスーパーコンピューター（ボットネット）にとって許容可能な値まで下がったら、 ネットワークに接続する。ただし直接ではなく、 特殊なノードを経由して接続する。そのノードはまだフラッディングしているゴミデータをフィルターリングする特殊な方法でメッセージを転送する。 これにより、スーパーコンピューターはブロックを受信して生成に参加できるが、他のノードはフラッディングされたままで 生成 BTC のわずかな部分しか得られない。
次に、生成 BTC に興味がない場合、ブロックチェーンフォークの生成を開始できる。 難易度が下がった直後に、隔離された環境でブロックチェーンの代替バージョンを生成し始める。 難易度はすぐには変わらないので、残りのネットワークがゴミデータを処理している間に ネットワークを上回ろうとできる。十分速く最長チェーンを全員に提示するが、その後難易度が上がる。 これにより、ブロックチェーンフォーク後に行った以前の支払いトランザクションを消去できる。 つまり、それらを回復して未使用のトランザクションを取り戻せるのではないか？そして再度使えるのか？ 以前のトランザクションがそのように「再支払い」された場合、新しいブロックチェーンにどう組み込まれるのか？
そしてこれは繰り返せる。 間違っているなら、「間違っている」と言ってほしい。 しかし、なぜかヒントもくれると助かる。
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
ギャビン・アンドレセンの投稿（2010年8月11日 07:10 UTC）
- クライアント間の接続プロセスの一部として何らかのプルーフ・オブ・ワークを要求する（「シビル」攻撃の防止に役立つ）。
それは素晴らしいアイデアではないか？hashcashのような？
トランザクションの文字列をハッシュすることが要求される。プルーフ・オブ・ワーク付きで、例えば現代のPCで計算に5秒かかるような。bitcoinと同様にPOWのチェックは受信側マシンにとって簡単で非常に高速だが、攻撃者が無限のCPUパワーを持たない限りランダムデータによるフラッド攻撃を阻止できる。
実は初回接続時に 1分から 3分のプルーフ・オブ・ワークを考えていたのであって、トランザクション送信時ではないが、ネットワークに送信されるすべてのトランザクションに何らかのプルーフ・オブ・ワークを要求するのは非常に興味深いアイデアだ！実装も簡単なはずだ（トランザクションにナンスと完全または部分的なハッシュを追加する）…
[Deleted] Quote from: davidonpda on August 11, 2010, 04:19:43 PM
ギャビン・アンドレセンの投稿（2010年8月11日 16:10 UTC）
- クライアント間の接続プロセスの一部として何らかのプルーフ・オブ・ワークを要求する（「シビル」攻撃の防止に役立つ）。
それは素晴らしいアイデアではないか？hashcashのような？
トランザクションの文字列をハッシュすることが要求される。プルーフ・オブ・ワーク付きで、例えば現代のPCで計算に5秒かかるような。bitcoinと同様にPOWのチェックは受信側マシンにとって簡単で非常に高速だが、攻撃者が無限のCPUパワーを持たない限りランダムデータによるフラッド攻撃を阻止できる。
実は初回接続時に1分から3分のプルーフ・オブ・ワークを考えていたのであって、トランザクション送信時ではないが、ネットワークに送信されるすべてのトランザクションに何らかのプルーフ・オブ・ワークを要求するのは非常に興味深いアイデアだ！実装も簡単なはずだ（トランザクションにナンスと完全または部分的なハッシュを追加する）…
残念ながら、実装は簡単だが、効果的であるためには互換性を壊す変更にならざるを得ない。
古いクライアントは知らないのでプルーフ・オブ・ワークを送信しない。だから攻撃者は自分のクライアントバージョンを 308 と偽れる — この保護機能を知らないほど古いバージョンだと。そうするとノードは、古いクライアントのサポートを打ち切ってこの種の攻撃に対して安全になるか、古いクライアントのサポートを続けてこの攻撃に対して脆弱なままでいるかを選ばなければならない。
やるべきでないとは言わないが、互換性を壊す変更を行う前に、重要な互換性を壊す変更のリストをまとめるべきだと思う。ユーザーは毎日のようにアップグレードを求められるのを嫌う。
また、メッセージリレープロトコルがどう動作するか分からない。各ノードが最初のノードが提供したのと同じナンスとハッシュでその Tx をリレーすればいいだろう。重複トランザクションは本質的に無効なのでハッシュの「再利用」の危険はない（ただしノードに嫌がらせはできる）。
検出とブラックリスト機能のコードも有用だろう。ある IP が一定時間内に一定数の無効なトランザクションを送信してきたら、切断してその IP からの接続を一定期間拒否する。再接続後にまたやったら、より長期間ブロックする…といった具合に。
クライアント同士が、単位時間あたりいくつのトランザクションを受け入れるかを相互に伝える。クライアントがそれ以上送ってきたら（多少の誤差範囲内で）、切断する。一般的なユーザーの推定トランザクション数と現在のユーザー数の推定に基づいたデフォルト値をコンパイル時に設定する。
クライアント間の接続プロセスの一部としてある程度のプルーフ・オブ・ワークを要求する（「シビル」攻撃の防止に役立つ）。
最終的には後者を実施しなければならないだろうということに同意する。あなたが指摘した理由が、私の DHT ソリューションに欠陥がある原因だ。興味深いことに、これはすべて前者の制約を実装できないことの副作用だ。
検証ノードが任意にトランザクションを無視することを許可すると、すべての検証ノードがすべてのトランザクションを受信し記録するという重要な要件を破る危険がある。現在の前提は、すべての検証者がすべてのトランザクションを受信し記録しようとすることだ。トランザクションが不均一に遅延し、ブロックを完成させたノードに見逃された場合、統計的にそのトランザクションは後続のブロックに記録されると推定される。ただし、それにはトランザクションを継続的に再ブロードキャストして通過を確実にする必要がある。
仮に throughput が正しく、ノードが「10 ブロック期間に 5 トランザクションしか受け付けない」と言うことにメリットがあるとしよう。その場合でも他のノードから拒否できないブロックを生成するが、最小限のブロックごとに未記録トランザクションのバックログが増加する。これにより追加の再送信が発生し、帯域幅の問題を悪化させる。
実質的に、制限されたノードが引き起こした問題を補償するために、制限のないノードに頼ることになる。制限されたノードが問題を引き起こし、他のノードより少ない検証と記録作業しかしていないなら、なぜブロック生成に対して同等に報酬を受けるべきなのか？それは非生産的だ。
むしろ「すべてのトランザクションを記録するか、検証者になれない！」と言う方がいい。検証者が減れば全体の帯域幅使用量が減る。不正者の発見も容易になる。
----追伸----
ゼロ知識による完全性の証明とは、競合する検証者が、既知の未処理トランザクションの 99%を含まないプルーフ・オブ・ワークブロックを拒否することだ。
そこまで破壊的な変更にする必要はない。新しいノードは、PoW なしのトランザクションの受け入れを拒否し始める前に、ほとんどのノードがすでにアップグレードされるまで長い間古いトランザクションを受け入れることができる。あるいは、常に古いトランザクションを受け入れるが、期間あたりの数を制限することもできる。
トランザクションへの PoW について何度も考えたが、通常は 0.01 のトランザクション手数料が本質的に同様でより良いという結論に至る。0.01 は基本的に Proof-of-work だが、無駄にならない。ただし、問題が大量のトランザクションの検証である場合、PoW の方が高速にチェックできるだろう。
より一般的な包括的な部分解決策は、受信ブロック数の異常な減少を検出するアイデアを実装することだ。そうすれば、攻撃者が DoS 攻撃から利益を得るにはネットワークパワーのかなりの部分が必要になる。
ギャビン・アンドレセンの投稿（2010年8月11日 07:10 UTC）Bitcoin の P2P ネットワークはさまざまなサービス拒否攻撃を受ける可能性がある。
はい、そう言った。 +1
この時点でのデモンストレーションテストは、すでにわかっていることを示すだけで、システムの強化から運用上の火消しに開発時間を転用させるだけだろう。
「もし……だったら？」と質問でき、すべてのアイデアを一箇所に集められる場が欲しい。
例えば。
生成ノードはすべてのトランザクションを受信する必要はないように思える。 必要なデータは前のブロックハッシュだけだ。 そうだろう？
次に。 ほぼすべての公開アクセス可能なノードに接続できるだろう？ そのアドレスを収集し、ほぼすべてのノードへの接続を確立できる。 そして望むだけのデータを送りつけることができる。 例えば、膨大な量の偽の（あるいはそうでない）トランザクション。 大量の（おそらく無効な）トランザクション（あるいは別のゴミデータ）を受信・検証させることで、 ノードの生成能力を絞ることは可能ではないか？
違う、違う、まだ違う。自分で試してみたが、クライアントはそれらをすべて無視するだけだ。
もしそれが可能なら、難易度を下げることができるのではないか？
違う
長期間これを行えば良い。 自分のスーパーコンピューター（ボットネット）にとって許容可能な値まで下がったら、 ネットワークに接続する。ただし直接ではなく、 特殊なノードを経由して接続する。そのノードはまだフラッディングしているゴミデータをフィルターリングする特殊な方法でメッセージを転送する。 これにより、スーパーコンピューターはブロックを受信して生成に参加できるが、他のノードはフラッディングされたままで 生成 BTC のわずかな部分しか得られない。
違う
次に、生成 BTC に興味がない場合、ブロックチェーンフォークの生成を開始できる。 難易度が下がった直後に、隔離された環境でブロックチェーンの代替バージョンを生成し始める。 難易度はすぐには変わらないので、残りのネットワークがゴミデータを処理している間に ネットワークを上回ろうとできる。十分速く最長チェーンを全員に提示するが、その後難易度が上がる。 これにより、ブロックチェーンフォーク後に行った以前の支払いトランザクションを消去できる。 つまり、それらを回復して未使用のトランザクションを取り戻せるのではないか？そして再度使えるのか？ 以前のトランザクションがそのように「再支払い」された場合、新しいブロックチェーンにどう組み込まれるのか？
そしてこれは繰り返せる。 間違っているなら、「間違っている」と言ってほしい。 しかし、なぜかヒントもくれると助かる。
ここに挙げたことは、もう多くの人間が試した。だからこそリリースには多くのセキュリティアップデートがあるんだ 😉
それを成立させる唯一の方法は、群全体と現在の difficulty を上回る CPU パワーを持つことだ。時間逆行チェーン、低速 DoS、高速 DoS、群の操作、ワームホール、タイムトラベル──これまでにすべて試されてきた。だが何か独自のアイデアを思いついたなら、喜んで試す。
違う、違う、まだ違う。自分で試してみたが、クライアントはそれらをすべて無視するだけだ。
もう少しうまくやるチャンスはないのか？ 必要なのはチェーンの成長を遅らせることだけ。個々の khps はそのままでよい。
ここに挙げたことは、もう多くの人間が試した。だからこそリリースには多くのセキュリティアップデートがあるんだ 😉
あなた方多くの人々は、その経験、特に結果と結論を共有してくれるだろうか？ 実験を伴う良い分析は、科学研究論文として発表できるかもしれない。興味はあるだろうか？
それを成立させる唯一の方法は、群全体と現在のdifficultyを上回るCPUパワーを持つことだ。時間逆行チェーン、低速DoS、高速DoS、群の操作、ワームホール、タイムトラベル──これまでにすべて試されてきた。だが何か独自のアイデアを思いついたなら、喜んで試す。
設計上の弱点（実装上の脆弱性ではなく）の議論が、何らかの公開フォーラムで自身のセクションを持ち、より集約されて一般に届くようになり次第、他の独自のアイデアを提示することにやぶさかではない。ただ、もう「違う、それは不可能だ、もう議論済みだ、フォーラムを読め」と言われるのが嫌なだけだ。 飽きるんだ、本当に。フォーラムは繰り返されるアイデアで膨れ上がっている。それらを集めよう。 すでに行われた本物の分析が見たい。結果を確認するためと、努力を重複させないために。 頻繁に提案される（実は弱点ではない）弱点をまとめた wiki の記事を見たが、あれは分析でも議論でもなく、ただの言明にすぎず、あまり説得力がない。 それに、ここで議論されている他の多くの明白な（非）弱点には触れていない。
たとえば、私は、Bitcoin ノードの運用コストは設計上、PC を持つ平均的なジョーには手が届かないと主張する。 トランザクション量（特に完全な履歴）のせいで、控えめな PC ハードウェアで実用的に運用することは不可能になる。 今ではない。5年、あるいは 15年待ってみよう。そうすれば、Bitcoin の運用にサーバーハードウェアが必要になることが分かる。 ディスク上に Bitcoin ノードを保存するために必要な容量と、保存されたすべてのデータを処理する（受信するトランザクションごとに検証する）ために必要な時間を見積もる方法があるべきだ。 そして私の見積もりでは、世界的なトランザクションレートはシステムによって制限される。 ここで私が間違っている理由を文書化しよう。そうすれば誰もが気を煩わせる必要がなくなり、皆が安心して Bitcoin に参加できる。いいね？
たとえば、私は、Bitcoinノードの運用コストは設計上、PCを持つ平均的なジョーには手が届かないと主張する。
bitcoin の生成は、SETI@home が常に平均的なジョーにとって手が届くのと同じ意味で、常に平均的なジョーにとって手が届くものであり続ける。常に儲かるとは限らないが、常に手が届く。実のところ今は儲かる。50 は簡単に 3.50 ドルで売れるし、辛抱強く待てばもっと高くなる。これは、彼がもうずっと電源を入れっぱなしにしている平均的なコンピューターの電気代と、決して使い切っていない余剰のインターネット帯域幅のコストよりも多い。