（laszloのコンテキスト投稿）

銀行サイトなどはエンドツーエンド暗号化を使っており、傍受をより困難にしている。通常、双方向の認証がある。ウェブサイトは個人が選択した画像/フレーズを表示して自身をあなたに認証し、あなたはこれが訪問したかったサイトだと認識する。次にあなたがウェブサイトに認証して、主張する顧客として認識される。完璧ではないが、正直な人を正直に保つために、お金の入った箱に南京錠を付けるようなものだ。時にはより大きく/厚い南京錠を使い、努力/利得の比率からして破ろうとする価値がないようにする。

セキュリティについてはある意味で同意する。不便すぎるとあまり役に立たない…ただし暗号化と認証は一般的に些細な問題を抑止するには十分で、ある程度の安心感を提供する。

PayPalのメールアドレスに送れるのは確かに便利だが、そこでも双方向認証がある。PayPalは送金額をコミットする前に送信先の人の名前を表示する。PayPalは非常に人気があり詐欺だらけだ…もしBitcoinがeBayで受け入れられ、今日のようにIPアドレスベースの送金が使われたら、途中で傍受されるだけなので、TORの有無にかかわらず実現しないだろう。

sshを使ったことがあれば分かるが、あれも双方向認証を使っている。自分の認証資格を提示する前に、サーバーの鍵を目視で確認する。この手法は、初めて接続する場合にどうあるべきか分からないという点で問題がある…サーバーを運用している人に電話して鍵を読み上げてもらう必要がある。URLや他のアドレス表記に入れるというアイデアは、期待するものを宣言し、ピアが異なるものを提示した場合にローカルクライアントが知らせてくれるということだと思う。sshのルートで、提示されたものを受け入れるようにすることもできるだろう…ただし現在、鍵は動的に生成されるので、1日に1回変わる鍵を提示するように変更することもできる…それを支払いを期待しているウェブサイトに表示できるが、それならbitcoinアドレス自体を表示してそちらで送ればいいではないか。

簡略化のポイントがよく分からない…既にアドレスをコピー/ペーストする必要があるなら、それがインターネットアドレスでも、DNSアドレスでも、bitcoinアドレスでも、何が違うのだろうか？

こう考えてみてくれ。BCでサーフェスウェブ*上のショップのようなものを運営する場合（多少遠い将来かもしれないが）、以下のことを望むだろう：

• 顧客を識別できること ― 誰が何を支払っているかを知り、返金を処理できる
• 顧客が支払いと一緒にメモを残せること
• 顧客がフレンドリーなアドレスに支払えること（IPでも読めないハッシュでもなく）― thenerdsshop.comでも運営していない限りは
• 顧客を煩わせないこと

このためにはTLS/SSL機能が明らかに興味深い。こんな操作を想像してくれ：

Client -> BC 50をbcpay.mysite.comに送信 bcpay.mysite.com -> ストアのデータを含む証明書を送信、クライアントにこのサーバーの情報を確認するポップアップが表示される

例： 以下のBitcoinクライアントに支払いを行おうとしています：

SITE NAME: mystore.com COMMON NAME: Payments Gateway CA VERIFIED BY: BitcoinSSL

Client -> 確認？ → 支払いが送信される：支払いがキャンセルされる。

• Torユーザー：自宅に商品を配送するサーフェスウェブのショップだと考えてくれ。どのみちそこには行かないだろう。自宅住所を教えるのにIPを隠す意味は何だろうか？

この2つのアイデアが互いに排他的である理由は分からない。SSL/TLSの実装は簡単ではないと思うが。OpenSSLライブラリには既にリンクしているので、どうだろう。

個人的にはbitcoinアドレスを扱うurnスキームを好む。 それは完璧だろう。ただし、右側にホスト名を使う方が好みだ。

もちろん、thenerdsshop.comで買い物をするようなタイプの人間だが。Smiley

おばあちゃんにとって、bitcoinの概念全体は今のところかなり混乱する。技術的な詳細をすべて無視しても、UIには巨大な数字と文字の文字列（受信アドレス）が表示され、現在のベストプラクティスでは、誰かにアドレスを渡すたびにそれに対処する必要がある。

もう一つの選択肢は、OpenIDが使うものに似たもの、つまりストアの（できればSSLの）サイトの隠しタグを使うことだ。そうすれば、受信アドレスとしてサイトのURLを入力するだけで済む。そのサイトにアクセスして、次のようなものを探す： Code:

または他の形式で、安全にそこに送信しようとする。

SirArthurは通常のオンライン加盟店のケースについて良い指摘をしている。これはIP送信オプションがより適している場合だ。加盟店が固定IPのサーバーを持ち、独自のドメイン名とSSL証明書を持つケースだ。

IPで接続する代わりに、既存のCA基盤を使用して、そのドメインの所有者に接続していることを認証しながら、SSLでドメイン名に接続できる。

ユーザーはdomain.com（またはwww.domain.comでもOK）に送信する。これは非常に自然で、ユーザーは入力した内容が支払いたい相手であることを確認できる。

SSLはTORユーザーにとっても安全になる。

問題は、加盟店は支払いが何のためのものか確実に把握するために、やはりビットコインアドレスの使用を好むだろうということだ。コメント欄にトランザクションを識別するための正しい情報を入力してくれるとユーザーに期待することは、単純にできない。注文番号でコメント欄を事前入力するmailtoスタイルのリンクがあれば実用に近づくが、そのリンクにはビットコインアドレスを入れても同じことだ。

domain.comにユーザーが身元不明の支払いを送信できるオープンなビットコインサーバーを持つだけでは、リスクが大きすぎる。一般ユーザーは支払いを識別する必要があるという考えに慣れていない。加盟店は空白の支払いを大量に受け取り、その後1週間後に「支払ったが、商品はどこだ？！」というクレームが来ることになるだろう。

支払いシーケンスには、受取人が受け入れる前に注文を確認するステップがある。有効な注文番号が含まれていない場合、支払いを拒否してエラーメッセージを返すことができる。しかし、それにはビットコインサーバーとカスタムコードの困難なレベルの統合が必要だ。