このアイデアを頭ごなしに否定する理由を探せば、見つかるだろう。しかし、なぜ一部のP2Pシステムは成功し、多くは失敗するのかを理解するためにこの例を使えば、何かしらの洞察が得られるはずだ。
その精神で、質問に直接答えよう。
Quote from: gavinandresen on August 06, 2010, 11:32:05 PM
どちらが先に発生したトランザクションかについて意見が一致しない場合はどうなるのか？多数決か？誰が多数派を決め、5ノードのうち4つがネットワークを離れて別の5ノードに置き換わった場合、変わり得るのか？
そのout-pointを使う他のトランザクションが1つでも見つかれば二重支払いだ。現在のBitcoinシステムと同じルールだ。意見の不一致が起こり得るのは、競合するトランザクションが同時にブロードキャストされ、一方がノードAに先に到着し、競合する方がノードEに先に到着した場合だけだ。2つの5ノードブロードキャストが完了するまでに、双方が二重支払いを発見する。
ではどちらが有効か？どちらでもいい。コインを投げればいい。Bitcoinはこの状況でまさにそうしている。自分のノードがあるトランザクションを含むブロックに取り組んでいて、あなたのノードが競合するトランザクションを含むブロックに取り組んでいる場合、先にブロックを解いた方が勝つ。分散コイン投げアルゴリズムは自明だ。これらすべてはほぼ即座に実行できる。10分間のウィンドウよりはるかに速い。だから4ノードが離脱しても多数派は変わらない。合意はすでに達成され、ノードは整合性が取れた状態になっているからだ。
ちなみに、標準的なDHTはノードが離脱した時のデータ保持と、ノードが参加した時のデータ分散にすでに対応している。
Quote from: gavinandresen on August 06, 2010, 11:32:05 PM
そして、大きなトランザクションを作成する予定があると分かっている場合、（まだ送信していない）トランザクションが自分の管理するノードにハッシュされるようにノードIDを事前計算する作業を行えるのか？トランザクションを保存するすべてのノードを管理していれば、「はい、間違いなく、そのトランザクションは有効で二重支払いされていない…」と答えるだけでいい。
いいえ、これは要件上の制約だ。同じ理由で不可能だ——2つの公開鍵が同じBitcoinアドレスに一致するものを生成することが不可能なのと同じだ。以前の私の失言を参照してほしい。
ノードはBitcoinアドレスと全く同じように秘密鍵に基づいてノードアドレスを生成する。これによりノードのなりすましは非現実的になる。out-pointハッシュへのすべての入力は受取人を除いて固定されており、受取人は事前に指定されている。唯一の柔軟性は支払い額だろう。すべての可能な金額を反復して同時に5方向のハッシュ衝突を作ろうとするなら、どうぞ好きにしてくれ。
Quote from: gavinandresen on August 06, 2010, 11:32:05 PM
bitcoinの背後にある素晴らしい洞察は分散タイムスタンプメカニズムだ。全員がトランザクションの順序に合意する。あなたのスキームがその問題をどう解決するのか分からない。
実は全く同じ方法で問題を解決する。ただCPUパワーがはるかに少なくて済む。
Bitcoinの分散タイムスタンプメカニズムの背後にある素晴らしい洞察は、絶対的なタイムスタンプは全く必要ないということだ！必要なのは相対的な順序だけだ。短いウィンドウ内での競合については、気にする必要すらない。単に任意に1つを選べばいい。
私の解決策はまさに同じことをする。トランザクション間の相対的な順序を維持する。競合については任意に合意に達する。どちらの方法も、無関係なトランザクションを時間順に正確に並べる必要はない。繰り返すが、あれは素晴らしい洞察だった。