私は攻撃を 2 つの種類に分けている：
- 通信経路上に実際にいる者にしかできない攻撃
- インターネット上のどこからでも、誰にでもできる攻撃
タイプ 1 で危険にさらされるのは、自宅や会社の同じ LAN にいる者、 途中の ISP の管理者、受信側の LAN にいる者だ。タイプ 2 で危険に さらされるのは、自分から攻撃者になることを選べる 10 億人で、 彼らは一つの手法を開発すれば複数の被害者に対する規模の経済を得る。
IP による送金は新しい公開鍵を要求するから、そう、タイプ 1 の中間者攻撃に 対しては脆弱だ。それが気がかりなら、ビットコインアドレスへの送金には その脆弱性はない。ただし、プライバシーで小さなトレードオフがある。 たぶん人々はビットコインアドレスを SSL でないウェブサイトや署名なしの 平文メールから入手することが多くなるだろうし、そういうのはすでに DNS 汚染を通じてタイプ 1 とタイプ 2 の両方に対して脆弱だ。
一つの解は、送金時に IP とビットコインアドレスの両方を使うこと （たとえば 1.2.3.4-1Kn8iojk… のように）。受信側がビットコイン アドレスの公開鍵で新しい公開鍵に署名して、送金先が本人で間違いないことを 証明する。このシステムが本格的な業務用途で使われ始めたら、必ず実装する。 別の解は SSL を使うことだ。
今のところ、IP に送るときは受取人について他の識別情報を渡していない わけだから、その IP に応答する誰かに対して目隠しで送っていることに なるのは明白だ。
後回しにしている機能の 1 つに、ウォレットを暗号化するオプションがある。
ダスティン・トランメルのメール（2009年1月15日 00:05 UTC）正しく理解できているか分からないが、ビットコインアドレスによる 取引というのは、取引をブロックチェーンに計算して入れて、受取人に それを「発見」してもらうだけ、という理解で合っているか？
そのとおりだ。
ダスティン・トランメル代替案として、ネットワークノードに解決サービスを持たせるのも 考えられる。あるビットコインアドレスのネットワークアドレスをノード間で 問い合わせ、対象ノードがオンラインであれば、そのアドレスについて ネットワーク全体の合意が形成されたうえで送信側のビットコインアプリ ケーションが直接接続する、という形だ。
ビットコインアドレスだけで済んで、IP は裏で解決される、というのが できれば嬉しい。プライバシーやサービス拒否（DoS）の問題があるかも しれない。新しい送金方式を実装する前に、設計をじっくり考えて ベストな方式かを確認する時間は十分にある。
Satoshi