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