スケーラビリティ
すべてのノードがすべてのトランザクションに関する情報を受信する（技術論文に記載されている通り）という理解で正しいだろうか？それでは、ビットコインを大規模な通貨として使用することは完全に非実用的にならないだろうか？
経済の議論はたぶん別スレッドでやるべきだから、これくらいにしておく。新しいスレッドを立てようとしたら、この人が自分の言いたいことをもっとうまく言ってくれていた：topic 57
knightmb：ブロックあたりのコイン数は時間とともに減少するよう設定されているから、数値はそれよりかなり大きくなる。トランザクションも含める必要がある。最初の 67k ブロックの間のトランザクション数は、何百万人もの人がこのシステムを使い始めた場合よりはるかに少ない。
コードに取り組んでいる人、スケーリングがどう対処されるのか答えてくれないか？今一番重要なのは、このシステムが機能する理由を売り手に納得させることだと思う。PDF は詳細が不十分だ。
経済の議論はたぶん別スレッドでやるべきだから、これくらいにしておく。新しいスレッドを立てようとしたら、この人が自分の言いたいことをもっとうまく言ってくれていた：topic 57
knightmb：ブロックあたりのコイン数は時間とともに減少するよう設定されているから、数値はそれよりかなり大きくなる。トランザクションも含める必要がある。最初の67kブロックの間のトランザクション数は、何百万人もの人がこのシステムを使い始めた場合よりはるかに少ない。
コードに取り組んでいる人、スケーリングがどう対処されるのか答えてくれないか？今一番重要なのは、このシステムが機能する理由を売り手に納得させることだと思う。PDFは詳細が不十分だ。
指摘してくれてありがとう、時間とともにどうスケールするのか分からなかったから、推測しただけだった。コイン生成の式はどこかで分かるはずだから、XYZ のトランザクションが与えられた場合に X 量のコインがどれだけのディスク容量を使うか、誰か計算できないのか。
自分自身もどのくらいの容量になるか気になる。 😊
コイン生成の公式はどこかでわかるはずだから、XYZトランザクションが与えられた場合にX量のコインがどれだけのディスク容量を占めるか計算できるんじゃないか。 自分もどれだけの容量が必要か気になる。
論文から： 「トランザクションのないブロックヘッダーは約 80 バイトになる。」 そして 「コインの最新トランザクションが十分なブロックの下に埋もれたら、それ以前の使用済みトランザクションは ディスク容量を節約するために破棄できる。」
つまり、80 × ブロック数 + 平均トランザクションサイズ × トランザクション数だ。
実際に自分のディスクから： 66663 ブロック中の 77428 トランザクションは約 46,752,464 バイト。 これは 1 トランザクションあたり約 600 バイトになる（ブロックヘッダーとデータベースのオーバーヘッドを含む）
66663ブロック中の77428トランザクションは約46,752,464バイト。 これは1トランザクションあたり約600バイトになる（ブロックヘッダーとデータベースのオーバーヘッドを含む）
それくらいだろう。
つまり 1日100 万トランザクションなら 6 億バイトだ。1日600 メガバイト、月18GB。
それほど悪くない。実際のネットワーク帯域幅はもっと大きくなる（ネットワークの接続方法により、ピアから同じトランザクションを複数回受信する）。iPhone で常時接続ネットワークノードを動かすことにはならないが、安価なサーバーならその 20倍の月間帯域幅を提供できる。そして 18GB はテラバイトのハードドライブの時代にはたいしたディスク容量ではない。
1日100 万トランザクションは非常に多い！ 比較のために言えば、2006年にはアメリカで 1日あたり約 6000 万件のクレジットカード取引があった。
最終的に、Bitcoin が生き残ってクレジットカードと同じくらい普及すれば、誰かがより効率的なネットワーク構造を持つ互換バージョンを作るだろう（その頃には何か洗練された IPV6 マルチキャストプロトコルなどがあるかもしれない）。そして彼らはいくつかのゲートウェイノード（非常に高速な回線で動作する）を実装して、現在の Bitcoin ネットワークからトランザクションとブロックのトラフィックを超効率的なネットワークに中継するだろう。そしてほとんどの人は、ウォレットの保持、トランザクションの署名、そしてすべてのトランザクションを監視している超高速ノードへのトランザクションの送受信だけを行う軽量クライアントを使うことになるだろう。
つまり、インターネットのバックボーントラフィックを処理する巨大なルーターや、超高速の DNS ルートサーバーのようなものだ。インターネットも最初から驚異的に高速なルーターがパケットを飛ばし合っていたわけではない。
そしてほとんどの人は、ウォレットの保持、トランザクションの署名、そしてすべてのトランザクションを監視している超高速ノードへのトランザクションの送受信だけを行う軽量クライアントを使うことになるだろう。
それは可能なのか？どのようなものになるのか？技術的な観点から「軽量クライアント」はどういうものをイメージしているのか？私の理解では、Bitcoin クライアントは信頼を確立するためにブロックチェーン全体が必要だ。
ちょっと思いつきを述べてみる…
P2P モデルは確かに斬新だが、多少ユートピア的に思える。少し付き合ってほしい（荒らしたいわけではない）。銀行を考えてみよう。銀行には効率的に協力し合うシステムがある。銀行 Y の口座を持っていても、銀行 X の ATM からお金を引き出せる。銀行同士は融資し合う。基本的に協力的だ。すべての人が PC（やスマートフォン）に Bitcoin クライアントを入れてオープンな P2P ネットワークに参加する代わりに、Bitcoin の「銀行」の集まりがブロックチェーンのホスティングと「ピアリング」のサービスを提供するのはどうだろう。これらは十分に大きな組織で、1日100 万件（以上）のトランザクションを持つ無限に長いブロックチェーンを維持するための帯域幅とハードウェアを賄える。これらの銀行は P2P のままであり、完全にオープンであることが望ましい。理想的には誰でも P2P ネットワークに参加できるが、参入障壁があるため一般の人はそうしないだろう。これらの銀行は今日あるのと同じ基本技術で運営される。Bitcoin の美しい側面はすべて保たれるが、アクティブな参加者の数がいくらか減少する。参加したい人は引き続き参加できる。
残る問題は典型的な「ラストマイル」問題だ。一般ユーザーはどうやってトランザクションを行うのか？この時点では問題はかなり単純になる。信頼は 2 者間（「銀行」とユーザー）だけで済む。これは本質的にプロキシの問題になる。ユーザーは「銀行」を通じてトランザクション要求を送信する。プロキシトランザクション用のプロトコルを Bitcoin に組み込むことさえ可能かもしれない。
とにかく…これは私の個人的な意見に過ぎない。この問題に対する具体的な回答がほしい。なぜなら、この取り組みの成功にとって根本的に重要だと思うからだ。
ギャビン・アンドレセンの投稿（2010年7月13日 15:42 UTC）そしてほとんどの人は、ウォレットの保持、トランザクションの署名、そしてすべてのトランザクションを監視している超高速ノードへのトランザクションの送受信だけを行う軽量クライアントを使うことになるだろう。
これは可能なのか？ どんな感じになる？ 技術的な観点から「軽量クライアント」はどのようなものか？ 私の理解では、Bitcoinクライアントは信頼を確立するためにブロックチェーン全体が必要だ。
私のイメージはこうだ：
軽量クライアントはコインの入ったウォレット（公開鍵+秘密鍵のペア）を持つ。
そして、常時接続の超高速ヘビー級ノードとの間で安全にメッセージを送受信する方法を持つ。
軽量クライアントは送金時に： トランザクションを作成する（秘密鍵でコインに署名する） 署名済みトランザクションを超高速サーバーに安全に送信し、サーバーがネットワークに流す トランザクションが有効で送信されたことの確認を受け取り、ウォレットを更新する（コインを使用済みにする） （またはサーバーから「そのコインはすでに使用済みだ」というエラーを受け取る）
軽量クライアントは受け取り時に： 定期的にサーバーにポーリングして「ウォレット内のこれらの BC アドレスへの支払いはあるか？」と尋ねる …または BC アドレスのリストへのトランザクションを検知した時（あるいは N 回の確認が得られた関連トランザクションを検知した時）に通知するようサーバーに依頼する トランザクションが発生したら、軽量クライアントはウォレットを更新する（コインを追加する）
サーバーを信頼する必要はない。サーバーは秘密鍵を持つことはない。
まあ、サーバーがトランザクションの有効性について嘘をつかないことは信頼する必要があるが、サーバーがなぜそんな嘘をつくのか？
確かにそのように動作はするが、それが理想なのか？ネットワークの堅牢性が低下し、攻撃や操作に対してより脆弱にならないか？攻撃者がスーパーノードのクラスタを運用し始めたらどうなるのか？要点は、その必要がないのに、なぜこのより脆弱なアーキテクチャに依存するのかということだ。実装がより簡単というわけでもない。
そう、どちらのシステムもあまり良い設計ではないと思う。Limewire は Gnutella のルーティングを実際に Kademlia に置き換えた。
spaceshaker：そう、モバイルデバイスのプロキシとして機能するノードが必要になるという点には同意する。
確かにそのように動作はするが、それが理想なのか？ネットワークの堅牢性が低下し、攻撃や操作に対してより脆弱にならないか？攻撃者がスーパーノードのクラスタを運用し始めたらどうなるのか？要点は、その必要がないのに、なぜこのより脆弱なアーキテクチャに依存するのかということだ。実装がより簡単というわけでもない。
実際にはそうでもない。心配なら、自分自身のサーバーをいつでも運用できる。
何も問題ない。たまたまそのスーパーノードの一つを使っている場合を除けば。使う必要はない。自分でスーパーノードを運用すればいい。あるいは、人々が Google にメールを任せるように、信頼できるノードを使えばいい。
実装がより簡単だというわけではないだろう？ここは根拠を示してほしい。
反例：ライス大学で開発された完全分散型メールシステムは、半集中型のメールサーバー（群）を運用するよりもはるかに複雑だ。
それはまさにスーパーノードサーバーがやることだ。
Quotespaceshaker：確かにモバイルデバイスのプロキシとして動作するノードが必要になるだろう。
うーん。それはまさにスーパーノードサーバーがすることだ。
うーん。確かに。一周回ったようだ。ギャビンが一番うまく言ったと思う：
ギャビン・アンドレセンの投稿（2010年7月13日 17:20 UTC）軽量クライアントはコインの入ったウォレット（公開鍵+秘密鍵のペア）を持つ。
そして、常時接続の超高速ヘビー級ノードとの間で安全にメッセージを送受信する方法を持つ。
軽量クライアントは送金時に： トランザクションを作成する（秘密鍵でコインに署名する） 署名済みトランザクションを超高速サーバーに安全に送信し、サーバーがネットワークに流す トランザクションが有効で送信されたことの確認を受け取り、ウォレットを更新する（コインを使用済みにする） （またはサーバーから「そのコインはすでに使用済みだ」というエラーを受け取る）
軽量クライアントは受け取り時に： 定期的にサーバーにポーリングして「ウォレット内のこれらのBCアドレスへの支払いはあるか？」と尋ねる …またはBCアドレスのリストへのトランザクションを検知した時（あるいはN回の確認が得られた 関連トランザクションを検知した時）に通知するようサーバーに依頼する トランザクションが発生したら、軽量クライアントはウォレットを更新する（コインを追加する）
サーバーを信頼する必要はない。サーバーは秘密鍵を持つことはない。
まあ、サーバーがトランザクションの有効性について嘘をつかないことは信頼する必要があるが、サーバーがなぜそんな嘘をつくのか？
このシナリオでは、Bitcoin クライアントは現在とほぼ同じままだが、「スーパーノード」や「トランザクションサーバー」や「プロキシサーバー」（これらのシステムはおそらく 3 つの役割すべてを果たす）で使われるか、そのゲームに参加したい人が使うことに焦点が当てられるだろう。Bitcoin クライアントが DHT を使うよう拡張されれば改善になるかもしれないが、ギャビンが上記で説明した「軽量クライアント」の必要性は依然としてある。ギャビンの「軽量クライアント」コンセプトは、私のスケーラビリティの懸念をある程度解消してくれるようだ。
spaceshakerの投稿（2010年7月13日 16:52 UTC）ギャビン・アンドレセンの投稿（2010年7月14日 00:42 UTC）そして私たちのほとんどは、ウォレットを保持し、トランザクションに署名し、すべてのトランザクションを見ている超高速ノードにトランザクションを送受信するだけの軽量クライアントを実行するようになると予想している。
これは可能なのか？ どんな感じになる？ 技術的な観点から「軽量クライアント」はどのようなものになるのか？ 私の理解では、Bitcoinクライアントは信頼を確立するためにブロックチェーン全体が必要だ。
想像してみると： …
想像する必要もない。実際には既にノードを「リモートコントロール」できるので、自分の（高速接続、HDD 満載の）ホームサーバーに情報を送受信するだけの小さな軽量クライアントを作ればいい。
ある種の「管理されたサーバー-クライアント版」は MyBitcoin にすでに存在している。自分のウェブホストで同様のものを実行して、どこからでもどんな接続速度でもアクセスできる。
「軽量クライアント」自体がそうである必要はなく、接続して何をすべきか指示すればいい。 JSON でできる。
クライアントリストの維持に DHT を使うアイデアを支持する――何百万人もの人が IRC チャンネルなどに依存するわけにはいかない。スケーリングの問題に関して言えば、HDD の容量は問題ではなく、ネットワーク帯域幅だ。皆忘れているが、bytes_per_transaction*transactions ではない（これは皆が使っている数字だ）。その数字は、皆が言うように完全に管理可能だ。いや、我々が関心を持つべき数字は bytes_per_transaction * transactions * number_of_clients * total_hops_beyond_first_between_all_clients_combined だ。
これが、ネットワークがスケールするにつれて BTC プロトコルが消費する帯域幅だ。各トランザクションの 1 コピーを各クライアントに送信するだけではなく、複数のクライアントが互いに冗長なデータをブロードキャストし、それを複数のホップを通じて行うため、何度もリブロードキャストされる。はるかに大きな数字であり、扱いがはるかに難しい。しかし、管理は可能だ。ただし、クライアントの現在のネットワーク処理の形では無理だ。
おそらく「普及」段階では、BTC チェーンを地域ごとに分割できるかもしれない。現在のドメインネーム管理機関の管轄と同様に。そして、これらの地域境界を越えた取引には代替プロトコルを使うとか？ これは問題の生の数字を改善し、レイテンシーや関連する問題も軽減するだろう。これが優れた解決策だとは思わないが――量子コンピューティングなどの大きなブレークスルーがない限り、全アクティブクライアントへの P2P フラッディングは明らかに無理だ。
設計では、完全なブロックチェーンを必要としない軽量クライアントの概要が示されている。設計 PDF では簡易支払い検証（Simplified Payment Verification）と呼ばれている。軽量クライアントはトランザクションの送受信ができるが、ブロックの生成はできない。支払いの検証にノードを信頼する必要はなく、自分で検証できる。
軽量クライアントはまだ実装されていないが、必要になった時に実装する計画だ。今のところ、全員がフルネットワークノードを実行している。
ノード数は 10 万を超えることはないと予想しており、おそらくそれ以下だろう。それ以上のノードが参加する価値がない均衡点に達する。残りは軽量クライアントになり、数百万になる可能性がある。
均衡サイズでは、多くのノードはサーバーファームとなり、1 つか 2 つのネットワークノードが LAN 経由でファームの残りに供給する。
仕様がすでにこの問題に対応してくれているのはありがたい。コインリスト（誰から受け取ったかに基づいてコインを使う、といった選択ができるように）やクライアントリストなど、もう少し踏み込んだアクセスができるようにしてほしい。例えば、家にある俺のすべてのコンピューターは、ルーターに接続しているんだが、そのルーターはポート 8333 を開けて動作している（ただし generate はしていない）。
リモートのノードよりも自分のローカルノードへのネットワークトラフィックを優先する方法があればいいんだがな。
ノード数は10万を超えることはないと予想しており、おそらくそれ以下だろう。それ以上のノードが参加する価値がない均衡点に達する。残りは軽量クライアントになり、数百万になる可能性がある。
均衡サイズでは、多くのノードはサーバーファームとなり、1つか2つのネットワークノードがLAN経由でファームの残りに供給する。
君か、あるいは誰でもいいんだが、現在のシステムの 1秒あたりのトランザクション数の上限について推測してもらえないだろうか？
最大のトランザクションスループット（量ではなく、件数で）はどれくらいになるんだ？それは何に依存するんだ？
システムが成長した場合、その数の将来的な限界はどうなるんだ？
Bitcoin をマイクロペイメント、あるいはナノペイメント向けのシステムとして考えてみよう。 フォーラムへの投稿に 0.000001（またはそれ以下）を支払うとか？あるいは、フォーラムを読むだけで（広告が除去された状態で）それより少ない額を支払うとか？ それは 1日100 万件をはるかに超えるトランザクションを生み出すことになる。 それは前例のないトランザクションの流れを生み出す。 ナノペイメントを行わない他の参加者に害を及ぼすだろうか？
ウォレット間で小額を循環させてシステムをフラッディングすれば、「システム」の速度をテストできるんじゃないか？ それともできないか？ もしやったとしたら、どんな影響が出るんだ？
そういう実験には反対するか？もし拒否権を行使するなら、どうやって止めるんだ？
まあ、サーバーがトランザクションの有効性について嘘をつかないことは信頼する必要があるが、サーバーがなぜそんな嘘をつくのか？
爆笑！！！
サトシ・ナカモトの投稿（2010年7月14日 21:10 UTC）次のリリースに向けて、「サーバー」と「クライアント」を分離する作業をするには、今がいいタイミングだと思う。
設計では、完全なブロックチェーンを必要としない軽量クライアントの概要が示されている。設計PDFでは簡易支払い検証（Simplified Payment Verification）と呼ばれている。軽量クライアントはトランザクションの送受信ができるが、ブロックの生成はできない。支払いの検証にノードを信頼する必要はなく、自分で検証できる。
軽量クライアントはまだ実装されていないが、必要になった時に実装する計画だ。今のところ、全員がフルネットワークノードを実行している。
これらの「クライアント」や「ライトウェイトクライアント」はいつリリースされるんだ？あるいはサンプルコードのようなものはあるか？ たとえば Java スマートカード環境上に実装してみるのは面白いだろうな。
設計では、フルブロックチェーンを必要としないライトウェイトクライアントが想定されている。設計PDFではこれをSimplified Payment Verification（簡易支払い検証）と呼んでいる。ライトウェイトクライアントはトランザクションの送受信ができるが、ブロックの生成だけはできない。
ライトウェイトのジェネレータが、多数のノードに対して以前のブロックチェーンのハッシュと現在のブロックに含まれるトランザクションを問い合わせる方式なら、ブロックを生成することは可能なのか？