現行のシステムは問題なく機能していると思う。マイクロペイメントシステムを実装したければ、自分の小さなトランザクションを含めるのに十分なノードをホストし、十分な処理能力を提供する必要がある。ノードがマイクロペイメントトランザクションを受け入れたり転送したりすることを望まないなら、それを要求する理由はない。
本当の問題は、正当な自動マイクロペイメントシステムでさえ、クレジットカードシステムが現在使用しているよりも多くのトランザクションを導入して bitcoin を過負荷にする可能性があることだ。その結果、ブロックサイズが巨大になる可能性がある。
私のユースケースでは、P2P システムで優先ダウンロードに対価を支払う。1 つの「torrent」ファイルに 100,000人全員がシードとダウンロードをしていると仮定する。簡単に 1分あたり 100,000 のマイクロペイメントが発生し得る。もちろん、2 つのクライアント間でアップロード!=ダウンロードの場合にのみ BTC を使用すればよい。
分散型であるため「スパム」と正当な利用を区別する簡単な方法はない。1回あたり 1+ BTC を転送し、残高が 0.01 を超えたらお釣りを返す私のソリューションでさえ、大規模なトランザクション膨張を引き起こし得る。
個別のトランザクション処理の「コスト」は低い（.00001 BTC）かもしれないが、自動支払い交渉/入札システムを使う数百万のユーザーからのそれらすべての小さなトランザクションを処理するコストは、すべての着信トランザクションをリッスンすることさえ不可能にするだろう。
この問題の唯一の解は、トランザクションのブロードキャストを「無料ではない」 ようにすることだ。つまり、私に取り込ませたいなら、私に支払いをしてもらう必要がある。結果として (ネットワーク的にも文字通りも) 、各クライアントはトランザクションを送る相手にも支払いをする必要があり、ブロックに取り込んだ者だけに支払うのではなくなる。こうすれば経済原理が働き、誰もトランザクションのブロードキャストシステムにただ乗りできなくなる。
これが意味するのは、あなたが支払いをした受信先のノードがあなたのトランザクションをブロックに組み込もうと試みて成功するまで、支払いの通知すら受け取れないかもしれないということだ。つまり 0/未確認の表示すら出ず、ブロックに入って初めて、組み込みを試みるよう支払いを受けていない者にもそのトランザクションの存在が知られることになる。
この構造は pay-to-ip 型のシステムを助長する。受取人側が、その取引を取り込んでもらうための支払いを負担する形になるからだ。受取人は自分でビットコイン生成を回すか、自分の代わりに回してくれる相手にトランザクションを送るための支払いをするかのどちらかになる。