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