Quote from: zipslack on November 28, 2010, 08:53:00 AM
Quote from: RHorning on November 26, 2010, 07:17:25 PM
だからこそ、通常のディストリビューションに含めるのではなく、新規ユーザー向けの別のダウンロード（ただし強く推奨）にすべきだと提案しているのだ。
すまない、誤解していた。
Quote from: jgarzik on November 28, 2010, 02:33:29 AM
ジェネシスブロックからブロック74000までのハッシュがBitcoinにハードコード（コンパイル）されているので、ブロックデータベースの圧縮zipファイルをどこからでも自動ダウンロードし、展開・検証して実行を開始できない理由はない。
チェックポイントのことだと思うが、もしそうなら、私の理解では、チェックポイントはダウンロードされたブロックの検証時にのみ適用される。blk0001.datとblkindex.datの内容がクライアントによってチェックされることは決してない。クライアントはそれらのファイルに書き込む前にデータをチェックするよう設計されているからだ。サトシがこのスレッドで示したように、
Quote from: satoshi on November 25, 2010, 05:51:39 PM
自分で検証とインデックス作成を行うことが、インデックスデータの安全性を確認する唯一の方法だ。信頼できないソースからblk0001.datとblkindex.datをコピーすると、そのすべての内容を信頼できるかどうかを知る方法がない。
それは正確ではない。「-checkblocks」（CheckBlock()）はblk0001.dat / blkindex.datの内容に対してかなりの数のチェックを実行する。AcceptBlock()はコンテキストを追加してもう少し多くのことをするが、大した差ではない。ただ、今はこの点は置いておこう。
もっと重要な点として見落としているのは、検証の省略を提案している人は誰もいないということだ。Bitcoinのコードは信頼できないblk0001.datデータの検証とインデックス作成を十分にこなせる。blkindex.datが存在しない場合に合理的に動作するよう、いくつかの修正が必要なだけだ。
提案は単純に、バルクデータ転送用に設計されていないプロトコル（Bitcoin P2P）を使って大量の非圧縮データをダウンロードするのをやめよう、ということだ。
クライアントはblk0001.datの暗号学的な完全性を信頼できないソースから検証する能力を明らかに持っている。なぜなら、ネットワーク経由で受信したブロックに対してそれを行っており、blk0001.datには……信頼できないソースからネットワーク経由で受信したシリアライズされたブロックが含まれているからだ。
blk0001.datのファイル位置データをProcessBlock()に渡し、下流の呼び出し先AcceptBlock()でWriteToDisk()のストレージ呼び出しをスキップするだけで、それほど難しくないはずだ。