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