私が言及していた方式は、Freenet の最初期のバージョンにあったものだ。信頼接続モデルが実装される前に設計されていた。詳細を思い出すには全部を見直さないといけない。だが基本的には、接続するノードがまず選ばれ（選び方は忘れた）、次にあなたがランダムな数を選んでそれらすべてのノードにブロードキャストする。各ノードもランダムな数を選んで、あなたとその集合内の他のノードに送り返す。すべての数が数学的に結合されて（関数は覚えていない）あなたの任意の ID になる。その合意された ID に応答しなければ、誰もあなたと通信しない。
間違っていても訴えないでくれ。明らかに当てにならない記憶からの話だ。
Sybil 攻撃（映画にちなんで名付けられたと思う）はネットワーク分断攻撃だった。複数の人格を作り出して、あるノードを取り囲んで何を保存しているかを推測しようとする。明らかにこの ID 生成方式ではそれが可能だと判明した。そこで新しい friend-to-friend トポロジーが生まれた。同じ制約は bitcoin にとっても弱点になり得る。だが失敗は、次の進み方への最良の手引きになることが多い。
Freenet の脱線はひとまず置いて……
「Proof-of-work」の技法は、あなたが鋭く指摘した ID 生成問題への対処にも実は応用できるかもしれない。トランザクションの記録を生成しにくくする代わりに、新しいノードを生成してネットワークに接続することを難しくすればいい。
仮に（思いつきで作るが）、ノードに秘密鍵を作らせ、その鍵に対して proof-of-work のチェックサムを計算させ、そしてノード ID を RIPE-160(SHA-256(POWCheckum(公開鍵) + SHA-256(公開鍵)))のようなものにする、と要求するとしよう。
意図は、ノード ID の生成を、攻撃を成立させられないほどに遅くすること。ただし、新規ノードの参加が苦痛になるほど遅くはしないこと。
それにトランザクションへの土壇場の「ソルト」を組み合わせれば、ほぼ目的地までたどり着けるかもしれない。
ところで、私の前回の構想で見落としていたものに気づいた。
トランザクションが DHT に送られたとき、実際には多数の（できれば独立した）ノードに保存されると私は仮定していた。各入力点に関連して 5回、各出力点に関連して 5回。さらに支払者によって 1回、受取人によって 1回。入力 1・出力 2 なら 17倍の冗長性ということになる。
これらの場所のどれもが、トランザクションが消えた場合にネットワークに「再送信できる」はずだ。
ただし、私は 3 つのことを考慮し損ねていた。1) 検証者は 17箇所のうち 5箇所だけを検証に使う。2) 最初の 5箇所が侵害された場合、他の冗長な場所に問い合わせる手段がない。3) 追加の冗長な場所は、標的を絞った悪意ある虚偽を返してきた侵害ノードを識別する手段がない。
しまった。だがいい指摘だ！