フラッド攻撃 0.00000001 BC
こんにちは。もし誰かが数百万の0.00000001 BCを数百万のアドレスに送信したらどうなるのだろうか？
=> ネットワークのすべてのピアがすべてのトランザクションを保存しなければならないのか？ => 各0.00000001の所有者/ハッシュはすべてのピアのブロックに格納されるのか？
ビットコインがBCの端数をどのように処理するのか、よく理解できていない。
まあ、現時点では次のようなシステムを作ることを止めるものは何もない：
AがBに1.00000001を送る BがAに1.00000000を返す
差し引きの結果はマイクロペイメントであり、処理手数料はかからない。私は上記と非常に似たことを行うシステムを作っている。実際のところ、「マイクロペイメント」システムはBTCブロックの外部で処理し、支払いを「集計」してから送信すべきだろう。
処理手数料の設計は素晴らしいと思う。各ノードは含めたいトランザクションを選り好みでき、したがって「含まれるまでの時間」はあなたの「提示」を受け入れるノードの数に正比例する。最悪の場合、自分一人のPCがブロックを作成できるまで待たなければならず、現時点では何週間もかかりうる！
実際、トランザクションを伝搬するノードに支払いを提供するのは合理的だと思う。ただし、それを「強制」し、不正なクライアントが手数料だけ集めて作業しないのを防ぐ方法があればの話だが。
Quote from: bytemaster on August 04, 2010, 06:22:56 AM
まあ、現時点では次のようなシステムを作ることを止めるものは何もない：
AがBに1.00000001を送る BがAに1.00000000を返す
差し引きの結果はマイクロペイメントであり、処理手数料はかからない。私は上記と非常に似たことを行うシステムを作っている。実際のところ、「マイクロペイメント」システムはBTCブロックの外部で処理し、支払いを「集計」してから送信すべきだろう。
処理手数料の設計は素晴らしいと思う。各ノードは含めたいトランザクションを選り好みでき、したがって「含まれるまでの時間」はあなたの「提示」を受け入れるノードの数に正比例する。最悪の場合、自分一人のPCがブロックを作成できるまで待たなければならず、現時点では何週間もかかりうる！
実際、トランザクションを伝搬するノードに支払いを提供するのは合理的だと思う。ただし、それを「強制」し、不正なクライアントが手数料だけ集めて作業しないのを防ぐ方法があればの話だが。
…Bが最初にゼロBitcoinで始めた場合を除いて。その場合Bは行き詰まる。1.0を返送することで0.00000001 Bitcoinの「おつり」トランザクションが発生し、それが0.01BTCの手数料を引き起こすが、Bはそれを支払えない（1.0000000001しか持っていないから）。
この0.01 BTCのトランザクション手数料が「解決」している「ダストスパム」とは一体何なのか？ bytemasterが提案しているようなマイクロペイメント実装を妨げるため、害の方が大きいように思える。
ネットワークが既存のトランザクション量で苦しんでいるとは認識していない。 大量のトランザクションを送りたい人は、すでにx BTCを自分宛に何度も送ることで可能だ。
Quote from: Insti on August 04, 2010, 02:58:31 PM
この0.01 BTCのトランザクション手数料が「解決」している「ダストスパム」とは一体何なのか？ bytemasterが提案しているようなマイクロペイメント実装を妨げるため、害の方が大きいように思える。
ネットワークが既存のトランザクション量で苦しんでいるとは認識していない。 大量のトランザクションを送りたい人は、すでにx BTCを自分宛に何度も送ることで可能だ。
1ビットコインしか持っていない人でも100,000,000件のトランザクションを送ることができ、ネットワークを過負荷にする可能性がある。しかし、これは良い解決策ではない——制限が下げられても、大量のビットコインを保有している人がいるはずなので脆弱性は残る。
より良い解決策は、0.01未満のトランザクションの優先度を下げ、キュー内に10,000件（など）を超える場合は完全にドロップすることだろう。そうすれば、これらのトランザクションは他のトランザクションより遅く信頼性が低くなるが、動作はするし「本物の」トランザクションには干渉しない。
優先度は何ノードがそれを受け入れるかに完全に依存する。つまり、ノードの1%しか0.000001 btcのトランザクション手数料を受け入れなければ、次のブロックに含まれる確率は1%だ。すべてのノードが1 BTCのトランザクション手数料を受け入れれば、次のブロックに含まれる確率はほぼ100%だ。
Quote from: theymos on August 04, 2010, 03:43:56 PM
Quote from: Insti on August 04, 2010, 02:58:31 PM
この0.01 BTCのトランザクション手数料が「解決」している「ダストスパム」とは一体何なのか？ bytemasterが提案しているようなマイクロペイメント実装を妨げるため、害の方が大きいように思える。
ネットワークが既存のトランザクション量で苦しんでいるとは認識していない。 大量のトランザクションを送りたい人は、すでにx BTCを自分宛に何度も送ることで可能だ。
1ビットコインしか持っていない人でも100,000,000件のトランザクションを送ることができ、ネットワークを過負荷にする可能性がある。しかし、これは良い解決策ではない——制限が下げられても、大量のビットコインを保有している人がいるはずなので脆弱性は残る。
より良い解決策は、0.01未満のトランザクションの優先度を下げ、キュー内に10,000件（など）を超える場合は完全にドロップすることだろう。そうすれば、これらのトランザクションは他のトランザクションより遅く信頼性が低くなるが、動作はするし「本物の」トランザクションには干渉しない。 Quote from: Insti on August 04, 2010, 02:58:31 PM この0.01 BTCのトランザクション手数料が「解決」している「ダストスパム」とは一体何なのか？ bytemasterが提案しているようなマイクロペイメント実装を妨げるため、害の方が大きいように思える。
ネットワークが既存のトランザクション量で苦しんでいるとは認識していない。 大量のトランザクションを送りたい人は、すでにx BTCを自分宛に何度も送ることで可能だ。
1ビットコインしか持っていない人がすでに100,000,000件のトランザクションを送ることは可能で、自分宛にコインを繰り返し送ればいい。トランザクションの値が1であろうと0.00000001であろうと、何が違うのか？
Quote from: Insti on August 04, 2010, 02:58:31 PM
この0.01 BTCのトランザクション手数料が「解決」している「ダストスパム」とは一体何なのか？ bytemasterが提案しているようなマイクロペイメント実装を妨げるため、害の方が大きいように思える。
ネットワークが既存のトランザクション量で苦しんでいるとは認識していない。 大量のトランザクションを送りたい人は、すでにx BTCを自分宛に何度も送ることで可能だ。
Bitcoinは既存の決済手段で実用的なものよりも小さなトランザクションに対して実用的だ。マイクロペイメント範囲の上位と呼べるものを含むのに十分な小ささだ。しかし、任意に小さなマイクロペイメントに対して実用的であるとは主張していない。
手数料のルールは任意に複雑にできるのか？そしてサイズ制限はハードコードされているのか、完全にノード次第なのか？
より多く含めるとハッシュレートは落ちるのか？
Quote from: gavinandresen on August 04, 2010, 11:58:58 AM
Quote from: bytemaster on August 04, 2010, 06:22:56 AM
まあ、現時点では次のようなシステムを作ることを止めるものは何もない：
AがBに1.00000001を送る BがAに1.00000000を返す
差し引きの結果はマイクロペイメントであり、処理手数料はかからない。私は上記と非常に似たことを行うシステムを作っている。実際のところ、「マイクロペイメント」システムはBTCブロックの外部で処理し、支払いを「集計」してから送信すべきだろう。
処理手数料の設計は素晴らしいと思う。各ノードは含めたいトランザクションを選り好みでき、したがって「含まれるまでの時間」はあなたの「提示」を受け入れるノードの数に正比例する。最悪の場合、自分一人のPCがブロックを作成できるまで待たなければならず、現時点では何週間もかかりうる！
実際、トランザクションを伝搬するノードに支払いを提供するのは合理的だと思う。ただし、それを「強制」し、不正なクライアントが手数料だけ集めて作業しないのを防ぐ方法があればの話だが。
…Bが最初にゼロBitcoinで始めた場合を除いて。その場合Bは行き詰まる。1.0を返送することで0.00000001 Bitcoinの「おつり」トランザクションが発生し、それが0.01BTCの手数料を引き起こすが、Bはそれを支払えない（1.0000000001しか持っていないから）。 Quote from: bytemaster on August 04, 2010, 06:22:56 AM まあ、現時点では次のようなシステムを作ることを止めるものは何もない：
AがBに1.00000001を送る BがAに1.00000000を返す
差し引きの結果はマイクロペイメントであり、処理手数料はかからない。私は上記と非常に似たことを行うシステムを作っている。実際のところ、「マイクロペイメント」システムはBTCブロックの外部で処理し、支払いを「集計」してから送信すべきだろう。
処理手数料の設計は素晴らしいと思う。各ノードは含めたいトランザクションを選り好みでき、したがって「含まれるまでの時間」はあなたの「提示」を受け入れるノードの数に正比例する。最悪の場合、自分一人のPCがブロックを作成できるまで待たなければならず、現時点では何週間もかかりうる！
実際、トランザクションを伝搬するノードに支払いを提供するのは合理的だと思う。ただし、それを「強制」し、不正なクライアントが手数料だけ集めて作業しないのを防ぐ方法があればの話だが。
aとbが両方とも1 BTCで始めて、単一のトランザクションで2つの入力と2つの出力を使って0.0001を転送することに合意すれば、aを0.9999に、bを1.0001に変更できる。ネットワークの他のノードはそのトランザクションを受け入れるだろう。
唯一の障壁は、トランザクションを作成する人が通常は異なるウォレットの両方の入力の秘密鍵を必要とすることだ。トランザクションを作成する人が不正をする可能性がある。
Quote from: satoshi on August 04, 2010, 04:25:36 PM
Quote from: Insti on August 04, 2010, 02:58:31 PM
この0.01 BTCのトランザクション手数料が「解決」している「ダストスパム」とは一体何なのか？ bytemasterが提案しているようなマイクロペイメント実装を妨げるため、害の方が大きいように思える。
ネットワークが既存のトランザクション量で苦しんでいるとは認識していない。 大量のトランザクションを送りたい人は、すでにx BTCを自分宛に何度も送ることで可能だ。
Bitcoinは既存の決済手段で実用的なものよりも小さなトランザクションに対して実用的だ。マイクロペイメント範囲の上位と呼べるものを含むのに十分な小ささだ。しかし、任意に小さなマイクロペイメントに対して実用的であるとは主張していない。
なぜ実用的ではないのか？良いマイクロペイメントシステムは何千ものトランザクション（例えばパケットごとに1つ）を生成することを避けるべきだが、bytemasterのお釣りのアイデアが間違っているということにはならない： それは素晴らしいユースケースに思える。さらに、llamaが言ったように、トランザクション手数料の固定部分は、そのトランザクションをブロックに含めるための実際のコストを常に反映すべきだ。では、ダストスパム対策のより知的で痛みの少ない実装方法はあるだろうか？
現行のシステムは問題なく機能していると思う。マイクロペイメントシステムを実装したければ、自分の小さなトランザクションを含めるのに十分なノードをホストし、十分な処理能力を提供する必要がある。ノードがマイクロペイメントトランザクションを受け入れたり転送したりすることを望まないなら、それを要求する理由はない。
本当の問題は、正当な自動マイクロペイメントシステムでさえ、クレジットカードシステムが現在使用しているよりも多くのトランザクションを導入してbitcoinを過負荷にする可能性があることだ。その結果、ブロックサイズが巨大になる可能性がある。
私のユースケースでは、P2Pシステムで優先ダウンロードに対価を支払う。1つの「torrent」ファイルに100,000人全員がシードとダウンロードをしていると仮定する。簡単に1分あたり100,000のマイクロペイメントが発生し得る。もちろん、2つのクライアント間でアップロード!=ダウンロードの場合にのみBTCを使用すればよい。
分散型であるため「スパム」と正当な利用を区別する簡単な方法はない。1回あたり1+ BTCを転送し、残高が0.01を超えたらお釣りを返す私のソリューションでさえ、大規模なトランザクション膨張を引き起こし得る。
個別のトランザクション処理の「コスト」は低い（.00001 BTC）かもしれないが、自動支払い交渉/入札システムを使う数百万のユーザーからのそれらすべての小さなトランザクションを処理するコストは、すべての着信トランザクションをリッスンすることさえ不可能にするだろう。
マイクロペイメントについての良い部分を書き忘れた。現時点では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になる。自動的に追加すべきだと思う。他の多くの種類のサービスが自動的に追加する手数料と比べれば些細なものだ。
Quote from: FreeMoney on August 04, 2010, 07:30:32 PM
手数料のルールは任意に複雑にできるのか？そしてサイズ制限はハードコードされているのか、完全にノード次第なのか？
より多く含めるとハッシュレートは落ちるのか？
いいえ、全くしない。
Quote from: bytemaster支払いは一般的に前払いで、例えば一度に1 BTCを支払い、接続が閉じられた時にお釣りが返されます。このルールでは、追加のトランザクションなしに単純な「検索クエリ」の支払いは不可能になります。 代替案の一つは、まとめ払いシステムを使うことだ。例えば一度に1000ページ、画像、ダウンロード、検索などを支払う。1000ページを使い切ったら、さらに1000ページ分を支払う。1ページしか使わなければ、使わないかもしれない999ページ分が残るが、1000ページあたりのコストはまだ小さいので大した問題ではない。
あるいは日単位で支払うこともできる。特定の日にサイトに初めてアクセスした時、24時間分のアクセスを支払う。
1000単位や日単位は消費者にとっても理解しやすいかもしれない。アイテム単位だと加算が速すぎないか心配するが、24時間無制限ならコストがわかる。あるいは1000が十分な量に思えれば、おそらく使い切らないだろうと思って、クリックするたびにコストがかかることを心配しなくて済む。
Quote from: bytemaster on August 05, 2010, 03:39:19 PM
現行のシステムは問題なく機能していると思う。マイクロペイメントシステムを実装したければ、自分の小さなトランザクションを含めるのに十分なノードをホストし、十分な処理能力を提供する必要がある。ノードがマイクロペイメントトランザクションを受け入れたり転送したりすることを望まないなら、それを要求する理由はない。
本当の問題は、正当な自動マイクロペイメントシステムでさえ、クレジットカードシステムが現在使用しているよりも多くのトランザクションを導入してbitcoinを過負荷にする可能性があることだ。その結果、ブロックサイズが巨大になる可能性がある。
私のユースケースでは、P2Pシステムで優先ダウンロードに対価を支払う。1つの「torrent」ファイルに100,000人全員がシードとダウンロードをしていると仮定する。簡単に1分あたり100,000のマイクロペイメントが発生し得る。もちろん、2つのクライアント間でアップロード!=ダウンロードの場合にのみBTCを使用すればよい。
分散型であるため「スパム」と正当な利用を区別する簡単な方法はない。1回あたり1+ BTCを転送し、残高が0.01を超えたらお釣りを返す私のソリューションでさえ、大規模なトランザクション膨張を引き起こし得る。
個別のトランザクション処理の「コスト」は低い（.00001 BTC）かもしれないが、自動支払い交渉/入札システムを使う数百万のユーザーからのそれらすべての小さなトランザクションを処理するコストは、すべての着信トランザクションをリッスンすることさえ不可能にするだろう。
それを実装する方法がわからない。ブロック作成者へのトランザクション手数料は、追加サイズなしでトランザクション手数料を含める特別なトリックを使っている。各トランザクション手数料に対してトランザクションがあるとしたら、トランザクション手数料のトランザクションに対するトランザクション手数料はどうなるのだろうか？
Quote from: satoshi on August 05, 2010, 04:39:58 PM
Quote from: bytemaster on August 05, 2010, 03:39:19 PM
この問題の唯一の解決策は、トランザクションのブロードキャストを「無料でなくする」ことだ。つまり、含めてほしいなら私に支払わなければならない。最終的な結果として、各クライアントはブロックに含める人だけでなく、トランザクションを送信する相手の他のクライアントにも支払う必要がある。このようにして経済法則が働き、トランザクションブロードキャストシステムにただ乗りする人はいなくなる。
それを実装する方法がわからない。ブロック作成者へのトランザクション手数料は、追加サイズなしでトランザクション手数料を含める特別なトリックを使っている。各トランザクション手数料に対してトランザクションがあるとしたら、トランザクション手数料のトランザクションに対するトランザクション手数料はどうなるのだろうか？
トランザクション手数料のトランザクションは、メインのトランザクションの完全に予測可能な結果として設計され、メインのトランザクション処理の手数料には手数料トランザクションの必要性も考慮されるだろう。つまり、手数料トランザクションは自身の手数料を含むことになる。したがって、これは管理可能な問題のようだ。
ByteCoin
現在、トランザクション手数料のアドレスは「空白」のままで、ブロック生成者が記入する。 今度はブロック構築を依頼する相手のアドレスを記入する。
送信手数料 <= ブロック統合手数料の場合、誰もトランザクションを利益的に転送できないため、自分自身でブロックを生成する必要がある。
Quote from: bytemaster on August 05, 2010, 04:46:52 PM
現在、トランザクション手数料のアドレスは「空白」のままで、ブロック生成者が記入する。 今度はブロック構築を依頼する相手のアドレスを記入する。
送信手数料 <= ブロック統合手数料の場合、誰もトランザクションを利益的に転送できないため、自分自身でブロックを生成する必要がある。
一人だけにブロックの構築を依頼するなら、何日もかかる可能性がある。ああ、各ノードに手数料を書き込んだ異なるバリエーションを送るということか？
現在の仕組みでは、これを構築した人が手数料を得る。
必要であれば、トランザクションブロードキャストにBitTorrent式の相互主義を導入できるだろう。手数料付きトランザクションを私にリレーしてくれなければ、あなたにもリレーしない。ただし、実際には問題にならないだろう。正しくリレーする1つのノードがあれば、貪欲にリレーしない他の7つのノードを相殺できる。
つまり、Bitcoinネットワーク全体をDDoS攻撃する能力は、ネットワーク接続やノードの数ではなく、BTCの購買力によってのみ制限されるということか？
ところで、いつかネットワークをテストしないか？ 既知のアドレスのリストに小さなトランザクションを送信するプロセスを自動化するのは簡単だ。 ネットワークを酷使して、影響を正確に把握しよう。
他のユーザーに注意喚起すべきだと思うが…
Quote from: throughput on August 10, 2010, 10:13:30 AM
つまり、Bitcoinネットワーク全体をDDoS攻撃する能力は、ネットワーク接続やノードの数ではなく、BTCの購買力によってのみ制限されるということか？
ところで、いつかネットワークをテストしないか？ 既知のアドレスのリストに小さなトランザクションを送信するプロセスを自動化するのは簡単だ。 ネットワークを酷使して、影響を正確に把握しよう。
他のユーザーに注意喚起すべきだと思うが…
テストネットワークを使うべきだ。
Quote from: Insti on August 10, 2010, 02:53:41 PM
Quote from: throughput on August 10, 2010, 10:13:30 AM
ところで、いつかネットワークをテストしないか？ 既知のアドレスのリストに小さなトランザクションを送信するプロセスを自動化するのは簡単だ。 ネットワークを酷使して、影響を正確に把握しよう。
他のユーザーに注意喚起すべきだと思うが…
テストネットワークを使うべきだ。 Quote from: throughput on August 10, 2010, 10:13:30 AM つまり、Bitcoinネットワーク全体をDDoS攻撃する能力は、ネットワーク接続やノードの数ではなく、BTCの購買力によってのみ制限されるということか？
ところで、いつかネットワークをテストしないか？ 既知のアドレスのリストに小さなトランザクションを送信するプロセスを自動化するのは簡単だ。 ネットワークを酷使して、影響を正確に把握しよう。
他のユーザーに注意喚起すべきだと思うが…
テストネットワークはテスト規模だ。
うーん、次回は他のやつらが本番ネットワークを酷使する前に許可を求めてくるとは思えないがな。 彼らはただやるだけだ。
こんな単純な侵入に脆弱であれば、Bitcoinは使い物にならないと確信している。 現実の脅威に対して持続可能であることを証明すべきだ。俺みたいにな Grin
もう誰かが実験したかもしれないな？
できる限りblk*.datファイルを小さく保てると良いな。
最終的な解決策は、大きくなっても気にしないことだ。
でも今はまだ小さいうちに、新しいユーザーがより早く始められるよう小さく保つのは良いことだ。クライアント専用モードを最終的に実装すれば、それはあまり問題にならなくなる。
トランザクション手数料についてはまだ作業が必要だ。フラッドが起きた場合でも、0.01のトランザクション手数料を支払うことで、キューを飛ばして次のブロックにトランザクションを入れることができるだろう。ただし、そのオプションをUIに追加する時間がまだなかった。
規模に関わらず、テストネットワークも同様の反応をするが、帯域幅の無駄と迷惑ははるかに少なくなる。