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のデータが書き込まれていた。
もっと多くの人がネットワーク上に分散して参加する別のテストをやって、潜在的な問題を洗い出す価値があるかもしれない。
ネットワークは何事もなかったかのように処理したので、これはいい結果だ。クライアントはおおむね指示どおり、期待どおりに動いたが、データベースには性能の問題があるかもしれない。
今思いつくのは以上だ。