RFC: リリースtarballにブロックチェーン1-74000を同梱する？

26 件のメッセージ BitcoinTalk ジェフ・ガージック, サトシ・ナカモト, ウラジミール・ファン・デル・ラーン, RHorning, MrFlibble, zipslack, tyler, jgarzik, MoonShadow, Theymos 2010年11月24日 — 2010年12月1日

ジェフ・ガージック（Jeff Garzik） 2010年11月24日原文 · 個別ページ

ビットコインがブロックチェーン情報を格納するblk0001.datは、Windows、Linux、32ビットおよび64ビット間で互換性があるようである。

であれば、各リリースにブロック1-74000を同梱することで、新規ユーザーの時間を節約できるのではないか？

ローカルファイルのインデックス作成と検証は、P2P経由ですべてのブロックをダウンロードするよりも高速で、ネットワークリソースの消費も少ないと考えられる。

ウラジミール・ファン・デル・ラーン（laanwj） 2010年11月25日原文 · 個別ページ

えっ、P2Pは1つのソースではなく多くのユーザーから同時にダウンロードできるから、より高速なはずではないか？（一部のゲーム会社がアップデートの配布にBitTorrentを使っている理由でもある）

RHorning 2010年11月25日原文 · 個別ページ

これについては複雑な思いがある。問題の一部は、Source Forgeという形でネットワークホスティングサービスの無料財が存在すると認識されていることだ。

もう一つの問題は、ノード間のネットワーク帯域幅もまた無料財であるということだ。

ブロックのダウンロードのためのネットワーク帯域幅はどちらにしても変わらないが、「オンライン」になろうとしている新しいクライアントが完全なブロックチェーンを取得するとBitcoinネットワークを通じて大量のブロックを吸い上げ、それらのノードに接続している誰にでも影響する。これが帯域幅に対して「課金」を始めることが非常に有用だと思う理由の一つだ。

これは複雑な問題に対するシンプルな解決策だが、すべての問題を解決するわけではない。

Quote from: witchspace on November 25, 2010, 01:37:13 PM

えっ、P2Pは1つのソースではなく多くのユーザーから同時にダウンロードできるから、より高速なはずではないか？（一部のゲーム会社がアップデートの配布にBitTorrentを使っている理由でもある）

本質的にP2Pチャネルを通じて分散されているものを、従来のクライアント・サーバー配布モデルに入れるのは非常に奇妙に思える。問題は、新しいクライアントがブロックチェーン全体を要求し、そのチェーンを持つまで「マイニング」や新しい取引の確認に参加できないことだ。その問題を解決しよう。それがより大きな問題だ。

もう一つの問題は、ソフトウェアを更新するだけなのにクライアントにこれらのブロックを含めるのは帯域幅の無駄に思えることだ。無料財だからといって、この方法をとることに他の結果がないことを意味しない。

ウラジミール・ファン・デル・ラーン（laanwj） 2010年11月25日原文 · 個別ページ

確かに、クライアントにデータを同梱するのは単なる応急処置だ。

Bitcoin P2Pプロトコルが大量のブロック転送で非常に非効率である主な理由は、HDD同期が行われているからだろう。初回ダウンロードではこれを保留にするか、ブロック[0..last-10000]についてはプロトコルをよりBitTorrent的にすべきだ。それらは基本的に確定しているのだから。

サトシ・ナカモト（Satoshi Nakamoto） 2010年11月25日原文 · 個別ページ

時間がかかるのはダウンロードではなく、検証とインデックス作成だ。

帯域幅の点では、アーカイブをダウンロードするよりも効率的だ。Bitcoinはblk0001.datのデータのみをダウンロードし、現在55MBで、blkindex.dat（47MB）は自分で構築する。blkindex.datの構築がすべてのディスクアクティビティの原因だ。

ブロックのダウンロード中は、500ブロックごとにのみデータベースをディスクにフラッシュする。ブロック数が??499や??999で一時停止するのが見えるかもしれない。それがフラッシュしている時だ。

自分で検証とインデックス作成を行うことが、インデックスデータの安全性を確保する唯一の方法だ。信頼できないソースからblk0001.datとblkindex.datをコピーした場合、その中身すべてを信頼できるかどうか知る方法はない。

Berkeley DBの設定を調整して、キャッシュメモリを有効化または増加できるかもしれない。

MrFlibble 2010年11月25日原文 · 個別ページ

最初の反応は「高速セットアップに+1」だったが、24時間の遅延のほとんどはローカルディスクによるものだった。キャッチアップモード中にデータベースのfsync(?)を無効にすることが最も効果的だろう。

