IP アドレスの代わりにホスト名を
少なくとも Windows クライアントはホスト名を解決できないようだ。あるいは試みすらせず、すぐに「Invalid Address」とポップアップが出る。
ほとんどの人が動的 IP アドレスを使っていることを考えると、これは大きな後退だ。したがって、「123.123.123.123」だけでなく、「someone-accepting-bitcoins.somedomain.sometld」のようなホスト名にも送信できる機能を追加すべきだ。
銀行サイトなどはエンドツーエンド暗号化を使っており、傍受をより困難にしている。通常、双方向の認証がある。ウェブサイトは個人が選択した画像/フレーズを表示して自身をあなたに認証し、あなたはこれが訪問したかったサイトだと認識する。次にあなたがウェブサイトに認証して、主張する顧客として認識される。完璧ではないが、正直な人を正直に保つために、お金の入った箱に南京錠を付けるようなものだ。時にはより大きく/厚い南京錠を使い、努力/利得の比率からして破ろうとする価値がないようにする。
セキュリティについてはある意味で同意する。不便すぎるとあまり役に立たない…ただし暗号化と認証は一般的に些細な問題を抑止するには十分で、ある程度の安心感を提供する。
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 で買い物をするようなタイプの人間だが。😊
おばあちゃんにとって、bitcoin の概念全体は今のところかなり混乱する。技術的な詳細をすべて無視しても、UI には巨大な数字と文字の文字列（受信アドレス）が表示され、現在のベストプラクティスでは、誰かにアドレスを渡すたびにそれに対処する必要がある。
もう一つの選択肢は、OpenID が使うものに似たもの、つまりストアの（できれば SSL の）サイトの隠しタグを使うことだ。そうすれば、受信アドレスとしてサイトの URL を入力するだけで済む。そのサイトにアクセスして、次のようなものを探す：
<link rel="bitcoin.address" href="19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3">
<link rel="bitcoin.server" href="12.34.56.78">
または他の形式で、安全にそこに送信しようとする。SirArthur は通常のオンライン加盟店のケースについて良い指摘をしている。これは IP 送信オプションがより適している場合だ。加盟店が固定 IP のサーバーを持ち、独自のドメイン名と SSL 証明書を持つケースだ。
IP で接続する代わりに、既存の CA 基盤を使用して、そのドメインの所有者に接続していることを認証しながら、SSL でドメイン名に接続できる。
ユーザーは domain.com（または www.domain.com でも OK）に送信する。これは非常に自然で、ユーザーは入力した内容が支払いたい相手であることを確認できる。
SSL は TOR ユーザーにとっても安全になる。
問題は、加盟店は支払いが何のためのものか確実に把握するために、やはりビットコインアドレスの使用を好むだろうということだ。コメント欄にトランザクションを識別するための正しい情報を入力してくれるとユーザーに期待することは、単純にできない。注文番号でコメント欄を事前入力する mailto スタイルのリンクがあれば実用に近づくが、そのリンクにはビットコインアドレスを入れても同じことだ。
domain.com にユーザーが身元不明の支払いを送信できるオープンなビットコインサーバーを持つだけでは、リスクが大きすぎる。一般ユーザーは支払いを識別する必要があるという考えに慣れていない。加盟店は空白の支払いを大量に受け取り、その後 1 週間後に「支払ったが、商品はどこだ？！」というクレームが来ることになるだろう。
支払いシーケンスには、受取人が受け入れる前に注文を確認するステップがある。有効な注文番号が含まれていない場合、支払いを拒否してエラーメッセージを返すことができる。しかし、それにはビットコインサーバーとカスタムコードの困難なレベルの統合が必要だ。
domain.comにユーザーが身元不明の支払いを送信できるオープンなビットコインサーバーを持つだけでは、リスクが大きすぎる。一般ユーザーは支払いを識別する必要があるという考えに慣れていない。加盟店は空白の支払いを大量に受け取り、その後1週間後に「支払ったが、商品はどこだ？！」というクレームが来ることになるだろう。
支払いシーケンスには、受取人が受け入れる前に注文を確認するステップがある。有効な注文番号が含まれていない場合、支払いを拒否してエラーメッセージを返すことができる。しかし、それにはビットコインサーバーとカスタムコードの困難なレベルの統合が必要だ。
emule 風に、Bitcoin クライアント用のプロトコルハンドラを登録するという手もある。そうすればショップは次のようなリンクを作れる：
bitcoin://address-to-pay-to|amount|order hash or id|some other fields
最終的にはこんな感じになる：
<a href="bitcoin://mybitcoin.com|20|aAAee3322AA67|CustomerId=20><img src="paywithbitcoins.jpg" alt="Pay now" border="0" title="Pay now" /></a>