フラッド攻撃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しか持っていないから）。
ルールは「いずれかのTxOut（出力）が0.01ビットコイン未満の値を持つ場合、0.01の手数料を課す」だ：
main.h:
foreach(const CTxOut& txout, vout)
if (txout.nValue < CENT)
nMinFee = CENT;
この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日14:58 UTC）この0.01 BTCのトランザクション手数料が「解決」している「ダストスパム」とは一体何なのか？
1ビットコインしか持っていない人でも100,000,000件のトランザクションを送ることができ、ネットワークを過負荷にする可能性がある。しかし、これは良い解決策ではない——制限が下げられても、大量のビットコインを保有している人がいるはずなので脆弱性は残る。
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の手数料を課す」だ：
main.h: foreach(const CTxOut& txout, vout) if (txout.nValue < CENT) nMinFee = CENT;
君のシナリオでは出力が2つある。1つは1 BTC、もう1つは0.005 BTCだ。0.005 < 0.01なので、トランザクションに手数料が適用される。
手数料のルールは任意に複雑にできるのかな？ そしてサイズ制限はハードコードされているのか、完全にノード次第なのか？
より多く含めるとハッシュレートは落ちる？
1 BTCを100万回行ったり来たり送ると、トランザクションチェーンが1本できる。100万件の0.000001 BTCのトランザクションを送ると、100万件のほぼ独立したトランザクションができ、それらをすべて記憶しておく必要がある。bitcoinが古い深く確認済みのトランザクションを破棄できる仕組みのため、長期的には前者のオーバーヘッドは後者よりはるかに小さい。ネットワークコストは似たり寄ったりかもしれないが、単一チェーンの場合はディスク容量のコストを大幅に削減できる。
「ダスト」が再び一つに集約され、再び十分に深く確認された場合に限り、ダストの領域は破棄できる。
ダニエル・ラリマーの投稿（2010年8月4日06: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日19: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をフレッドに送りたいとしよう。クラスタが1秒あたり10億khashで動作しているとすると、私はトランザクションを十分な数のノードに配布する必要がある。それによって、トランザクションが次のNブロック以内に記録されるのに十分な、合計に対するkhash/秒の割合を確保できるようにするわけだ。
そこで、生成ノードA、B、Cはそれぞれのkhashレートに比例して送信手数料を設定する。（彼らはどうやって自分のkhashレートを証明するんだ？ 時間の経過に対する累計ブロック生成数か？）
そこで私は、自分からフレッドへの0.001 BTCのトランザクションと、自分からAへの0.000001 BTCのトランザクションを送る。BとCには別のものを送る。
こうすると、A、B、Cはそのトランザクションを他の誰かに処理させることで利益を得ることはできなくなるので、回収したければ自分で処理しなければならない。
問題は、「0.001は私からフレッドへ1回だけ流れる、各ブロックで流れるのではない」というルールをどう強制するかだ。
1 BTCを100万回行ったり来たり送ると、トランザクションチェーンが1本できる。100万件の0.000001 BTCのトランザクションを送ると、100万件のほぼ独立したトランザクションができ、それらをすべて記憶しておく必要がある。bitcoinが古い深く確認済みのトランザクションを破棄できる仕組みのため、長期的には前者のオーバーヘッドは後者よりはるかに小さい。ネットワークコストは似たり寄ったりかもしれないが、単一チェーンの場合はディスク容量のコストを大幅に削減できる。
「ダスト」が再び一つに集約され、再び十分に深く確認された場合に限り、ダストの領域は破棄できる。
0.1 BTCを100万回送るのも、単一のトランザクションになるの？ 単一のトランザクションから独立したトランザクションに変わる境界はどこになるの？ その境界は少し下げられる？ 下げたら、何か悪い副作用はある？
そこで私は、自分からフレッドへの0.001 BTCのトランザクションと、自分からAへの0.000001 BTCのトランザクションを送る。BとCには別のものを送る。
こうすると、A、B、Cはそのトランザクションを他の誰かに処理させることで利益を得ることはできなくなるので、回収したければ自分で処理しなければならない。
問題は、「0.001は私からフレッドへ1回だけ流れる、各ブロックで流れるのではない」というルールをどう強制するかだ。
君が具体的に何を提案しているのか、私はまったく混乱している。
私は君に100ビットコインのトランザクションを送りたいとする。
君は私が「送信手数料」を払う必要があると言うが……それは誰に支払われ、具体的に何をするものなのだろう？
もし私がそれをA、B、Cに支払ったら、彼らは接続している全員に対してトランザクションを再ブロードキャストするのか？ そして彼らは、再ブロードキャスト先のノードに対して送信手数料を支払うのか？ 「送信手数料をありがとう」と言ってズル（私のトランザクションを握りつぶす）するのを、何が止めるんだ？
ネットワークのオーバーヘッドをカバーするために、すべてのトランザクションが最低限の手数料を持つべきだというサトシの提案は理にかなっている。トランザクションを含むブロックを生成した者がその手数料を受け取ることになる。
つまり、Bitcoinネットワーク全体をDDoS攻撃する能力は、ネットワーク接続やノードの数ではなく、BTCの購買力によってのみ制限されるということか？
ところで、いつかネットワークをテストしないか？ 既知のアドレスのリストに小さなトランザクションを送信するプロセスを自動化するのは簡単だ。 ネットワークを酷使して、影響を正確に把握しよう。
他のユーザーに注意喚起すべきだと思うが…
ところで、いつかネットワークをテストしないか？ 既知のアドレスのリストに小さなトランザクションを送信するプロセスを自動化するのは簡単だ。 ネットワークを酷使して、影響を正確に把握しよう。
他のユーザーに注意喚起すべきだと思うが…
テストネットワークを使うべきだ。
throughputの投稿（2010年8月10日10:13 UTC）ところで、いつかネットワークをテストしないか？ 既知のアドレスのリストに小さなトランザクションを送信するプロセスを自動化するのは簡単だ。 ネットワークを酷使して、影響を正確に把握しよう。
他のユーザーに注意喚起すべきだと思うが…
テストネットワークを使うべきだ。
テストネットワークはテスト規模だ。
うーん、次回は他のやつらが本番ネットワークを酷使する前に許可を求めてくるとは思えないがな。 彼らはただやるだけだ。
こんな単純な侵入に脆弱であれば、Bitcoinは使い物にならないと確信している。 現実の脅威に対して持続可能であることを証明すべきだ。私みたいにな😄
もう誰かが実験したかもしれないな？
blk*.datファイルは、できる限り小さく保っておきたい。
最終的な解決策は、大きくなっても気にしないことだ。
でも今はまだ小さいうちに、新しいユーザーがより早く始められるよう小さく保つのは良いことだ。クライアント専用モードを最終的に実装すれば、それはあまり問題にならなくなる。
トランザクション手数料についてはまだ作業が必要だ。フラッドが起きた場合でも、0.01のトランザクション手数料を支払うことで、キューを飛ばして次のブロックにトランザクションを入れることができるだろう。ただし、そのオプションをUIに追加する時間がまだなかった。
規模に関わらず、テストネットワークも同様の反応をするが、帯域幅の無駄と迷惑ははるかに少なくなる。
blk*.datファイルは、できる限り小さく保っておきたい。
最終的な解決策は、大きくなっても気にしないことだ。
でも今はまだ小さいうちに、新しいユーザーがより早く始められるよう小さく保つのは良いことだ。クライアント専用モードを最終的に実装すれば、それはあまり問題にならなくなる。
トランザクション手数料についてはまだ作業が必要だ。フラッドが起きた場合でも、0.01のトランザクション手数料を支払うことで、キューを飛ばして次のブロックにトランザクションを入れることができるだろう。ただし、そのオプションをUIに追加する時間がまだなかった。
規模に関わらず、テストネットワークも同様の反応をするが、帯域幅の無駄と迷惑ははるかに少なくなる。
OK、分かった。ほかのろくでなしどもがどうかは知らないけどね 😁