Quote from: witchspace on November 25, 2010, 01:37:13 PM

えっ、P2Pは1つのソースではなく多くのユーザーから同時にダウンロードできるから、より高速なはずではないか？（一部のゲーム会社がアップデートの配布にBitTorrentを使っている理由でもある）

良い指摘だ。しかし、ブロックのSHA-256がコードに組み込まれているので、データも同梱するのは完全に合理的だ。ブロックチェーンが500MBを超えたら、転送効率が重要になると思う。

選択肢がある、

SFの利用規約の範囲内で妥当な限り、SFからブロックチェーンを配布する。
SFから「小さな」バイナリを配布し、BitTorrent経由でデータ付きの「大きな」リリースを配布する
「小さな」リリースを配布し、ブロックチェーン用の.torrentとフェッチャースクリプトを含める。

うーん、各バイナリアーキテクチャごとにブロックチェーンを同梱するのは馬鹿げている。

では、誰がデータのトラッカーとシードを提供するのか？インセンティブやコミュニティ精神のある人？まあ、このフォーラム+Wikiは http://www.slicehost.com/ で動いているようだ => 最低月$20。おそらくWebサイトに影響を与えずに共有でき、シードを厳しくスロットルして他のBTシードにより多くの負担をかけることもできる。

ジェフ・ガージック（jgarzik） 2010年11月26日原文 · 個別ページ

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の設定を調整して、キャッシュメモリを有効化または増加できるかもしれない。

これは多くの初心者ユーザーには当てはまらない。「まあ、90000ブロックすべてを取得するのに数時間かかりましたが、最終的に到着しました」と言うような人たちだ（今日IRCで新規ユーザーからの引用）。

同意する。アーカイブに圧縮すると、blk0001.datは約36MBになる。

ダウンロードではなく検証が最も高い体験のばらつきを持っている。初回ユーザーはソフトウェアが実際に使えるようになるまで30分から数時間の遅延を経験する。一部のP2Pノードは非常に遅い場合がある。エンドユーザーの帯域幅は低く、不安定で、高価かもしれない。ファイアウォールはしばしば問題になる。

公式Bitcoinにblk0001.datを同梱するだけで、新しいBitcoinユーザーが経験し続ける複数の問題を解消できる。

ジェフ・ガージック（jgarzik） 2010年11月26日原文 · 個別ページ

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の設定を調整して、キャッシュメモリを有効化または増加できるかもしれない。

ダウンロード中にACIDのどのプロパティが必要か？

BDBレコードの追加はチェックポイントを発行するまで単にログファイルへの追記だ。チェックポイントがメインデータベースファイルを更新する。

通常のBDBトランザクションでは、トランザクションのコミットが成功する前に各ログレコードがディスクに同期されることが保証される。これは非常に厳密だが、完全なACIDには必要だ。DB_TXN_NOSYNCを有効にしても多くが得られる。

Bitcoinは最近の取引が取り消されても明らかにリカバリできるので、初期ブロックダウンロードの100%でこのフラグを設定するのが有用だと思われる。

チェックポイントについては、チェックポイント時に実行される作業量——ログからデータベースファイルにコピーする必要があるレコード数——と実時間のバランスだ。いくつかの値を試して何が「適切」に感じるか見るしかない——おそらく10,000ブロックごとにチェックポイント？

サトシ・ナカモト（Satoshi Nakamoto） 2010年11月26日原文 · 個別ページ

7年前の遅いドライブでテストしたが、帯域幅とCPUは明らかにボトルネックではなかった。初回ダウンロードは1時間20分かかった。

それよりはるかに長く、特に24時間もかかるなら、非常に遅いノードからダウンロードしているか、接続速度が約15KB/秒（120kbps）よりかなり遅いか、何か他に問題があるはずだ。そのような場合にボトルネックが何であるように見えるかわかると良いのだが。

最新のブロックが送信される10分程度ごとに、より速いノードに切り替える機会があるはずだ。最新のブロックがブロードキャストされると、他のノードに次の500ブロックを要求し、最も速く送信するノードからダウンロードを継続する。少なくとも、そのように動作するはずだ。

Quote from: jgarzik on November 26, 2010, 02:07:43 AM

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の設定を調整して、キャッシュメモリを有効化または増加できるかもしれない。

ダウンロード中にACIDのどのプロパティが必要か？

BDBレコードの追加はチェックポイントを発行するまで単にログファイルへの追記だ。チェックポイントがメインデータベースファイルを更新する。

