IRC チャンネルでスケーラビリティやスパムトランザクションによるサービス拒否攻撃について憶測が飛び交っていたので、テストを行うのが良いと思いました。
私の Linux マシン 2 台に簡単な bitcoind スクリプトを設定し、3 台目のマシンに対してできるだけ速く 1000件の少額トランザクションを送信しました。
IRC で実行すべきでない明確な理由があるか尋ねたところ、良いアイデアだという賛成意見が 1 つと、まずここで聞くべきだという慎重な意見が 1 つありました。私は思い切って実行することにしました。
スクリプトはループの残りステップ数のカウントダウンと、bitcoind の sendtoaddress コマンドの出力（通常は単に「sent」）を表示するだけのものでした。
両方とも最初は速く動いていましたが、約 600件のトランザクションが送信された頃から、両方の送信側が目に見えて遅くなり始めました。一方がもう一方より 3〜4倍速かったのですが、これは CPU が速いためだと思います。最初はネットワークの過負荷を防ぐためにクライアントがスロットリングしているのかと思いましたが、それは単なる推測でした。後で、古いディスク上のデータベースが少し遅くなっているのではないかという結論に至りました。
その後、一方のマシンが突然速くなったように見えました。しかし実際にはそうではありませんでした。エラーが発生しており、bitcoind デーモンが停止していたのです。調査したところ、.bitcoin のドライブが満杯になっていたことが判明したので、プログラムが停止したのは仕方ありません。
もう一方のマシンはその頃にはかなり遅くなっており、目視で 1 トランザクションあたり約 5秒程度でした。最終的に約 50分後にエラーなく完了しました。
クラッシュしたマシンはディスク容量を追加した後すぐに再起動し、424件のトランザクションしか送信していなかったことが判明しました。つまり、最初のベンチマークとして 50分間で 1424件のトランザクションということになります。さらに多くの処理は容易に可能でしょう。
速度低下の主な原因は.bitcoin/database ディレクトリだったと思います。ディスク容量が不足したマシンでは約 184MB、1000件のトランザクションを完了したマシンでは 1341MB のデータが書き込まれていました。
より多くの人がネットワーク上に分散して参加する別のテストを行い、潜在的な問題を洗い出す価値があるかもしれません。
ネットワークは何事もなかったかのように処理したので、これは肯定的な結果です。クライアントは概ね指示通り期待通りに動作しましたが、データベースにパフォーマンスの問題がある可能性があります。
今思いつくのは以上です。