サトシ、ありがとう。
これが彼に送った内容だ。
公開鍵暗号は、大きな素数を素因数分解するのが難しいという事実に依存している。それは誰もが知っている。もし bitcoin の送金がきちんと形成された公開鍵に割り当てられ、将来の送金のために対応する秘密鍵による署名が必要なら、bitcoin の暗号的送金は完全に安全だと認めるだろう。
しかし、私の読み取りでは、bitcoin のトランザクションはそのようには動いていないようだ。トランザクションはコインの金額を特定の「bitcoin アドレス」に割り当てる。そしてそのアドレスは公開鍵のハッシュだ。
トランザクションを検証するために、ノードは署名から公開鍵を取り出し、それを使って実際の署名を検証する。署名が有効なら、その公開鍵をハッシュ化して、前のトランザクションで割り当てられた bitcoin アドレスと一致するか確認する。両方が一致すれば、定義上、そのトランザクションは正当だ。
潜在的な弱点は、署名内の公開鍵を bitcoin アドレスと結びつける部分にある。
公開鍵とあるハッシュ値の間には多対一の関係がある。さて、公開鍵部分が特定の bitcoin アドレスにハッシュ化されるような、安全な公開鍵／秘密鍵ペアを作る素数の組を見つけるのは難しそうだ……たぶん難しい。
しかし、それは必要ない。
必要なのは、既知の大きな bitcoin 口座とハッシュが衝突する、公開鍵を表す「何か」だけだ。素数に基づく安全な鍵ペアである必要は全くない。1回だけ機能して、盗んだお金を別の口座に送れればそれでいい。それは潜在的にずっと簡単だ。
ハッシュによっては衝突させるのが他より難しいものもある。使われているハッシュの強度はわからない。だが、ハッシュ化される内容を気にしなくていいなら、どんなハッシュでも衝突させるのはずっと簡単になる。
公開鍵はその性質上、ランダムなデータのように見える。私が理解する限り、公開鍵が安全な数学に基づいているかどうかは、それを素因数分解できない限りわからない。したがってクライアントは試さない。普通は署名の検証だけを行い、それが通れば公開鍵は安全な方法で生成されたものだと前提する。
注：以下の分析は本物の暗号ハッカーによるダブルチェックが必要だ。私は暗号研究者ではない（IANACR）。
つまり、ハッシュ次第で、新興のハッシュ衝突アルゴリズムの一つを使って、公開鍵を表す衝突データブロックを生成できる。それから公開鍵／秘密鍵の数学を逆算して、有効な署名を生成できる、対応する（しかしまったく安全ではない）秘密鍵を生成する。
次に、その安全でない、簡単に分解できる鍵ペアを使って、対象の bitcoin アドレスに一致する署名済みトランザクションを生成する。
トランザクションログは、コインが意図された完全な公開鍵を検証できないので、提示されたものがそうだったに違いないと前提するだけだ。
送金先の完全な公開鍵をブロックリストに記録すれば、本来の強度を取り戻せる。しかしその場合、34 文字のアドレスを使い回す利便性は失われる。
もし的外れなことを言っているなら、時間を無駄にさせて申し訳ない。
ではまた！ Red