通常のBDBトランザクションでは、トランザクションのコミットが成功する前に各ログレコードがディスクに同期されることが保証される。これは非常に厳密だが、完全なACIDには必要だ。DB_TXN_NOSYNCを有効にしても多くが得られる。

Bitcoinは最近の取引が取り消されても明らかにリカバリできるので、初期ブロックダウンロードの100%でこのフラグを設定するのが有用だと思われる。

チェックポイントについては、チェックポイント時に実行される作業量——ログからデータベースファイルにコピーする必要があるレコード数——と実時間のバランスだ。いくつかの値を試して何が「適切」に感じるか見るしかない——おそらく10,000ブロックごとにチェックポイント？ 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の設定を調整して、キャッシュメモリを有効化または増加できるかもしれない。

ダウンロード中に、ACIDプロパティのどれが必要ですか？より多くの読み取りキャッシュが役立つかもしれない。インデックスを作成するためにblk0001.datとblkindex.dat全体をランダムに読み取る必要がある。ファイルがメモリより小さいと仮定することはできないが、現在はまだそうだ。ほとんどの依存関係が最近のものなので、キャッシュは効果的だろう。

誰かが異なるBerkeley DB設定で実験して、ダウンロードを大幅に速くするものがないか確認すべきだ。大幅な改善が見つかれば、詳細を詰めることができる。

引用：BDBレコードの追加は、チェックポイントを発行するまで、単にログファイルに追記するだけだ。チェックポイントがメインデータベースファイルを更新する。500ブロックごとにチェックポイントしている。

RHorning 2010年11月26日原文 · 個別ページ

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ユーザーやこの種のブロックファイルを適切なディレクトリに配置できないコンピュータに詳しくないユーザーのインストールを簡素化したいなら、正式なインストールファイルを作成して適切な場所に配置するのがより「ユーザーフレンドリー」だろうが、実際に必要なのはブロックデータだけだ。

この目的は主に、新バージョンにアップデートする際に同じブロックデータを繰り返しダウンロードしなくて済むようにすることだ。ブロックデータは定義上、時間とともに増大していく。

zipslack 2010年11月26日原文 · 個別ページ

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をアップグレードする際にブロックを再ダウンロードする必要はない。アップグレード前の状態からそのまま続行される。

RHorning 2010年11月26日原文 · 個別ページ

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ユーザーやこの種のブロックファイルを適切なディレクトリに配置できないコンピュータに詳しくないユーザーのインストールを簡素化したいなら、正式なインストールファイルを作成して適切な場所に配置するのがより「ユーザーフレンドリー」だろうが、実際に必要なのはブロックデータだけだ。

この目的は主に、新バージョンにアップデートする際に同じブロックデータを繰り返しダウンロードしなくて済むようにすることだ。ブロックデータは定義上、時間とともに増大していく。

それがまさにポイントだ。ブロックがアップデートに含まれていれば、すでにネットワーク経由で取得済みのブロックも含まれることになる。だからこそ、通常のディストリビューションに含めるのではなく、新規ユーザー向けの別のダウンロード（ただし強く推奨）にすべきだと提案しているのだ。

ジェフ・ガージック（jgarzik） 2010年11月28日原文 · 個別ページ

IRCの別の新規ユーザー（今回はLinux）が、1ブロックあたり4秒の速度でダウンロードしていた——推定合計ダウンロード時間は約4日間。

このスレッドの他のコメント者は、アップグレードするユーザーにはブロックデータベースは不要だと正しく指摘している……しかし、新規ユーザーの初期ブロックダウンロード体験を改善するために何かをする必要がある。データベースをいくら改善しても……さまざまな理由でブロックをゆっくり提供するピアは残る。

Genesisブロックからブロック74000までのハッシュがBitcoinにハードコード（コンパイル）されているので、ブロックデータベースの圧縮zipファイルをどこからでも自動的にダウンロードし、展開し、検証し、実行を開始できない理由はない。

tyler 2010年11月28日原文 · 個別ページ

Quote from: jgarzik on November 28, 2010, 02:33:29 AM

IRCの別の新規ユーザー（今回はLinux）が、1ブロックあたり4秒の速度でダウンロードしていた——推定合計ダウンロード時間は約4日間。

このスレッドの他のコメント者は、アップグレードするユーザーにはブロックデータベースは不要だと正しく指摘している……しかし、新規ユーザーの初期ブロックダウンロード体験を改善するために何かをする必要がある。データベースをいくら改善しても……さまざまな理由でブロックをゆっくり提供するピアは残る。

