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