私はAndroid携帯で動作するクライアントの構築を視野に入れて、簡易支払い検証のJava実装に取り組んでいます。そのため、ストレージ要件とBitCoinのスケーラビリティについて多く考えてきましたが、論文では答えられていないいくつかの疑問が生じました（論文の新版を出してもいいかもしれません。現在では内容の一部が古くなっていると思います）。
論文における簡易支払い検証は、IPアドレスへの送信のようにトランザクションを直接受信することを想定していたが、誰もそれを使っていない。あるいは、ノードがすべてのトランザクションを公開鍵でインデックス化し、メールサーバーからメールをダウンロードするようにダウンロードできることを想定していた。
代わりに、クライアント専用ノードはフルブロックを受信して、自分のトランザクションをスキャンすべきだと考えている。それらを保存したりインデックス化したりする必要はない。初期ダウンロードでは、プログラムが初めて実行される前には支払いが存在し得ないため、ヘッダーのみをダウンロードすれば十分だ（ヘッダーダウンロードコマンドは0.3.18で追加された）。それ以降は、フルブロックをダウンロードする（ただしヘッダーのみ保存する）。
クライアント専用モードのコードはほぼ実装済みだ。GitHubにフィーチャーブランチがあり、このメッセージにパッチも添付している。
以下に詳細を述べる：
「これまでのクライアントモード実装だ。クライアント専用モードはブロックヘッダーのみを記録し、txインデックスを使用しない。生成はできないが、トランザクションの送受信は可能だ。エンドユーザー向けには完全に仕上がっていないが、fClientが有効でなければ完全に何もしないので問題ない。現時点では、主にクライアント専用の再実装者向けのカットラインを示すドキュメントだ。
fClient=trueでは、ヘッダーのみの初期ダウンロードのみテストした。
少し背景を説明する。CBlockIndexにはブロックヘッダーのすべての情報が含まれているため、ヘッダーのみで動作するには、通常通りCBlockIndex構造を維持するだけだ。フルブロックがディスクに記録されないため、nFile/nBlockPosはnullだ。
途中でblk*.datを削除せずにクライアントモードのオン/オフを切り替えるコードはまだ実装されていない。主に、非クライアントのLoadBlockIndexがブロック位置がnullのブロックインデックスエントリを無視するようにすれば済む。そうすれば、それらをフルブロックとして再ダウンロードする。クライアントモードへの切り替えは問題ない。フルブロックがあっても気にしない。
初期ブロックダウンロードが長くなりすぎる場合、新しいユーザーがすぐに使い始められるように、クライアントモードをオプションとして用意したい。クライアントモードの適切なオフ切り替えにより、後でクライアントモードをオフにして、生成を始めたい場合はフルブロックをダウンロードできる。むしろgetworkマイナーを使ってプールに参加すべきだ。
クライアント専用の再実装はEvalScriptを全く実装する必要がないか、せいぜい標準トランザクションテンプレートで使用される5つのオペコードだけを実装すれば十分だ。」
具体的には、BitCoinにはさまざまなマジックナンバーがあり、コードにも論文にもその由来が説明されていません。例えば、2100万枚のコインが発行されるとインフレーションが停止するという事実。この数字は何らかの方法で導き出されたはずですが、どのようにして決められたのか分かりません。
経験に基づく推測で、計算するときりのいい数字になる。非常に普及した場合に低すぎず、そうでない場合に高すぎないものが欲しかったのだ。
もう一つは10分間のブロック目標です。これはトランザクションがネットワーク全体に伝播できるように選ばれたと理解しています。しかし、BGPのような既存の大規模P2Pネットワークは、新しいデータを1分未満で世界中に伝播できます。
伝播に1分かかるなら、10分は良い推測だった。ノードは作業の10%しか失わない（1分/10分）。レイテンシによって無駄になるCPU時間の割合がもっと大きければ、私が考えていない弱点があるかもしれない。攻撃者は自分のブロックを連鎖させているためレイテンシの影響を受けず、有利になる。レイテンシにより、チェーンは一時的により頻繁にフォークするだろう。
最後に気になる数字は、ブロックサイズの500kb制限です。Wikipediaによると、Visaだけで2009年に620億件の取引を処理しました。割り算すると平均で毎秒2000トランザクション、ピーク時はおそらくその倍の毎秒4000トランザクションになります。10分間のブロック目標では、ピーク時にブロックは240万トランザクションを含む必要がありますが、これは500kbには収まりません。この500kbは公式クライアントから徐々に撤廃される一時的な制限ですか、それともより根本的なものですか？
実際の使用量が制限に近づき、正常に動作していることを確認してから、より高い制限を段階的に導入できる。
最終的にクライアント専用の実装が実現すれば、ブロックチェーンのサイズはあまり問題にならなくなる。それまでは、すべてのユーザーが開始するためにブロックチェーン全体をダウンロードする必要がある間は、合理的なサイズに抑えられるのは良いことだ。
非常に高いトランザクション量では、ネットワークノードは統合され、プールマイニングやGPUファームが増え、ユーザーはクライアント専用で動作するようになる。最適化と並列化の開発作業により、スケールアップを続けることができる。
ソフトウェアの現在の処理能力がどうであれ、ムーアの法則の速度、年間約60%で自動的に成長する。