7年前の遅いドライブでテストしたが、帯域幅とCPUは明らかにボトルネックではなかった。初回ダウンロードは1時間20分かかった。
それよりはるかに長く、特に24時間もかかるなら、非常に遅いノードからダウンロードしているか、接続速度が約15KB/秒（120kbps）よりかなり遅いか、何か他に問題があるはずだ。そのような場合にボトルネックが何であるように見えるかわかると良いのだが。
最新のブロックが送信される10分程度ごとに、より速いノードに切り替える機会があるはずだ。最新のブロックがブロードキャストされると、他のノードに次の500ブロックを要求し、最も速く送信するノードからダウンロードを継続する。少なくとも、そのように動作するはずだ。
ジェフ・ガージックの投稿（2010年11月26日02:07 UTC）サトシ・ナカモトの投稿（2010年11月25日17:51 UTC）Berkeley DBの設定を調整して、キャッシュメモリーを有効化または増加できるかもしれない。
ダウンロード中に、ACID (
http://en.wikipedia.org/wiki/ACID)プロパティのどれが必要だろうか？
より多くの読み取りキャッシュが役立つかもしれない。インデックスを作成するためにblk0001.datとblkindex.dat全体をランダムに読み取る必要がある。ファイルがメモリーより小さいと仮定することはできないが、現在はまだそうだ。ほとんどの依存関係が最近のものなので、キャッシュは効果的だろう。
誰かが異なるBerkeley DB設定で実験して、ダウンロードを大幅に速くするものがないか確認すべきだ。大幅な改善が見つかれば、詳細を詰めることができる。
ジェフ・ガージックBDBレコードの追加はチェックポイントを発行するまで単にログファイルへの追記だ。チェックポイントがメインデータベースファイルを更新する。
500ブロックごとにチェックポイントしている。