テストネットワークで行ったテスト、私の発見
[元の投稿内容は失われている。投稿者が件名を「af」、本文を「adgadg」に書き換えた状態でBitcoinTalkに残存している。]
実は…無料トランザクションを金額とその「古さ」の両方に基づいて優先順位付けすれば、この攻撃は無力になるはずだ。
基本的な考え方はこうだ。大量の少額無料トランザクションをスパムしている場合、大量の真新しい「小銭」が生成されることになる（古い50BTCコインベーストランザクションを取り、1ペニーを分割して1ペニーと49.99のお釣りを得る。次にその49.99を分割してさらに1ペニーを得る、という具合だ）。
保留中の無料トランザクションをソートし、より高額のトランザクションやブロックチェーンの深い位置に入力を持つ無料トランザクション（「古いお金」）に優先順位を与えれば、通常のトランザクションは通過できる。
スパムのトランザクションは依然としてネットワーク帯域幅とディスク容量を消費する。これが問題になる場合、ノードは少額の新しいトランザクションを無視し（中継しない）、スパムを行っているノードにトランザクションをキューに入れて再ブロードキャストさせればよい。最終的にはネットワークに少しずつ流れ込むだろうし、その間スパマーの小銭は拘束されたままだ。
実は…無料トランザクションを金額とその「古さ」の両方に基づいて優先順位付けすれば、この攻撃は無力になるはずだ。
保留中の無料トランザクションをソートし、より高額のトランザクションやブロックチェーンの深い位置に入力を持つ無料トランザクション（「古いお金」）に優先順位を与えれば、通常のトランザクションは通過できる。
より大きな金額のトランザクションに優先順位を付けても、問題は本当には解決しない。自分のアドレス間で大きな金額のBitcoinを無限に送り続けることでスパムが完全に可能だからだ。
古いトランザクションに優先順位を付けると、Bitcoinの購入時に大量のおつりが発生しないよう保有を分割するインセンティブが生まれる。保有を2のべき乗 * 0.01で持っていれば、おつりなしで何でも支払え、断片化も最小限になる。もちろん支出後にできるだけ早く保有を再バランスする必要があるが、その最善の方法は、私にはすぐには分からない。おつりをどう分割するか指定できるなら、特定の状況では有利かもしれない。複数の購入には3のべき乗が最適かもしれない。 いずれにせよ、最終的な効果はトランザクションの入出力が増えることだ。おそらく平均的な入出力の数は、トランザクション内のBitcoinペニー数の対数の何らかの非常に小さい倍数（あるいは大きい分数）になるだろう。これにより平均トランザクションサイズが10倍以上増加する可能性があると見積もる。
ByteCoin
より大きな金額のトランザクションに優先順位を付けても、問題は本当には解決しない。自分のアドレス間で大きな金額のBitcoinを無限に送り続けることでスパムが完全に可能だからだ。
いや、できない。送るたびに「新しい」ものになり、優先度は年齢に金額を掛けたものだからだ：
// 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は、フラッド攻撃中に正当なトランザクションが順番に割り込めるようにする複数の機能を組み合わせている。鍵となったのは、依存関係の経過時間に基づいてトランザクションの優先順位を決めるというギャビンのアイデアだ。すべてのコインは一定頻度で回転する権利がある。待ち時間が長いほど、より多くの優先度が蓄積される。優先度はsum(valuein * age) / txsizeだ。トランザクション手数料は依然として優先度より優先され、優先度は手数料階層内の処理順序を決定する。
優先度機能をサポートするため、SelectCoinsは、それしか残っていない場合の最後の手段としてのみ、自分の0承認トランザクションを使用する。これにより、実際にすべてのコインを急速に回転させることを強制しない限り、コインの急速な回転を防ぐのに役立つ。
優先度機能をサポートするため、SelectCoinsは、それしか残っていない場合の最後の手段としてのみ、自分の0承認トランザクションを使用する。これにより、実際にすべてのコインを急速に回転させることを強制しない限り、コインの急速な回転を防ぐのに役立つ。
もちろん、ネットワークがフラッドされておらず、現在の取引が保留されることをあまり心配していないなら、0承認の取引を優先的に使って、ネットワークが実際にフラッドされた時のために高い優先度のコインを「温存」する方がおそらく価値がある。
自分の理解が正しければ、現在のロジックは古い取引の蓄積された優先度を消費しやすいように見える。ただし、些細な点だ。
上の投稿で書いたように、最近回転した1000 BTCほどを入れて優先度を押し上げ、仕組みの裏をかくやり方は、もちろんまだ通用する！
ByteCoin
もちろん、ネットワークがフラッドされておらず、現在の取引が保留されることをあまり心配していないなら、0承認の取引を優先的に使って、ネットワークが実際にフラッドされた時のために高い優先度のコインを「温存」する方がおそらく価値がある。
次のブロックの前にフラッド攻撃が来る場合に備えて、少なくともある程度の優先度は使うべきだ。
すべての依存関係が少なくとも1承認を持っている限り、トランザクションが最初に十分な優先度を持っていなくても、依存関係が経過時間を重ねて優先度に達する。
ByteCoin上の投稿で書いたように、最近回転した1000 BTCほどを入れて優先度を押し上げ、仕組みの裏をかくやり方は、もちろんまだ通用する！
またはトランザクションにどれだけの優先度を使うかを管理すること。ソフトウェアが将来の計画を知らなければ、今優先度を使うべきか後のために温存すべきかわからない。しかし、そこまで詳細に踏み込む必要はないと思う。通常のユーザーとフラッド攻撃者の間には十分な差がある。
優先度がすべてを解決する必要はない。フラッド攻撃があると分かったら、-paytxfee=0.01を追加できる。優先度があれば、その前のトランザクションは、うまくいけば最悪でも遅くなるだけで、止まりはしないだろう。
優先度がすべてを解決する必要はない。フラッド攻撃があると分かったら、
-paytxfee=0.01を追加できる。優先度があれば、その前のトランザクションは、うまくいけば最悪でも遅くなるだけで、止まりはしないだろう。
それで、完全に同意する。直近のブロックが何で埋まっていたかを確認できるtxfeeモニタが必要だ。そうすれば推測なしに、手数料をより的確に見積もれる。
ByteCoinの投稿（2010年11月13日23:55 UTC）上の投稿で書いたように、最近回転した1000 BTCほどを入れて優先度を押し上げ、仕組みの裏をかくやり方は、もちろんまだ通用する！
あるいは、トランザクションにどれだけプライオリティを費やすかを管理することもできる。ただしソフトウェアは、ユーザーの今後の予定を知らないと、プライオリティを今使うべきか後に取っておくべきかを判断できない。
複雑さを提案して申し訳ないのだが、入力コインの「プライオリティ」を1ブロック以上さかのぼって追跡し、ある種のスライディング平均を取ることもできる。これにより、資金を移動させることによる「一時的な減価」の効果が減らせる。
10ホップさかのぼって「古い」資金が見つからなければ、くだらない小細工が行われているということだ。ただしこれは新しいタイプの複雑さ攻撃も生む。😞