他の議論にもかかわらず、現在の次のステップは：
サトシ・ナカモトの投稿（2010年11月26日 17:32 UTC）誰かが異なるBerkeley DB設定で実験して、ダウンロードを大幅に速くするものがないか確認すべきです。大幅な改善が見つかれば、詳細を詰めることができます。
特に、読み取りキャッシュを増やすと大いに役立つのではないかと思う。
ジェフ・ガージックの投稿（2010年11月27日 17:33 UTC）IRC の別の新規ユーザー（今回は Linux）が、1 ブロックあたり 4秒の速度でダウンロードしていた——推定合計ダウンロード時間は約 4日間。
それなら何かもっと具体的な問題があった。通常の初回ダウンロード時間によるものではない。より詳細がなければ診断できない。遅いダウンロードが原因だったなら、次のブロックブロードキャストでより速いソースに切り替わるはずの 10〜20分後に速くなったか？debug.log に手がかりがあるかもしれない。インターネット接続はどのくらい速いか？一貫して遅かったのか、ある時点で遅くなっただけか？
ジェフ・ガージックの投稿（2010年11月27日 17:33 UTC）Genesis ブロックからブロック 74000 までのハッシュが Bitcoin にハードコード（コンパイル）されているので、ブロックデータベースの圧縮 zip ファイルをどこからでも自動的にダウンロードし、展開し、検証し、実行を開始できない理由はない。
74000 チェックポイントは保護に十分ではなく、ダウンロードがすでに 74000 を過ぎていれば何もしない。-checkblocks はより多くのことをするが、依然として簡単に突破される。zip ファイルの提供者を信頼しなければならない。
「検証する」ステップがあれば、現在の通常の初回ダウンロードと同じくらい時間がかかるだろう。データダウンロードではなく、インデックス作成がボトルネックなのだ。
ジェフ・ガージックの投稿（2010年11月27日 22:33 UTC）おそらくある時点でブロックヘッダーのみをダウンロードする軽量クライアントが登場するだろうが、それでも数十万のヘッダーがある……
ヘッダーあたり 80 バイトでインデックス作成作業なし。1分程度で済むかもしれない。
ジェフ・ガージックの投稿（2010年11月27日 22:33 UTC）一括データ転送用に設計されていないプロトコル（bitcoin P2P）を使用した非圧縮データ。
データの大部分はハッシュ、鍵、署名で、圧縮不可能だ。
初回ダウンロードの速度は、プロトコルの一括データ転送レートを反映していない。制限要因はダウンロード中のインデックス作成だ。