Quote from: RHorning on November 26, 2010, 07:17:25 PM
Quote from: zipslack on November 26, 2010, 06:08:40 PM
Quote from: RHorning on November 26, 2010, 05:42:17 PM
Quote from: jgarzik on November 26, 2010, 01:47:43 AM
Quote from: satoshi on November 25, 2010, 05:51:39 PM
時間がかかるのはダウンロードではなく、検証とインデックス作成だ。
これは多くの初心者ユーザーには当てはまらない。「まあ、90000ブロックすべてを取得するのに数時間かかりましたが、最終的に到着しました」と言うような人たちだ（今日IRCで新規ユーザーからの引用）。
同意する。アーカイブに圧縮すると、blk0001.datは約36MBになる。
ダウンロードではなく検証が最も高い体験のばらつきを持っている。初回ユーザーはソフトウェアが実際に使えるようになるまで30分から数時間の遅延を経験する。一部のP2Pノードは非常に遅い場合がある。エンドユーザーの帯域幅は低く、不安定で、高価かもしれない。ファイアウォールはしばしば問題になる。
公式Bitcoinにblk0001.datを同梱するだけで、新しいBitcoinユーザーが経験し続ける複数の問題を解消できる。
個人的な提案としては、ブロックデータを別ダウンロードにするが、強く推奨する形がよいと思う。Windowsユーザーやこの種のブロックファイルを適切なディレクトリに配置できないコンピュータに詳しくないユーザーのインストールを簡素化したいなら、正式なインストールファイルを作成して適切な場所に配置するのがより「ユーザーフレンドリー」だろうが、実際に必要なのはブロックデータだけだ。
この目的は主に、新バージョンにアップデートする際に同じブロックデータを繰り返しダウンロードしなくて済むようにすることだ。ブロックデータは定義上、時間とともに増大していく。
あなたの環境がどうかは分からないが、自分の場合、Bitcoinをアップグレードする際にブロックを再ダウンロードする必要はない。アップグレード前の状態からそのまま続行される。 Quote from: RHorning on November 26, 2010, 05:42:17 PM Quote from: jgarzik on November 26, 2010, 01:47:43 AM
Quote from: satoshi on November 25, 2010, 05:51:39 PM
時間がかかるのはダウンロードではなく、検証とインデックス作成だ。
これは多くの初心者ユーザーには当てはまらない。「まあ、90000ブロックすべてを取得するのに数時間かかりましたが、最終的に到着しました」と言うような人たちだ（今日IRCで新規ユーザーからの引用）。
同意する。アーカイブに圧縮すると、blk0001.datは約36MBになる。
ダウンロードではなく検証が最も高い体験のばらつきを持っている。初回ユーザーはソフトウェアが実際に使えるようになるまで30分から数時間の遅延を経験する。一部のP2Pノードは非常に遅い場合がある。エンドユーザーの帯域幅は低く、不安定で、高価かもしれない。ファイアウォールはしばしば問題になる。
公式Bitcoinにblk0001.datを同梱するだけで、新しいBitcoinユーザーが経験し続ける複数の問題を解消できる。
個人的な提案としては、ブロックデータを別ダウンロードにするが、強く推奨する形がよいと思う。Windowsユーザーやこの種のブロックファイルを適切なディレクトリに配置できないコンピュータに詳しくないユーザーのインストールを簡素化したいなら、正式なインストールファイルを作成して適切な場所に配置するのがより「ユーザーフレンドリー」だろうが、実際に必要なのはブロックデータだけだ。
この目的は主に、新バージョンにアップデートする際に同じブロックデータを繰り返しダウンロードしなくて済むようにすることだ。ブロックデータは定義上、時間とともに増大していく。
それがまさにポイントだ。ブロックがアップデートに含まれていれば、すでにネットワーク経由で取得済みのブロックも含まれることになる。だからこそ、通常のディストリビューションに含めるのではなく、新規ユーザー向けの別のダウンロード（ただし強く推奨）にすべきだと提案しているのだ。
すまない、誤解していた。
Quote from: jgarzik on November 28, 2010, 02:33:29 AM
IRCの別の新規ユーザー（今回はLinux）が、1ブロックあたり4秒の速度でダウンロードしていた——推定合計ダウンロード時間は約4日間。
このスレッドの他のコメント者は、アップグレードするユーザーにはブロックデータベースは不要だと正しく指摘している……しかし、新規ユーザーの初期ブロックダウンロード体験を改善するために何かをする必要がある。データベースをいくら改善しても……さまざまな理由でブロックをゆっくり提供するピアは残る。
Genesisブロックからブロック74000までのハッシュがBitcoinにハードコード（コンパイル）されているので、ブロックデータベースの圧縮zipファイルをどこからでも自動的にダウンロードし、展開し、検証し、実行を開始できない理由はない。
チェックポイントのことだと思うが、もしそうなら、私の理解では、チェックポイントはダウンロードされたブロックの検証時にのみ適用される。blk0001.datとblkindex.datの内容がクライアントによってチェックされることは決してない。クライアントはそれらのファイルに書き込む前にデータをチェックするよう設計されているからだ。サトシがこのスレッドで示したように、
Quote from: satoshi on November 25, 2010, 05:51:39 PM
時間がかかるのはダウンロードではなく、検証とインデックス作成だ。
帯域幅の点では、アーカイブをダウンロードするよりも効率的だ。Bitcoinはblk0001.datのデータのみをダウンロードし、現在55MBで、blkindex.dat（47MB）は自分で構築する。blkindex.datの構築がすべてのディスクアクティビティの原因だ。
ブロックのダウンロード中は、500ブロックごとにのみデータベースをディスクにフラッシュする。ブロック数が??499や??999で一時停止するのが見えるかもしれない。それがフラッシュしている時だ。
自分で検証とインデックス作成を行うことが、インデックスデータの安全性を確保する唯一の方法だ。信頼できないソースからblk0001.datとblkindex.datをコピーした場合、その中身すべてを信頼できるかどうか知る方法はない。
Berkeley DBの設定を調整して、キャッシュメモリを有効化または増加できるかもしれない。