クライアントリストの維持に 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 フラッディングは明らかに無理だ。