テストネットワークで行ったテスト、私の発見
実は…無料トランザクションを金額とその「古さ」の両方に基づいて優先順位付けすれば、この攻撃は無力になるはずだ。
基本的な考え方はこうだ。大量の少額無料トランザクションをスパムしている場合、大量の真新しい「小銭」が生成されることになる（古い50BTC生成トランザクションを取り、1ペニーを分割して1ペニーと49.99のお釣りを得る。次にその49.99を分割してさらに1ペニーを得る、という具合だ）。
保留中の無料トランザクションをソートし、より高額のトランザクションやブロックチェーンの深い位置に入力を持つ無料トランザクション（「古いお金」）に優先順位を与えれば、通常のトランザクションは通過できる。
スパムのトランザクションは依然としてネットワーク帯域幅とディスク容量を消費する。これが問題になる場合、ノードは少額の新しいトランザクションを無視し（中継しない）、スパムを行っているノードにトランザクションをキューに入れて再ブロードキャストさせればよい。最終的にはネットワークに少しずつ流れ込むだろうし、その間スパマーの小銭は拘束されたままだ。
Quote from: gavinandresen on November 07, 2010, 02:14:29 AM
実は…無料トランザクションを金額とその「古さ」の両方に基づいて優先順位付けすれば、この攻撃は無力になるはずだ。
基本的な考え方はこうだ。大量の少額無料トランザクションをスパムしている場合、大量の真新しい「小銭」が生成されることになる（古い50BTC生成トランザクションを取り、1ペニーを分割して1ペニーと49.99のお釣りを得る。次にその49.99を分割してさらに1ペニーを得る、という具合だ）。
保留中の無料トランザクションをソートし、より高額のトランザクションやブロックチェーンの深い位置に入力を持つ無料トランザクション（「古いお金」）に優先順位を与えれば、通常のトランザクションは通過できる。
スパムのトランザクションは依然としてネットワーク帯域幅とディスク容量を消費する。これが問題になる場合、ノードは少額の新しいトランザクションを無視し（中継しない）、スパムを行っているノードにトランザクションをキューに入れて再ブロードキャストさせればよい。最終的にはネットワークに少しずつ流れ込むだろうし、その間スパマーの小銭は拘束されたままだ。
より大きな金額のトランザクションに優先順位を付けても、問題は本当には解決しない。自分のアドレス間で大きな金額のBitcoinを無限に送り続けることでスパムが完全に可能だからだ。
古いトランザクションに優先順位を付けると、Bitcoinの購入時に大量のおつりが発生しないよう保有を分割するインセンティブが生まれる。保有を2のべき乗 * 0.01で持っていれば、おつりなしで何でも支払え、断片化も最小限になる。もちろん支出後に保有を再バランスする必要があるが、すぐにできる最善の方法は自明ではない。おつりをどう分割するか指定できるなら、特定の状況では有利かもしれない。複数の購入には3のべき乗が最適かもしれない。 いずれにせよ、最終的な効果はトランザクションの入出力が増えることだ。おそらく平均的な入出力の数は、トランザクション内のBitcoinペニー数の対数の何らかの非常に小さい倍数（あるいは大きい分数）になるだろう。これにより平均トランザクションサイズが10倍以上増加する可能性があると見積もる。
ByteCoin
Quote from: ByteCoin on November 08, 2010, 02:31:22 AM
Quote from: gavinandresen on November 07, 2010, 02:14:29 AM
実は…金額とその「年齢」の両方に基づいて無料トランザクションに優先順位を付ければ、この攻撃は無力化できるはずだ。
より大きな金額のトランザクションや、ブロックチェーンの深いところに入力がある無料トランザクション（「古いお金」）に優先順位を付ければ、通常のトランザクションは通過できる。
より大きな金額のトランザクションに優先順位を付けても、問題は本当には解決しない。自分のアドレス間で大きな金額のBitcoinを無限に送り続けることでスパムが完全に可能だからだ。
古いトランザクションに優先順位を付けると、Bitcoinの購入時に大量のおつりが発生しないよう保有を分割するインセンティブが生まれる。保有を2のべき乗 * 0.01で持っていれば、おつりなしで何でも支払え、断片化も最小限になる。もちろん支出後に保有を再バランスする必要があるが、すぐにできる最善の方法は自明ではない。おつりをどう分割するか指定できるなら、特定の状況では有利かもしれない。複数の購入には3のべき乗が最適かもしれない。 いずれにせよ、最終的な効果はトランザクションの入出力が増えることだ。おそらく平均的な入出力の数は、トランザクション内のBitcoinペニー数の対数の何らかの非常に小さい倍数（あるいは大きい分数）になるだろう。これにより平均トランザクションサイズが10倍以上増加する可能性があると見積もる。
ByteCoin
いや、できない。送るたびに「新しい」ものになり、優先度は年齢に金額を掛けたものだからだ： Code:// Priority is sum(valuein * age) / txsize (valuein is the size of the bitcoin input, age is # of blocks deep, and txsize is the number of bytes the transaction takes up)
ウォレット内のコインをいじればいじるほど、（他の全員に比べて）それらは新しくなり、優先度は低くなる。深く考えてはいないが、コインをそのままにして必要に応じてお釣りを作る方がおそらく最善だと思う。しかし、ぜひ自分のクライアントを作成してテストネットワークで何かを壊してみてほしい！
davidonpdaの助けを借りて、今日サトシの最新のコード変更（取引の年齢、入力ビットコイン量、取引サイズ（バイト）に基づく優先度設定——SVN rev 176）を使って自分でテストを行った。
期待通りに動作し、ネットワークにフラッドされている少額の取引よりも大きく古い取引を優先させたため、誰かが嫌がらせで取引をフラッドしても「通常」の取引は迅速に承認される。
フラッドテストをテストネットに限定してくれてありがとう。
バージョン0.3.15は、フラッド攻撃中に正当なトランザクションがキューを飛ばすのに役立つ複数の機能を組み合わせている。鍵となったのは、依存関係の経過時間に基づいてトランザクションの優先順位を決めるというGavinのアイデアだ。すべてのコインは一定頻度で回転する権利がある。待ち時間が長いほど、より多くの優先度が蓄積される。優先度は sum(valuein * age) / txsize だ。トランザクション手数料は依然として優先度より優先され、優先度は手数料階層内の処理順序を決定する。
優先度機能をサポートするため、SelectCoinsは、それしか残っていない場合の最後の手段としてのみ、自分の0承認トランザクションを使用する。これにより、実際にすべてのコインを急速に回転させることを強制しない限り、コインの急速な回転を防ぐのに役立つ。
Quote from: satoshi on November 13, 2010, 11:25:26 PM
フラッドテストをテストネットに限定してくれてありがとう。
バージョン0.3.15は、フラッド攻撃中に正当なトランザクションがキューを飛ばすのに役立つ複数の機能を組み合わせている。鍵となったのは、依存関係の経過時間に基づいてトランザクションの優先順位を決めるというGavinのアイデアだ。すべてのコインは一定頻度で回転する権利がある。待ち時間が長いほど、より多くの優先度が蓄積される。優先度は sum(valuein * age) / txsize だ。トランザクション手数料は依然として優先度より優先され、優先度は手数料階層内の処理順序を決定する。
優先度機能をサポートするため、SelectCoinsは、それしか残っていない場合の最後の手段としてのみ、自分の0承認トランザクションを使用する。これにより、実際にすべてのコインを急速に回転させることを強制しない限り、コインの急速な回転を防ぐのに役立つ。
もちろん、ネットワークがフラッドされておらず、現在の取引が保留されることをあまり心配していないなら、0承認の取引を優先的に使って、ネットワークが実際にフラッドされた時のために高い優先度のコインを「温存」する方がおそらく価値がある。
自分の理解が正しければ、現在のロジックは古い取引の蓄積された優先度を消費しやすいように見える。ただし、些細な点だ。
上述した投稿で説明した、最近回転した1000 BTC程度を含めて優先度を上げるシステムのゲーミングは、もちろんまだ機能する！
ByteCoin
Quote from: ByteCoin on November 13, 2010, 11:55:11 PM
Quote from: satoshi on November 13, 2010, 11:25:26 PM
フラッドテストをテストネットに限定してくれてありがとう。
バージョン0.3.15は、フラッド攻撃中に正当なトランザクションがキューを飛ばすのに役立つ複数の機能を組み合わせている。鍵となったのは、依存関係の経過時間に基づいてトランザクションの優先順位を決めるというGavinのアイデアだ。すべてのコインは一定頻度で回転する権利がある。待ち時間が長いほど、より多くの優先度が蓄積される。優先度は sum(valuein * age) / txsize だ。トランザクション手数料は依然として優先度より優先され、優先度は手数料階層内の処理順序を決定する。
優先度機能をサポートするため、SelectCoinsは、それしか残っていない場合の最後の手段としてのみ、自分の0承認トランザクションを使用する。これにより、実際にすべてのコインを急速に回転させることを強制しない限り、コインの急速な回転を防ぐのに役立つ。
もちろん、ネットワークがフラッドされておらず、現在の取引が保留されることをあまり心配していないなら、0承認の取引を優先的に使って、ネットワークが実際にフラッドされた時のために高い優先度のコインを「温存」する方がおそらく価値がある。
自分の理解が正しければ、現在のロジックは古い取引の蓄積された優先度を消費しやすいように見える。ただし、些細な点だ。
上述した投稿で説明した、最近回転した1000 BTC程度を含めて優先度を上げるシステムのゲーミングは、もちろんまだ機能する！
ByteCoin
次のブロックの前にフラッド攻撃が来る場合に備えて、少なくともある程度の優先度は使うべきだ。
すべての依存関係が少なくとも1承認を持っている限り、トランザクションが最初に十分な優先度を持っていなくても、依存関係が経過時間を重ねて優先度に達する。
引用：上の投稿で説明したように、最近回転させた1000 BTC程度を含めて優先度を上げることでシステムをゲームすることは、もちろん依然として可能です！ またはトランザクションにどれだけの優先度を使うかを管理すること。ソフトウェアが将来の計画を知らなければ、今優先度を使うべきか後のために温存すべきかわからない。しかし、そこまで詳細に踏み込む必要はないと思う。通常のユーザーとフラッド攻撃者の間には十分な差がある。
優先度がすべてを解決する必要はない。フラッド攻撃があると分かったら、-paytxfee=0.01を追加できる。優先度があれば、その前のトランザクションは最悪でも遅くなるだけで、止まることはないはずだ。