Genesisブロックからブロック74000までのハッシュがBitcoinにハードコード（コンパイル）されているので、ブロックデータベースの圧縮zipファイルをどこからでも自動的にダウンロードし、展開し、検証し、実行を開始できない理由はない。

何かをする必要がある。ブロックチェーンは来年かそこらで巨大になるのだろう？

ジェフ・ガージック（jgarzik） 2010年11月28日原文 · 個別ページ

Quote from: tyler on November 28, 2010, 07:23:04 AM

Quote from: jgarzik on November 28, 2010, 02:33:29 AM

このスレッドの他のコメント者が正しく指摘しているように、アップグレードするユーザーにはブロックデータベースは不要だが…新規ユーザーの初回ブロックダウンロード体験を改善するために何かをする必要がある。データベースをいくら改善しても…様々な理由でピアからブロックがゆっくり提供される状況は変わらない。

何かをする必要がある。ブロックチェーンは来年かそこらで巨大になるのだろう？ Quote from: jgarzik on November 28, 2010, 02:33:29 AM IRCの別の新規ユーザー（今回はLinux）が、1ブロックあたり4秒の速度でダウンロードしていた——推定合計ダウンロード時間は約4日間。

このスレッドの他のコメント者は、アップグレードするユーザーにはブロックデータベースは不要だと正しく指摘している……しかし、新規ユーザーの初期ブロックダウンロード体験を改善するために何かをする必要がある。データベースをいくら改善しても……さまざまな理由でブロックをゆっくり提供するピアは残る。

Genesisブロックからブロック74000までのハッシュがBitcoinにハードコード（コンパイル）されているので、ブロックデータベースの圧縮zipファイルをどこからでも自動的にダウンロードし、展開し、検証し、実行を開始できない理由はない。

はい、その通り。

おそらくある時点でブロックヘッダーのみをダウンロードする軽量クライアントが登場するだろうが、それでも数十万のヘッダーがある……

zipslack 2010年11月28日原文 · 個別ページ

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の設定を調整して、キャッシュメモリを有効化または増加できるかもしれない。

jgarzik 2010年11月28日原文 · 個別ページ

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()のストレージ呼び出しをスキップするだけで、それほど難しくないはずだ。

RHorning 2010年11月28日原文 · 個別ページ

これについては複雑な思いがある。一方では、ブロックチェーンの暗号的整合性の検証能力がクライアントに明らかにある。ネットワーク経由で来るブロックに対してそれを行っているからだ。blk0001.datには……信頼できないソースからネットワーク経由で元々受信されたシリアライズされたブロックが含まれている。

blk0001.datのファイル位置データをProcessBlock()に渡し、下流の呼び出し先AcceptBlock()でWriteToDisk()ストレージコールを単にスキップすることは、過度に難しいとは思えない。

そのような機能がいつか追加されることを望む。

MoonShadow 2010年11月28日原文 · 個別ページ

自分の理解では、インデックスが見つからない場合、クライアントは起動時にブロックチェーンの再チェックを行う。最初に始めた時にこれをやったが、確かにチェーンを辿っているように見えた。どのみちインデックスがないと機能しないのではないか？起動時にブロックチェーンが有効だと仮定する理由は？誰でも編集できるのだから。Genesisブロックはクライアントにエンコードされているよね？それとブロックチェーンのチェックポイントだけが正しいと仮定される部分で、間違っているだろうか？他の方法によるブロックチェーンのダウンロードを防ぐ正当な理由はない。Bitcoinネットワークが容量に近い状態で動いている将来では、P2Pネットワーク経由でブロックチェーン全体をダウンロードすることは有害になる。

マークルツリーがプルーニングされたチェーンでも最初から検証できるはずであり、そうでなければマークルツリーを使う意味は何だろうか？

サトシ・ナカモト（Satoshi Nakamoto） 2010年11月28日原文 · 個別ページ

他の議論にもかかわらず、現在の次のステップは：引用：誰かが異なる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）を使用した非圧縮データ。データの大部分はハッシュ、鍵、署名で、圧縮不可能だ。

初回ダウンロードの速度は、プロトコルの一括データ転送レートを反映していない。制限要因はダウンロード中のインデックス作成だ。

ジェフ・ガージック（jgarzik） 2010年11月28日原文 · 個別ページ

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%を「圧縮不能」とは呼ばない

Theymos（theymos） 2010年11月28日原文 · 個別ページ

Quote from: jgarzik on November 28, 2010, 06:59:49 PM

Quote from: satoshi on November 28, 2010, 05:13:01 PM

