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