Quote from: satoshi on November 28, 2010, 05:13:01 PM
他の議論にもかかわらず、現在の次のステップは： 引用：誰かが異なるBerkeley DB設定で実験して、ダウンロードを大幅に速くするものがないか確認すべきです。大幅な改善が見つかれば、詳細を詰めることができます。 特に、読み取りキャッシュを増やすと大いに役立つのではないかと思う。
Quote from: jgarzik on November 28, 2010, 02:33:29 AM
IRCの別の新規ユーザー（今回はLinux）が、1ブロックあたり4秒の速度でダウンロードしていた——推定合計ダウンロード時間は約4日間。
このスレッドの他のコメント者は、アップグレードするユーザーにはブロックデータベースは不要だと正しく指摘している……しかし、新規ユーザーの初期ブロックダウンロード体験を改善するために何かをする必要がある。データベースをいくら改善しても……さまざまな理由でブロックをゆっくり提供するピアは残る。
Genesisブロックからブロック74000までのハッシュがBitcoinにハードコード（コンパイル）されているので、ブロックデータベースの圧縮zipファイルをどこからでも自動的にダウンロードし、展開し、検証し、実行を開始できない理由はない。
それなら何かもっと具体的な問題があった。通常の初回ダウンロード時間によるものではない。より詳細がなければ診断できない。遅いダウンロードが原因だったなら、次のブロックブロードキャストでより速いソースに切り替わるはずの10〜20分後に速くなったか？debug.logに手がかりがあるかもしれない。インターネット接続はどのくらい速いか？一貫して遅かったのか、ある時点で遅くなっただけか？
引用：ジェネシスブロックからブロック74000までのハッシュがbitcoinにハードコード（コンパイル）されているので、ブロックデータベースの圧縮zipファイルをどこからでも自動的にダウンロードし、展開し、検証し、実行を開始できない理由はないはずです。 74000チェックポイントは保護に十分ではなく、ダウンロードがすでに74000を過ぎていれば何もしない。-checkblocksはより多くのことをするが、依然として簡単に突破される。zipファイルの提供者を信頼しなければならない。
「検証する」ステップがあれば、現在の通常の初回ダウンロードと同じくらい時間がかかるだろう。データダウンロードではなく、インデックス作成がボトルネックなのだ。
Quote from: jgarzik on November 28, 2010, 07:33:55 AM
Quote from: tyler on November 28, 2010, 07:23:04 AM Quote from: jgarzik on November 28, 2010, 02:33:29 AM
新規ユーザーの初期ブロックダウンロード体験を改善するために何かをする必要がある。
何かをする必要がある。ブロックチェーンは来年かそこらで巨大になるよね？
はい、その通り。
おそらくある時点でブロックヘッダーのみをダウンロードする軽量クライアントが登場するだろうが、それでも数十万のヘッダーがある……
ヘッダあたり80バイトでインデックス作成作業なし。1分程度で済むかもしれない。
引用：一括データ転送用に設計されていないプロトコル（bitcoin P2P）を使用した非圧縮データ。 データの大部分はハッシュ、鍵、署名で、圧縮不可能だ。
初回ダウンロードの速度は、プロトコルの一括データ転送レートを反映していない。制限要因はダウンロード中のインデックス作成だ。
申し訳ないが、これらのユーザーのディスクとCPUは100%ではなかった。多くのユーザーにとってボトルネックがデータベースやインデックスではないことは明らかだ。
bzip2は33%の圧縮率を提供し、ダウンロードから数メガバイトを節約する：
Code:[jgarzik@bd data]$ tar cvf /tmp/1.tar blk0001.dat blk0001.dat
[jgarzik@bd data]$ tar cvf /tmp/2.tar blk*.dat blk0001.dat blkindex.dat
[jgarzik@bd data]$ bzip2 -9v /tmp/[12].tar /tmp/1.tar: 1.523:1, 5.253 bits/byte, 34.34% saved, 55439360 in, 36402074 out. /tmp/2.tar: 1.512:1, 5.291 bits/byte, 33.86% saved, 103690240 in, 68577642 out.
33%を「圧縮不能」とは呼ばない