フラッド攻撃 0.00000001 BC
こんにちは。もし誰かが数百万の 0.00000001 BC を数百万のアドレスに送信したらどうなるのだろうか？
=> ネットワークのすべてのピアがすべてのトランザクションを保存しなければならないのか？ => 各 0.00000001 の所有者/ハッシュはすべてのピアのブロックに格納されるのか？
ビットコインが BC の端数をどのように処理するのか、よく理解できていない。
まあ、現時点では次のようなシステムを作ることを止めるものは何もない：
A が B に 1.00000001 を送る B が A に 1.00000000 を返す
差し引きの結果はマイクロペイメントであり、処理手数料はかからない。私は上記と非常に似たことを行うシステムを作っている。実際のところ、「マイクロペイメント」システムは BTC ブロックの外部で処理し、支払いを「集計」してから送信すべきだろう。
処理手数料の設計は素晴らしいと思う。各ノードは含めたいトランザクションを選り好みでき、したがって「含まれるまでの時間」はあなたの「提示」を受け入れるノードの数に正比例する。最悪の場合、自分一人の PC がブロックを作成できるまで待たなければならず、現時点では何週間もかかりうる！
実際、トランザクションを伝搬するノードに支払いを提供するのは合理的だと思う。ただし、それを「強制」し、不正なクライアントが手数料だけ集めて作業しないのを防ぐ方法があればの話だが。
まあ、現時点では次のようなシステムを作ることを止めるものは何もない：
AがBに1.00000001を送る BがAに1.00000000を返す
差し引きの結果はマイクロペイメントであり、処理手数料はかからない。私は上記と非常に似たことを行うシステムを作っている。実際のところ、「マイクロペイメント」システムはBTCブロックの外部で処理し、支払いを「集計」してから送信すべきだろう。
…B が最初にゼロ Bitcoin で始めた場合を除いて。その場合 B は行き詰まる。1.0 を返送することで 0.00000001 Bitcoin の「おつり」トランザクションが発生し、それが 0.01BTC の手数料を引き起こすが、B はそれを支払えない（1.0000000001 しか持っていないから）。
この 0.01 BTC のトランザクション手数料が「解決」している「ダストスパム」とは一体何なのか？ bytemaster が提案しているようなマイクロペイメント実装を妨げるため、害の方が大きいように思える。
ネットワークが既存のトランザクション量で苦しんでいるとは認識していない。 大量のトランザクションを送りたい人は、すでに x BTC を自分宛に何度も送ることで可能だ。
この0.01 BTCのトランザクション手数料が「解決」している「ダストスパム」とは一体何なのか？ bytemasterが提案しているようなマイクロペイメント実装を妨げるため、害の方が大きいように思える。
ネットワークが既存のトランザクション量で苦しんでいるとは認識していない。 大量のトランザクションを送りたい人は、すでにx BTCを自分宛に何度も送ることで可能だ。
1 ビットコインしか持っていない人でも 100,000,000件のトランザクションを送ることができ、ネットワークを過負荷にする可能性がある。しかし、これは良い解決策ではない——制限が下げられても、大量のビットコインを保有している人がいるはずなので脆弱性は残る。
より良い解決策は、0.01 未満のトランザクションの優先度を下げ、キュー内に 10,000件（など）を超える場合は完全にドロップすることだろう。そうすれば、これらのトランザクションは他のトランザクションより遅く信頼性が低くなるが、動作はするし「本物の」トランザクションには干渉しない。
優先度は何ノードがそれを受け入れるかに完全に依存する。つまり、ノードの 1%しか 0.000001 btc のトランザクション手数料を受け入れなければ、次のブロックに含まれる確率は 1%だ。すべてのノードが 1 BTC のトランザクション手数料を受け入れれば、次のブロックに含まれる確率はほぼ 100%だ。
Instiの投稿（2010年8月4日 05:58 UTC）この0.01 BTCのトランザクション手数料が「解決」している「ダストスパム」とは一体何なのか？
1ビットコインしか持っていない人でも100,000,000件のトランザクションを送ることができ、ネットワークを過負荷にする可能性がある。ただしこれは良い解決策ではない。制限が引き下げられても脆弱性は残る。なぜなら大量のBitcoinを貯めている人が確実にいるからだ。
1 ビットコインしか持っていない人がすでに 100,000,000件のトランザクションを送ることは可能で、自分宛にコインを繰り返し送ればいい。トランザクションの値が 1 であろうと 0.00000001 であろうと、何が違うのか？
これは利よりも害の方が大きいように思える。bytemasterが提案しているようなマイクロペイメント実装を阻むからだ。Bitcoinは現在、非常に小さなマイクロペイメントには実用的ではない。集約メカニズムなしの検索ごと支払いやページビューごと支払いには、また0.01未満の支払いには。ダストスパム制限は、そのような過度に小さなマイクロペイメントを意図的に防ごうとする最初の試みだ。
Bitcoin は既存の決済手段で実用的なものよりも小さなトランザクションに対して実用的だ。マイクロペイメント範囲の上位と呼べるものを含むのに十分な小ささだ。しかし、任意に小さなマイクロペイメントに対して実用的であるとは主張していない。
Instiの投稿（2010年8月4日 14:58 UTC）これは利益よりも害の方が大きいように思える。なぜならbytemasterが提案しているようなマイクロペイメント実装を妨げてしまうからだ。
Bitcoinは極めて小額のマイクロペイメントには実用的ではない。集約メカニズムのない検索ごとやページビューごとの支払いには向いていないし、ましてや0.01未満を支払う必要があるものには向いていない。ダストスパム制限は、こうした過度に小さいマイクロペイメントを意図的に防ごうとする最初の試みだ。
Bitcoinは既存の支払い手段で実用的とされる金額よりも小さなトランザクションには実用的だ。マイクロペイメント帯の上限と呼べるものを含めるくらいには小さい。だが、任意に小さいマイクロペイメントに対して実用的だと主張しているわけではない。
なぜダメなんだ？ サイズがどう違いを生むのか分からない。 単にシステムが処理できるトランザクション数の問題だからか？
ユーザーがあなたに1.005bcを送り、あなたが1bcを返す。このシナリオでは手数料はかかるんだろうか？戻ってくるおつりが0.005bcになるからだ。
ああ、それは上で取り上げたとおりだ。
ギャビン・アンドレセンの投稿（2010年8月4日 12:55 UTC）ルールは「いずれかのTxOut（出力）が0.01ビットコイン未満の値を持つ場合、0.01の手数料を課す」だ： Code:main.h: foreach(const CTxOut& txout, vout) if (txout.nValue nMinFee = CENT;
君のシナリオでは出力が 2 つある。1 つは 1 BTC、もう 1 つは 0.005 BTC だ。 0.005 < 0.01 なので、トランザクションに手数料が適用される。
手数料のルールは任意に複雑にできるのか？そしてサイズ制限はハードコードされているのか、完全にノード次第なのか？
より多く含めるとハッシュレートは落ちるのか？
ダニエル・ラリマーの投稿（2010年8月3日 21:22 UTC）まあ、現時点では次のようなシステムを作ることを止めるものは何もない：
AがBに1.00000001を送る BがAに1.00000000を返す
差し引きの結果はマイクロペイメントであり、処理手数料はかからない。
…Bが最初にゼロBitcoinで始めた場合を除いて。その場合Bは行き詰まる。1.0を返送することで0.00000001 Bitcoinの「おつり」トランザクションが発生し、それが0.01BTCの手数料を引き起こすが、Bはそれを支払えない（1.0000000001しか持っていないから）。
a と b が両方とも 1 BTC で始めて、単一のトランザクションで 2 つの入力と 2 つの出力を使って 0.0001 を転送することに合意すれば、a を 0.9999 に、b を 1.0001 に変更できる。ネットワークの他のノードはそのトランザクションを受け入れるだろう。
唯一の障壁は、トランザクションを作成する人が通常は異なるウォレットの両方の入力の秘密鍵を必要とすることだ。トランザクションを作成する人が不正をする可能性がある。
Bitcoinは現時点では非常に小さなマイクロペイメントには実用的でない。集約メカニズムなしでの検索ごとやページビューごとの支払いのようなもの、0.01未満を支払う必要があるものには向いていない。ダストスパム制限は、そのような極端に小さなマイクロペイメントを意図的に防止する最初の試みだ。
Bitcoinは既存の決済手段で実用的なものよりも小さなトランザクションに対して実用的だ。マイクロペイメント範囲の上位と呼べるものを含むのに十分な小ささだ。しかし、任意に小さなマイクロペイメントに対して実用的であるとは主張していない。
なぜ実用的ではないのか？良いマイクロペイメントシステムは何千ものトランザクション（例えばパケットごとに 1 つ）を生成することを避けるべきだが、bytemaster のお釣りのアイデアが間違っているということにはならない： それは素晴らしいユースケースに思える。さらに、llama が言ったように、トランザクション手数料の固定部分は、そのトランザクションをブロックに含めるための実際のコストを常に反映すべきだ。では、ダストスパム対策のより知的で痛みの少ない実装方法はあるだろうか？
現行のシステムは問題なく機能していると思う。マイクロペイメントシステムを実装したければ、自分の小さなトランザクションを含めるのに十分なノードをホストし、十分な処理能力を提供する必要がある。ノードがマイクロペイメントトランザクションを受け入れたり転送したりすることを望まないなら、それを要求する理由はない。
本当の問題は、正当な自動マイクロペイメントシステムでさえ、クレジットカードシステムが現在使用しているよりも多くのトランザクションを導入して bitcoin を過負荷にする可能性があることだ。その結果、ブロックサイズが巨大になる可能性がある。
私のユースケースでは、P2P システムで優先ダウンロードに対価を支払う。1 つの「torrent」ファイルに 100,000人全員がシードとダウンロードをしていると仮定する。簡単に 1分あたり 100,000 のマイクロペイメントが発生し得る。もちろん、2 つのクライアント間でアップロード!=ダウンロードの場合にのみ BTC を使用すればよい。
分散型であるため「スパム」と正当な利用を区別する簡単な方法はない。1回あたり 1+ BTC を転送し、残高が 0.01 を超えたらお釣りを返す私のソリューションでさえ、大規模なトランザクション膨張を引き起こし得る。
個別のトランザクション処理の「コスト」は低い（.00001 BTC）かもしれないが、自動支払い交渉/入札システムを使う数百万のユーザーからのそれらすべての小さなトランザクションを処理するコストは、すべての着信トランザクションをリッスンすることさえ不可能にするだろう。
この問題の唯一の解は、トランザクションのブロードキャストを「無料ではない」 ようにすることだ。つまり、私に取り込ませたいなら、私に支払いをしてもらう必要がある。結果として (ネットワーク的にも文字通りも) 、各クライアントはトランザクションを送る相手にも支払いをする必要があり、ブロックに取り込んだ者だけに支払うのではなくなる。こうすれば経済原理が働き、誰もトランザクションのブロードキャストシステムにただ乗りできなくなる。
これが意味するのは、あなたが支払いをした受信先のノードがあなたのトランザクションをブロックに組み込もうと試みて成功するまで、支払いの通知すら受け取れないかもしれないということだ。つまり 0/未確認の表示すら出ず、ブロックに入って初めて、組み込みを試みるよう支払いを受けていない者にもそのトランザクションの存在が知られることになる。
この構造は pay-to-ip 型のシステムを助長する。受取人側が、その取引を取り込んでもらうための支払いを負担する形になるからだ。受取人は自分でビットコイン生成を回すか、自分の代わりに回してくれる相手にトランザクションを送るための支払いをするかのどちらかになる。
マイクロペイメントについての良い部分を書き忘れた。現時点では Bitcoin がより小さなマイクロペイメントに実用的だとは思わないが、ストレージと帯域幅のコストが下がり続けるにつれて、いずれそうなるだろう。Bitcoin が大規模に普及すれば、その頃にはすでにそうなっているかもしれない。もう一つの実用化の方法は、クライアント専用モードを実装し、ネットワークノードの数がより少数のプロフェッショナルなサーバーファームに集約されることだ。必要なサイズのマイクロペイメントはいずれ実用的になるだろう。5年か 10年で、帯域幅とストレージは些細なものに見えるようになると思う。
ネットワークが DoS 攻撃に対して無敵だとは主張していない。ほとんどの P2P ネットワークは多くの方法で DoS 攻撃を受ける可能性があると思う。（余談だが、レコード会社がすべてのファイル共有ネットワークに DoS 攻撃をしたいと考えているが、ハッキング防止/濫用防止法に違反したくないという記事を読んだ。）
無駄なトランザクションを大量に往復させる DoS 攻撃を受け始めた場合、最低 0.01 のトランザクション手数料を支払い始める必要があるだろう。バージョン 0.1.5 にはそれを設定するオプションがあったが、混乱を減らすために削除した。無料トランザクションは素晴らしいことであり、人々が濫用しない限りそのままにしておける。
ここで疑問が生じる：各トランザクションに最低 0.01 の手数料がある場合、最低限の 0.01 であれば自動的に手数料を追加すべきだろうか？ 毎回尋ねるのは非常に面倒だろう。50.00 持っていて 10.00 送る場合、受取人は 10.00 を受け取り、残りは 39.99 になる。自動的に追加すべきだと思う。他の多くの種類のサービスが自動的に追加する手数料と比べれば些細なものだ。
FreeMoneyの投稿（2010年8月4日 10:30 UTC）より多く含めるとハッシュレートは落ちるのか？
いいえ、全くしない。
支払いは一般的に前払いで、例えば一度に1 BTCを支払い、接続が閉じられた時にお釣りが返されます。このルールでは、追加のトランザクションなしに単純な「検索クエリ」の支払いは不可能になります。
— bytemaster
代替案の一つは、まとめ払いシステムを使うことだ。例えば一度に 1000 ページ、画像、ダウンロード、検索などを支払う。1000 ページを使い切ったら、さらに 1000 ページ分を支払う。1 ページしか使わなければ、使わないかもしれない 999 ページ分が残るが、1000 ページあたりのコストはまだ小さいので大した問題ではない。
あるいは日単位で支払うこともできる。特定の日にサイトに初めてアクセスした時、24時間分のアクセスを支払う。
1000 単位や日単位は消費者にとっても理解しやすいかもしれない。アイテム単位だと加算が速すぎないか心配するが、24時間無制限ならコストがわかる。あるいは 1000 が十分な量に思えれば、おそらく使い切らないだろうと思って、クリックするたびにコストがかかることを心配しなくて済む。
1 BTCを100万回行ったり来たり送ると、トランザクションチェーンが1本できる。100万件の0.000001 BTCのトランザクションを送ると、100万件のほぼ独立したトランザクションができ、それらをすべて記憶しておく必要がある。bitcoinが古い深く確認済みのトランザクションを破棄できる仕組みのため、長期的には前者のオーバーヘッドは後者よりはるかに小さい。ネットワークコストは似たり寄ったりかもしれないが、単一チェーンの場合はディスク容量のコストを大幅に削減できる。
「ダスト」が再び一つに集約され、再び十分に深く確認された場合に限り、ダストの領域は破棄できる。
改良された攻撃はこんな感じになる：1BTC から始めて、0.999999999BTC を送金し、次に 0.999999998BTC を……と続ける。 結果として、100 万個（マイナス 10000）のアカウントがそれぞれ 0.000000001BTC を持つことになる。
現行のシステムは問題なく機能していると思う。マイクロペイメントシステムを実装したければ、自分の小さなトランザクションを含めるのに十分なノードをホストし、十分な処理能力を提供する必要がある。ノードがマイクロペイメントトランザクションを受け入れたり転送したりすることを望まないなら、それを要求する理由はない。
それを実装する方法がわからない。ブロック作成者へのトランザクション手数料は、追加サイズなしでトランザクション手数料を含める特別なトリックを使っている。各トランザクション手数料に対してトランザクションがあるとしたら、トランザクション手数料のトランザクションに対するトランザクション手数料はどうなるのだろうか？
トランザクション手数料ごとにトランザクションがあるとしたら、トランザクション手数料のトランザクションのトランザクション手数料はどうなるのか？
トランザクション手数料のトランザクションは、メインのトランザクションの完全に予測可能な結果として設計され、メインのトランザクション処理の手数料には手数料トランザクションの必要性も考慮されるだろう。つまり、手数料トランザクションは自身の手数料を含むことになる。したがって、これは管理可能な問題のようだ。
ByteCoin
現在、トランザクション手数料のアドレスは「空白」のままで、ブロック生成者が記入する。 今度はブロック構築を依頼する相手のアドレスを記入する。
送信手数料 <= ブロック統合手数料の場合、誰もトランザクションを利益的に転送できないため、自分自身でブロックを生成する必要がある。
現在、トランザクション手数料のアドレスは「空白」のままで、ブロック生成者が記入する。
一人だけにブロックの構築を依頼するなら、何日もかかる可能性がある。ああ、各ノードに手数料を書き込んだ異なるバリエーションを送るということか？
現在の仕組みでは、これを構築した人が手数料を得る。
必要であれば、トランザクションブロードキャストに BitTorrent 式の相互主義を導入できるだろう。手数料付きトランザクションを私にリレーしてくれなければ、あなたにもリレーしない。ただし、実際には問題にならないだろう。正しくリレーする 1 つのノードがあれば、貪欲にリレーしない他の 7 つのノードを相殺できる。
前提としては、同じトランザクションのバリエーションを別々のノードに送り、その際に自分のトランザクションを統合してもらうための「チップ」を付ける、ということだ。そのノードがチップを回収するためには最終的にブロックを生成する必要があるが、まあいずれは生成するだろう。チップの額は、そのユーザーが送信手数料を「再ブロードキャスト」できる金額より低く設定する。だから再帰的な送信手数料は発生しない。
仮に俺が 0.001 BTC を Fred に送りたいとしよう。クラスタが 1秒あたり 10 億 khash で動作しているとすると、俺はトランザクションを十分な数のノードに配布する必要がある。それによって、トランザクションが次の N ブロック以内に記録されるのに十分な、合計に対する khash/秒の割合を確保できるようにするわけだ。
そこで、生成ノード A、B、C はそれぞれの khash レートに比例して送信手数料を設定する。（彼らはどうやって自分の khash レートを証明するんだ？時間の経過に対する累計ブロック生成数か？）
そこで俺は、自分から Fred への 0.001 BTC のトランザクションと、自分から A への 0.000001 BTC のトランザクションを送る。B と C には別のものを送る。
こうすると、A、B、C はそのトランザクションを他の誰かに処理させることで利益を得ることはできなくなるので、回収したければ自分で処理しなければならない。
問題は、「0.001 は俺から Fred へ 1回だけ流れる、各ブロックで流れるのではない」というルールをどう強制するかだ。
1 BTCを100万回行ったり来たり送ると、トランザクションチェーンが1本できる。100万件の0.000001 BTCのトランザクションを送ると、100万件のほぼ独立したトランザクションができ、それらをすべて記憶しておく必要がある。bitcoinが古い深く確認済みのトランザクションを破棄できる仕組みのため、長期的には前者のオーバーヘッドは後者よりはるかに小さい。ネットワークコストは似たり寄ったりかもしれないが、単一チェーンの場合はディスク容量のコストを大幅に削減できる。
「ダスト」が再び一つに集約され、再び十分に深く確認された場合に限り、ダストの領域は破棄できる。
0.1 BTC を 100 万回送るのも、単一のトランザクションになるのか？単一のトランザクションから独立したトランザクションに変わる境界はどこなんだ？ その境界は少し下げられるか？下げた場合、何か悪い副作用はあるか？
そこで俺は、自分からFredへの0.001 BTCのトランザクションと、自分からAへの0.000001 BTCのトランザクションを送る。BとCには別のものを送る。
こうすると、A、B、Cはそのトランザクションを他の誰かに処理させることで利益を得ることはできなくなるので、回収したければ自分で処理しなければならない。
問題は、「0.001は俺からFredへ1回だけ流れる、各ブロックで流れるのではない」というルールをどう強制するかだ。
君が具体的に何を提案しているのか、私はまったく混乱している。
私は君に 100 ビットコインのトランザクションを送りたいとする。
君は私が「送信手数料」を払う必要があると言うが……それは誰に支払われ、具体的に何をするものなんだ？
もし私がそれを A、B、C に支払ったら、彼らは接続している全員に対してトランザクションを再ブロードキャストするのか？そして彼らは、再ブロードキャスト先のノードに対して送信手数料を支払うのか？「送信手数料をありがとう」と言ってズル（私のトランザクションを握りつぶす）するのを、何が止めるんだ？
ネットワークのオーバーヘッドをカバーするために、すべてのトランザクションが最低限の手数料を持つべきだというサトシの提案は理にかなっている。トランザクションを含むブロックを生成した者がその手数料を受け取ることになる。
つまり、Bitcoin ネットワーク全体を DDoS 攻撃する能力は、ネットワーク接続やノードの数ではなく、BTC の購買力によってのみ制限されるということか？
ところで、いつかネットワークをテストしないか？ 既知のアドレスのリストに小さなトランザクションを送信するプロセスを自動化するのは簡単だ。 ネットワークを酷使して、影響を正確に把握しよう。
他のユーザーに注意喚起すべきだと思うが…
ところで、いつかネットワークをテストしないか？ 既知のアドレスのリストに小さなトランザクションを送信するプロセスを自動化するのは簡単だ。 ネットワークを酷使して、影響を正確に把握しよう。
他のユーザーに注意喚起すべきだと思うが…
テストネットワークを使うべきだ。
throughputの投稿（2010年8月10日 01:13 UTC）ところで、いつかネットワークをテストしないか？ 既知のアドレスのリストに小さなトランザクションを送信するプロセスを自動化するのは簡単だ。 ネットワークを酷使して、影響を正確に把握しよう。
他のユーザーに注意喚起すべきだと思うが…
テストネットワークを使うべきだ。
テストネットワークはテスト規模だ。
うーん、次回は他のやつらが本番ネットワークを酷使する前に許可を求めてくるとは思えないがな。 彼らはただやるだけだ。
こんな単純な侵入に脆弱であれば、Bitcoin は使い物にならないと確信している。 現実の脅威に対して持続可能であることを証明すべきだ。俺みたいにな 😄
もう誰かが実験したかもしれないな？
できる限り blk*.dat ファイルを小さく保てると良いな。
最終的な解決策は、大きくなっても気にしないことだ。
でも今はまだ小さいうちに、新しいユーザーがより早く始められるよう小さく保つのは良いことだ。クライアント専用モードを最終的に実装すれば、それはあまり問題にならなくなる。
トランザクション手数料についてはまだ作業が必要だ。フラッドが起きた場合でも、0.01 のトランザクション手数料を支払うことで、キューを飛ばして次のブロックにトランザクションを入れることができるだろう。ただし、そのオプションを UI に追加する時間がまだなかった。
規模に関わらず、テストネットワークも同様の反応をするが、帯域幅の無駄と迷惑ははるかに少なくなる。
できる限りblk*.datファイルを小さく保てると良いな。
最終的な解決策は、大きくなっても気にしないことだ。
でも今はまだ小さいうちに、新しいユーザーがより早く始められるよう小さく保つのは良いことだ。クライアント専用モードを最終的に実装すれば、それはあまり問題にならなくなる。
トランザクション手数料についてはまだ作業が必要だ。フラッドが起きた場合でも、0.01のトランザクション手数料を支払うことで、キューを飛ばして次のブロックにトランザクションを入れることができるだろう。ただし、そのオプションをUIに追加する時間がまだなかった。
規模に関わらず、テストネットワークも同様の反応をするが、帯域幅の無駄と迷惑ははるかに少なくなる。
OK、了解した。他のクソ野郎どもがどうかは知らんがな 😁