「検証する」ステップがあれば、現在の初期ダウンロードと同じくらいの時間がかかる。ボトルネックはデータダウンロードではなくインデックス作成だ。 […] 初期ダウンロードの速度はプロトコルのバルクデータ転送レートの反映ではない。律速要因はダウンロード中のインデックス作成だ。

申し訳ないが、これらのユーザーのディスクと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%を「圧縮不能」とは呼ばない

自分にはディスクの問題か彼の側のネットワーク状態の問題のように見えた。IRCログからの一部の引用：

また、ブロックの置き換えによって取引に気づかなくなった可能性もある。

サトシ・ナカモト（Satoshi Nakamoto） 2010年11月29日原文 · 個別ページ

実際よりも、すべてが間違っていると想定する傾向があるようだね。

ブロックインデックスの書き込みは軽い作業だ。txインデックスの構築は1ブロックあたりのランダムアクセスがはるかに多い。すべてのprev txinの読み取りが遅い原因ではないかと疑っている。読み取りキャッシュが役立つだろう。DBがそれを行うのが最善だ。キャッシュメモリの使用量の設定があるかもしれない。

引用：1) bitcoinはプログラムの起動時に環境だけでなくデータベースを開き、プログラムのシャットダウン時にデータベースを閉じるべきです。すでにそうしている。CDBを参照してくれ。（例えば）CTxDBオブジェクトの寿命は、データベーストランザクションのサポートと、シャットダウン時にまだデータベースを使用しているものがあるかどうかを知るためだけだ。

引用：そして、さらにbitcoinはデータベースのチェックポイントを強制し、すべてのトランザクションをログからメインデータベースにプッシュします。そうしていたらはるかに遅くなるだろう。1分または500ブロックに1回のみのはずだ：

    if (strFile == "blkindex.dat" && IsInitialBlockDownload() && nBestHeight % 500 != 0)
        nMinutes = 1;
    dbenv.txn_checkpoint(0, nMinutes, 0);

おそらくこれを追加すべきだ：

    if (!fReadOnly)
        dbenv.txn_checkpoint(0, nMinutes, 0);

引用：2) 初回ブロックダウンロードでは、txnコミットはレコードごとではなくN件ごとに行うべきです。N=1000を提案します。トランザクションコミットはフラッシュを意味するのか？それは驚きだ。トランザクションでラップされたデータベース操作は、他のデータベース操作と同様にログに記録されると思う。多くのデータベースアプリケーションでは、ほぼすべての操作のペアをトランザクションでラップする必要がある。例えば、あるアカウントから別のアカウントへの送金（aを借方、bを貸方）などだ。すべてを自分でバッチ処理することが求められるとは想像できない。

以下のケースで、ケース1は1回フラッシュし、ケース2は2回フラッシュするのだろうか？

ケース1： write write write write checkpoint

ケース2： begin transaction write write commit transaction begin transaction write write commit transaction checkpoint

データベースの使用方法を歪めるのは正しいアプローチではないだろう。BDBの設定とキャッシュで対応すべきだ。

ジェフ・ガージック（jgarzik） 2010年11月29日原文 · 個別ページ

ああ、すべてのC++コンストラクタに埋もれたデータベースオープンキャッシングを見落としていた。大きなレッドヘリングで、申し訳ない。

db4キャッシュ制御は http://download.oracle.com/docs/cd/E17076_01/html/api_reference/CXX/dbset_cachesize.html

ジェフ・ガージック（jgarzik） 2010年11月30日原文 · 個別ページ

クリーンなデータディレクトリ（中身なし）、-noirc、-addnode=10.10.10.1、Linux 64ビットで2回のタイミングを測定した。ハードウェア：SATA SSD

メインライン、パッチなし： 94660ブロックのダウンロードに32分。

メインライン + AddToBlockIndex()にTxnBegin/TxnCommit： 94660ブロックのダウンロードに25分。

サトシ・ナカモト（Satoshi Nakamoto） 2010年12月1日原文 · 個別ページ

良い最適化だ。次にSVNを更新する際に追加する。

より一般的には、これも検討できるだろう：

        dbenv.set_lk_max_objects(10000);
        dbenv.set_errfile(fopen(strErrorFile.c_str(), "a")); /// debug
        dbenv.set_flags(DB_AUTO_COMMIT, 1);
+       dbenv.set_flags(DB_TXN_NOSYNC, 1);
        ret = dbenv.open(strDataDir.c_str(),
                         DB_CREATE     |
                         DB_INIT_LOCK  |
                         DB_INIT_LOG   |

そうすれば、ウォレット書き込み後のフラッシュにはCDB::Close()のdbenv.txn_checkpoint(0, 0, 0)に依存することになる。