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