IP による送金は新しい公開鍵を要求するから、そう、タイプ 1 の中間者攻撃に 対しては脆弱だ。それが気がかりなら、ビットコインアドレスへの送金には その脆弱性はない。ただし、プライバシーで小さなトレードオフがある。 たぶん人々はビットコインアドレスを SSL でないウェブサイトや署名なしの 平文メールから入手することが多くなるだろうし、そういうのはすでに DNS 汚染を通じてタイプ 1 とタイプ 2 の両方に対して脆弱だ。
確かにそうだが、ビットコインアドレスを使う利点は、2 人の人間が 複数の異なるチャネルでアドレスを照合できる、という点だ。 友人がこちらのウェブサイトからアドレスを取って、何か怪しいと思った場合は、 こちらに電話することも、IM で連絡を取ることも、メールすることもできて、 アドレスを照合できる。攻撃者は、こちらのアドレスを悪意あるものに 置き換えるためには、音声を含むあらゆる通信チャネルすべてで置換を 行わなければならず、これはかなり難しい。ネットワーク アドレスによる直接通信を中間者攻撃する場合には、攻撃者がアドレスを 偽装するか傍受しているので、この利点はない。友人がこちらの アドレスを同じ方法で確認することはできるが、アドレスを確認しても 状況は実質改善されないわけだ。
サトシ・ナカモト一つの解は、送金時に IP とビットコインアドレスの両方を使うこと （たとえば 1.2.3.4-1Kn8iojk… のように）。受信側がビットコイン アドレスの公開鍵で新しい公開鍵に署名して、送金先が本人で間違いないことを 証明する。このシステムが本格的な業務用途で使われ始めたら、必ず実装する。 別の解は SSL を使うことだ。
それは良い解だ。定期的に取引する相手なら、おそらく相手の ビットコインアドレスはすでにアドレス帳に入っているはずだ。
サトシ・ナカモト後回しにしている機能の 1 つに、ウォレットを暗号化するオプションがある。
この話題で思いついたことが 1 つある。システム障害が起きた場合の ビットコイン消失の可能性についてだ。アプリケーションは実行 ディレクトリ内には何もデータを保存していないようなので、おそらく レジストリやその他の場所に保存しているのだろう（まだ ProcessExplorer を 取り出して自分で確認していない）。なので、復旧に必要なすべてを システム外にバックアップできるファイルにエクスポートする機能を入れて おくのは、良いアイデアかもしれない。
サトシ・ナカモトビットコインアドレスだけで済んで、IP は裏で解決される、というのが できれば嬉しい。プライバシーやサービス拒否（DoS）の問題があるかも しれない。新しい送金方式を実装する前に、設計をじっくり考えて ベストな方式かを確認する時間は十分にある。
これは常に任意機能にできる。たとえば「自分のビットコインアドレスを ネットワークに広告する」のオン／オフを切り替えるトグルをユーザーに 持たせるのだ。ビットコインアドレスで検索してもネットワーク上で 見つからない場合は、これまでどおりトランザクションをブロック チェーンに挿入する。見つかった場合は、トランザクションのメタデータを そのネットワークアドレスに通信できる、という形だ。
今日もう 1 つ気づいたのだが、アプリケーションを閉じても ネットワークソケットをきれいに閉じていないようだ（TCP RST が 飛び始める）。優先度の低い todo に入れる項目かもしれない (:
ではまた。
—
Dustin D. Trammell
dtrammell@dustintrammell.com
http://www.dustintrammell.com