私は攻撃を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日06:05 UTC）正しく理解できているか分からないが、ビットコインアドレスによる 取引というのは、取引をブロックチェーンに計算して入れて、受取人に それを「発見」してもらうだけ、という理解で合っているかな？
そのとおりだ。
ダスティン・トランメル代替案として、ネットワークノードに解決サービスを持たせるのも 考えられる。あるビットコインアドレスのネットワークアドレスをノード間で 問い合わせ、対象ノードがオンラインであれば、そのアドレスについて ネットワーク全体の合意が形成されたうえで送信側のビットコインアプリ ケーションが直接接続する、という形だ。
ビットコインアドレスだけで済んで、IPは裏で解決される、というのが できれば嬉しい。プライバシーやサービス拒否（DoS）の問題があるかも しれない。新しい送金方式を実装する前に、設計をじっくり考えて ベストな方式かを確認する時間は十分にある。
Satoshi