Re: 提案ではなく

人物: Red

これには 2 部に分けて返答する。

サトシ・ナカモトの投稿(2010年8月13日 19:28 UTC)

あなたのアイデアをまだ把握できていない。

それは私のせいだ。一度にあまり多くを主張しないようにしていたし、分析のために一度に多くの新しい「機能」を導入しないようにもしていたからだ。

私の心の中の目標は、トランザクションの可視性の地平を段階的に狭めていくことだ。時間的にも、空間的にも。時間というのは、たとえば特定の瞬間に動いているノードだけに、ということ。空間というのは、その時点で動いているノードすべての集合より少ない範囲に、ということ。最適には、トランザクションは送信者と受信者にしか知られないようにしたい。そうすればすべての証拠は消える。

10 ドル札を私からあなたに手渡す。そのまま二人は永遠に立ち去る。私が紙幣を渡したその瞬間を誰にも観察されていなければ、紙幣自体を調べてもその事実は誰にも発見されない。

サトシ・ナカモトの投稿(2010年8月13日 19:28 UTC)

公開ネットワークから何か情報を隠すのか? 利点は何だ?

少なくとも 50%のノードがトランザクションを十分に検証して古いトランザクションを破棄できるなら、全員がすべてを見て記録を保持できたということだ。

最初私は、すべてのトランザクションは関係する当事者間でのみ検証されることを願っていた。事実上、ブロック生成ノードは伝えられたハッシュを記録するだけ、ということになる。

ただし土壇場で気づいたのは、ハッシュが署名もされず検証もされていないので、「以前のアウトポイントハッシュをキャンセルする」という偽の操作が容易に可能になってしまうことだった。誰かのコインを盗むことはできないが、無効化することはできてしまう。

その厄介な詳細について、3 つの前進方法が考えられる。1) すべての検証者がトランザクションを見る代わり、保存するものを最小化する。2) 各トランザクションを見る必要のある検証者の数を最小化する何らかの方法を考える。3) 新しいアウトポイントごとに使い捨ての鍵ペアを作る。ハッシュに署名する。(土壇場の追加案だ!)

  1. 最初に書いたのは 1 つ目のケースだった。一度に変数を増やしすぎないためだ。ハッシュしか記録しないやり方が明らかな FAIL ではないことを確認したかった。

得られるプライバシーがどの程度かを定量化しようとした。最悪のケースでは最小だ(どのみち全員がすべてを保存する)。だが標準的なケースではかなり大きい。多くの人は自分に必要のないものは保存しないからだ。

つまりこの段階での恩恵は、新たな脅威が観察できるのは自分が参加した後に発生したトランザクションだけ、ということ。過去にさかのぼることはできない。ただし、参加時から全てを記録していた早期参加者を特定し、共有を承諾させられる場合を除く。最小限の保護だが、少なくとも昔の恋人に後から詮索される心配はない。:-)

  1. ただし、DHT を巧みに使えば空間的な地平も最小化できる。詳細はまだ詰めていないが、1 万の冗長な検証ノードを持つ 1 つのブロックリストではなく、ブロックリストを 1024個の同一のブロックリストに分け、それぞれに 10個の冗長な検証ノードを持たせる、というイメージだ。ランダムに選ばれたノードの集合がそれぞれハッシュ空間の 1 区分を担当する。

ただし、何かを偽造するには CPU パワーの 50%以上が必要、という保証ではなく、100%の合意とチェーンチェックサムやブロックの完全なブロードキャストを目指す。そうすれば、定期的な DHT 再編成のたびに、新しいノードはチェーンが常に 100%整合していたことを検証できる。(毎日新聞に 1024個のチェックサムを掲載するようなものだ)

これにより、攻撃者が「どのハッシュをキャンセルしたいか」を知るための可視性が制限される。(私はトランザクションの 1/1024 しか見えない)。そして、不正なキャンセルを送出するための時間枠も、彼が特定のバケットの検証者の 100%を支配している時間枠だけに限定される。

つまり、可視性を一部制限することでプライバシーをいくらか得る道はある。ただし潜在的なリスクを伴う。

  1. 実際のところ、最良のアイデアの火付け役としてあなたに功を譲るべきだ。お見事! 当初、アウトポイントハッシュに署名するアイデアは却下していた。既存の bitcoin アドレスにあまりに似ているように見えたからだ。署名に必要な公開鍵が、あまりに多くのものを関連付けてしまうだろうと思っていた。

ただし、アウトポイントハッシュと現在のブロック番号の組み合わせに署名する 1回限りの公開鍵を使えばどうだろう。アウトポイントハッシュが最初に作られるときには公開鍵とともに記録される。それが使われるときには、ハッシュが、同じ鍵で署名された別の(しかし関連する)署名を持つことで検証される。

これで問題は完全に解決すると思う。追加の関連付けは生じない。なぜなら、ブロックリスト内のアウトポイントハッシュの 2 つの使い捨てインスタンスは関連していなければならないからだ。2 つ目の使い捨て公開鍵識別子を加えても、何も加わらない。

「現在のブロック番号」の問題を簡略化するため、提出者は次の 3〜4個のブロック番号それぞれの署名を提出してもよい。検証者は適切なものだけをブロックに記録する。

これは、私が望んでいたよりもブロックリストにビット数を増やしてしまう。ハッシュだけが最適だと考えていた。

====

次の性質を持つ最小の暗号構造は何か? ハッシュと完全な署名の代わりに考えられるかもしれない。

  1. 私はあなたに任意に見えるものを渡す。
  2. 私はあなたに、あなたの#1 と容易に関連するように見えるが、他の誰の#1 とも関連しないものを渡す。
  3. 他の誰もあなたの#1 からあなたの#2 を割り出せない。

====

たとえば

  1. 私はあなたに Z を渡す。Z = X * Y で、X と Y はどちらも大きな素数
  2. 私はあなたにタプル(X, Y)を渡す
  3. 誰も Z から X と Y を因数分解できない

その場合、オフラインのトランザクションを送信するときは、送信者は各インポイントについて(X,Y)を同梱する。 受信者は新しいアウトポイントごとに新しい(X,Y)を非公開で作る。 受信者は次に各インポイントの(X,Y)をブロードキャストしてキャンセルする。各アウトポイントの Z をブロードキャストして作成する。

これでうまくいくだろうか、それとも単純すぎるだろうか?