ここでまた混乱した。あなたのスキームにはブロックはなく、トランザクションだけだと思っていた。先に「ブロック」を解くとはどういう意味か？
私のスキームにはブロックがない。ここでは既存のシステムの動作方法について言及していた。
ギャビン・アンドレセン😕？ ネットワークに10,000ノードがあるとしよう。二重支払いしたいトランザクションに最も近いネットワークノードを見つけるためにクエリを行う。
そこで秘密鍵を生成する。現在最も近いノードよりも近くなる確率は約1/10,000だ。だから近い鍵を5つ見つけるまで秘密鍵を生成し続ける。確率を今から計算する余裕はないが、100,000の秘密鍵を生成すれば、5つ見つかる可能性はかなり高い。私のしょぼいラップトップでも最低でも毎秒100のECC鍵を生成できるので、20分もあれば100,000を生成できる。
それらの鍵で5つのノードを作成し（ネットワークの残りに「みなさん、正直なところ、これらの鍵は本当にランダムに選んだんだ…」と言いながら）、勝利だ。
トランザクションのハッシュに対して、ネットワーク上の他のどのノードよりも「近い」ノードIDを生成しようとしているのだ。それははるかに簡単だ。
はい、はるかに簡単だ！
この特定のケースについて、非常にもっともらしい議論をしてくれた。お見事！
ポイントはそこではないので、私も計算はしない。「解決策」を提案しているわけではない。bitcoinの要件を満たすために計算リソースがこれほど悪くスケールする必要はないことを示唆しているのだ。他の合理的な設計が、大幅に低いCPU使用量で、そしてこのスレッドの場合はより低いレイテンシーでbitcoinの要件を満たせることを示そうとしているだけだ。
このフォーラムのブレイントラストがあれば、分散型ソリューションの限界は容易に発見・修正できると思う。現在の実装においてもまさにそれが行われているとおりだ。おそらくノードIDの作成方法が不適切だったのだろう。Freenetは完全に異なるノードID共有生成方法を提案している。あなたが指摘する問題は発生しない。おそらくこの状況では他の問題があるかもしれない。しかし、機能する分散型実装が存在すると確信している。
あなたの議論の主旨と懐疑は、100,000のCPUを100%で24時間365日稼働させ、トランザクションごとに100,000以上の冗長メッセージを送信するよりも良い解決策が絶対にありえないと考えているからか？
（100,000という数字は、何百万人ものユーザーを支える想定のシステムにおいて、サトシが見込んでいたコアノード数だ）