Bitcoin用URIスキーム
こんにちは、ビットコインのシステムに興味を持ち、一つアイデアがある：
ビットコインアドレスは、例えばトレントのマグネットリンク (http://en.wikipedia.org/wiki/Magnet_URI_scheme)のようなURIスキーム (http://en.wikipedia.org/wiki/URI_scheme)を実装することで改善できるだろう。
つまり、1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZの代わりに、より明確にbitcoin:?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZと表記でき、さらにブラウザーでこのようなリンクのクリックをビットコインクライアントにリダイレクトするよう設定できる。これにより、ホームページに「寄付ボタン」を、ウェブショップに「支払いボタン」を実装できるようになるだろう。
IPを含める必要がある場合、URIではbitcoin://HOST_OR_IP:PORT?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZと記述できる。希望すれば金額もbitcoin:?amount=42.00;addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZのように指定できる（もちろんユーザーがセキュアなビットコインクライアントで確認するためのものだ）。
以上、0.02 ฿ 分の私見だ（気に入らなければbitcoin:?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZに返してくれ）
URIスキームはQRコードを使ったモバイルウォレットの実装にも役立つだろう。X bitcoinを払いたい友人がBitcoinアドレスを手動で入力する必要がなく、自分の携帯電話の画面を撮影するだけで済むようになる。
ああ、私もまったく同じことを考えていた。マグネットリンク方式は最高だろう。😁
それはものすごく素晴らしいだろうな……😊
このアイデアについて誰か何かしているのか気になっている。このスレッドとここで説明されている素晴らしい開発に従って、インターネットブラウザー機能の実装の可能性を調査しているところだ。まずこれを試して、Firefoxアドオンが発展する中で他の機能と一緒に含めるのが、より簡単な最初の一歩かもしれない（学びながら進めている）。
これが実現する前に、URIがどのような形式を取るかについてコンセンサスが必要だ。URIスキームについて少し調査したが、W3Cの承認なしのほとんどのアプローチは好ましくないとされている。W3Cが暫定的なURIスキームを承認して保留にするカテゴリーがあるが、保証はない（仮特許のようなもの）。しかし、最も適切なスキームはマグネットURIのようだ。特定のアドレスではなく、コンテンツの一意性から生成されるハッシュによってリソースを見つけるよう設計されている。マグネットはピアツーピアネットワーク上のアプリケーションでの使用を意図しており、アプリケーション固有のデータへの参照用の予約パラメーターがある。基本的に、アプリケーション固有のパラメーターの前にxを付けるだけだ。例：xbitcoin1:?
新しいトップレベルURIスキームの実装を試みないのが良いかもしれない。普遍的に認識されていなければ、即興的な手法と見なされるからだ。マグネットシステムの採用はこれを回避するが、マグネット自体も非公式の未登録スキームだ。マグネットの利点は共有可能でオープンなことだ。
これは非常に良さそうに見えるかもしれない。bitcoinは結局P2Pアプリケーションであり、そのネットワークは似た原理で動作しているからだ。しかし、リンクをクリックする人がbitcoinユーザーでない場合はどうか？ 既存のネットワークに含まれない情報、例えば販売する商品、配送情報、その他の問題を組み込みたい場合はどうか。bitcoinはトランザクション自体のみを処理するという理解なので、ユーザーは他のすべての取り決め、契約、コミュニケーションをbitcoinとは独立に行う必要がある。ここで匿名性が損なわれる。従来の「階層的なハードワイヤード、または非匿名の技術」に頼る傾向があるからだ。これはbitcoinへの批判ではまったくない。bitcoinは素晴らしいトランザクション方法だ。しかし、トランザクションはコインの片面にすぎない（このべたなダジャレを許してもらえるなら）。😄
URIの調査過程でfreenetと彼らが使うマグネットに似たシステムを思い出し、結局そこに戻ってチェックした。freenetが情報保存を意図したユーザー/アイデンティティ空間であるなら、各ユーザーに固有の人間可読なデータファイルのリポジトリとしても使えないだろうか。トランザクションの補足に使いたい任意の形式のデータを組み込める。これをURIからアプリケーション固有のリッチなデータベースに接続するために使えないだろうか。bitcoinノードが実際のトランザクションを処理する間、freenetノードが個別のデータの提示を処理する。
これにより、すべてが同じ種類の暗号P2Pインフラストラクチャの下に保たれ、アプリケーション固有のコンテキストの無限の多様性が可能になるはずだ。ユニークなURIハッシュキーは、freenet+bitcoinのハッシュの組み合わせから生まれ、freenetキーで暗号化されたファイルはbitcoinキーで復号して見つけ、bitcoinノードにはその逆でアドレスできるのではないか。これで合っているかな？ もちろん、一方で実名を使えば、もう一方でも実名が明らかになるだろう。
いずれにしても、何らかの方法があるはずだ。繰り返すが、freenetも未登録のURIスキームを使っているが、マグネットの変形が採用されればそれは問題にならない。残る疑問は、bitcoinが正式に認められた通貨として非常に正当なものになることを望むなら、他のすべてのインターネットプロトコルへの厳格な準拠が望ましいかもしれないということだ。マグネット/freenetのようなURIスキームの登録を妨げるものは特に見当たらなかった。すべてを検索してはいないが、既に存在するかもしれない。なければ、登録してしまえばいいのでは？
URIスキームの分類（どの種類のマグネットなのか、正式/公式にするかどうか）とレイアウトの形式について合意する必要がある：
URIの構成要素
これはMozillaがURIのパース時に考慮する規則に関するものだ。
典型的なマグネットURIはこのようになる：
magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C
freenet URIはこのようなものだ：
http://127.0.0.1:8888/USK@oshw3DxmJUt7q4ThF4dCez5IXbc9hCGcv0VuwLRCmeQ,ckeXv20F1gBzkqssB4RXHZ2nB1YRT8Pb8KYZk8wj-bs,AQACAAE/occamsrazor/6/f.pdf
認識されるためにはfreenetプログラムをインストールする必要があり、これにはリソースをlocalhostのアイデンティティ空間のアイテムとして認識するJava搭載のウェブサーバーが含まれる。つまり、ブラウザーからはfreenet全体が自分のマシン上にあるように見える。ユーザーがウェブサーバーを実行せずにこのアイデンティティ空間をアドレス可能にできるかは分からないが、サーバーはウェブページの提供とlocalhostをトップレベルドメインとして認識するためだけに必要だと思われる。「http:」はfreenet URI自体が特別なものではないことを示しているが、IPアドレス（localhost）は確かに特別だ。プログラムがウェブサーバーを組み込まずにfreenetユーザー空間にアクセスでき、ユニバーサルリンクはマグネットURIとして作成できるのではないかと思う。bitcoinがインストールされていない人に対して、そのリンクの訪問者をbitcoinのSourceForgeダウンロードにリダイレクトするデフォルトのフォールバックをURIに持たせる方法は分からない。コード内で実装し、bitcoinの存在を記録するためにcookieや環境変数を設定する必要があるかもしれない。
この調査中に訪れた他の関連サイト：
http://infomesh.net/2001/09/urischemeshttp://www.search.com/reference/Magnet:_URI_schemehttp://magnet-uri.sourceforge.net/http://magnet-uri.sourceforge.net/magnet-draft-overview.txthttp://www.w3.org/Addressing/schemeshttp://www.w3.org/Addressing/schemes#Registration
アイデア/コメント/フィードバックは歓迎する。😉 Steve
これが実現する前に、URIがどんな形を取るかについて合意が必要だ。[snip] ……最も適したスキームは、特定のアドレスではなく、コンテンツの一意性の産物であるハッシュによってリソースを見つけるように設計されたmagnet URIのようだ。 [snip] magnetの美点は、共有可能でその意味で開かれていることだ。
magnetリンクをすでにある程度普及しているからという理由だけで使っても、欠点を上回るメリットはないと思う。magnetリンクはピアツーピアネットワーク上のファイルまたはファイル群を参照するために設計されたもので、よく知られているパラメーターはどれもファイル（ファイル名、サイズなど）を指す。bitcoinはアプリケーション固有のxBitcoinパラメーターに頼ることになるし、ファイルとbitcoinトランザクションを1つのリンクに混在させたいわけでもない。だから、独自の別フォーマットを使わない説得力のある理由は特にない。ましてmagnetリンクも公式に認められているわけではないのだから。
KarmicadsURIを調べる過程でfreenetと、彼らが使うmagnet風のシステムを思い出して、また見に行ってみた。[snip] これを使えば、出版者自身のウェブサイトの機能やビジネスシステム向けに設計された、アプリケーション固有データのリッチなデータベースにURIを連結できないか？ bitcoinノードが実際のトランザクションを処理する一方で、freenetノードが個別に提示されるデータを処理する。
うわっ！ Bitcoinクライアントを起動するだけの軽量なURLハンドラから、Freenetを必要とするところまで行くのは少し飛躍だ。これは本当にオプションであるべきだ。
ただ、トランザクションに追加情報を付けられるのは確かにとても良い。ecの最初の投稿と、さらなる詳細が必要だという点を踏まえ、以下のURLパラメーター（あるいはその短縮版）を持つべきだと思う。
- address: bitcoinの送信先アドレス。人ごとに異なるアドレスを渡せるので、これは送信者の識別にもなりうる。
- amount（オプション）: 送る金額。
- message（オプション）: トランザクションを説明する短いメッセージ（Bitcoinクライアントのフィールドと同じ）。
- details（オプション）: トランザクションの詳細をエンコードしたURL。たとえばオンラインショップでの購入なら、購入の詳細にリンクできる。これ自体がフル機能のURLになるので、匿名性を保つためにfreenetやi2p、torにリンクすることもできる。
速報：…
ちょうど、freenet上の保存されたデータファイルと対話するための既存のプロトコルがあるようだ。😄 ＜やった！＞ 😄
申し訳ない、自分が提案したfreenet URI機能に合意しなければならないとは思っていない。ただ、実験目的であっても非常に簡単に組み込めることがワクワクするということだ。事前設定されたfreenetサーバーにアドレスするだけでうまくいくはずだが、既存のコードを少し修正して直接freenetにアドレスすることもできるかもしれない（正式なfreenetインストールに含まれる暗黙のウェブサーバーなしで）。このFCPコードをブラウザーアドオンに含めることで、フルのfreenet HTTPサーバーのオーバーヘッドなしに、アドレッシングと通信の機能だけを組み込めるかもしれない。この時点では、freenetウェブサーバーはクライアントがfreenetをブラウジングするためだけに必要で、ノードのサービスには不要だと想定している。Bitcoinは既に同様のP2Pネットワークにアドレスしているので、bitcoinサーバーにfreenetの問い合わせをさせるのはどの程度難しいだろうか？ そのようなトリックをJSONインターフェースに含めることはできるだろうか？
参照：http://new-wiki.freenetproject.org/FCPv2
つまり、自由にfreenetからデータを取り出し、freenetにデータを投稿できるようだ。 ものすごーく興味深い。
それとは別に、freenet URI統合のプロキシや回避策を探す過程で、ISPがVoIP/SIPをブロックしているという無関係な問題を解決できたと思う（ローカルの電話会社でもあるので。そう、もうすぐプロバイダーを変更する）。VoIPが欲しいのだが、反競争的なクソISPがモデムのファームウェア（内蔵の2ポートアナログ電話アダプター付き）の機能を削いでいる。この回避策（Tor）でうまくいくことを願っているが（期待はしていない）。Link2VoIP、もし読んでいるなら、あなたの方を見ているよ。😉
やあ、DataWraith
DataWraithの投稿（2010年5月1日13:40 UTC）magnetリンクをすでにある程度普及しているからという理由だけで使っても、欠点を上回るメリットはないと思う。
誤解させていたらすまない。ほかの人たちとよく検討したり合意したりしないままmagnetリンクを使うつもりはないし、ひとまず支持しているのも、すでに普及しているからではない。正直なところ、うわべの人気には、できるだけ左右されたくない。自分の考えでは、magnet URIを検討する理由は、明記された目的と仕様の草案 (http://magnet-uri.sourceforge.net/magnet-draft-overview.txt)にある。
MAGNETは策定中のURI仕様であり、ウェブサイトが、ローカルのユーティリティープログラムの提供する機能とシームレスに連携できるようにするための、標準的な慣行と実装コードの集まりである。ある意味では、FreenetとEDonkey2000のピアツーピアネットワークがそれぞれ使う「freenet:」と「ed2k:」のURIスキームを、特定の企業やプロジェクトに依存しない形で一般化したものと考えることもできる。
明記された目的は、まさに、ウェブサイトがローカルのユーティリティープログラムの機能とシームレスに連携できるようにすることだ。特定の企業に依存せず、車輪の再発明を避け、ほかのURIスキームとのこれ以上の衝突を避けることを意図している。W3Cの標準にも厳密に準拠していて、magnetの約束事を使うスキームなら、その厳密さを受け継ぐことになる。
DataWraithURIの形式についての注記：
確かに、「:」のすぐ後に「?」が来るのは少し奇妙に見えるが、関連するURL/URIのRFCを私が読んだ限りでは、推奨される共通のURI構文にうまく合っている。（パラメーターが個々のローカルアプリに渡される方法ともうまくかみ合う。）
参考までに、EDonkeyのURIは、RFC 1738と2396の多くの条項に違反している。階層的でない名前空間の先頭に「//」を使っていることや、（エスケープされていない場合に）不正または非推奨の文字を使っていることなどだ
パラメーターの名前と値は、正式には、HTTPのウェブフォームのGET送信のクエリー文字列と同じように、www-formencodedされるべきである。ただし実際には、HTMLの仕様やRFC 1738を厳密に読めばエンコードすべきとされる文字（「.」や「:」など）の一部は、エンコードされていないようだ。
接頭辞「x.」は、アプリケーション固有の新しいパラメーターを試すために予約されている。「x.」で始まらないパラメーターは、正式なMAGNET仕様によってのみ定義される。
ほかに考えられるパラメーターとしては、P2Pで見つからないコンテンツのための「代替の所在」、P2Pシステム固有の識別子（ed2k、sig2dat、freenet）、そのほかのトピックの修飾子（「長さ」）などがある。これらはまだ設計されておらず、意見を求めている。
magnetリンクはピアツーピアネットワーク上のファイルまたはファイル群を参照するために設計されたもので、よく知られているパラメーターはどれもファイル（ファイル名、サイズなど）を指す。
すまないがDataWraith、失礼ながら同意できない。まず、ハードドライブ上のファイルは、入れ子になった場所の階層的な名前空間、つまりドメインとディレクトリに対応づけられている。多くのP2Pネットワークのやり方が根本的に違うのは、名前空間が階層的でなく、扱うデータがアドレスではなく内容の一意性によって参照される点だ。対象がファイルであれ何であれ、決まった固定のアドレスによってではなく、固有の内容の同一性によって参照される。同一のファイルは本質的に同じものであり、P2Pアプリケーションは、複数のインスタンスを同じ対象への複数の供給元として使える。magnetのパラメーターは、どんなP2Pアプリケーションにもよく合っている。
DataWraith例で示すMAGNET URI：
(1)
magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C
意味：与えられたURI（具体的にはURN）が示す「完全一致トピック」（xt）に関する選択肢を表示せよ
(2)
magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C&dn=Great+Speeches+-+Martin+Luther+King+Jr.+-+I+Have+A+Dream.mp3
意味：この完全一致トピックに関する選択肢を表示せよ。ただし利用者の便宜のため、含まれている（検証されていない）「表示名」を使え
(3)
magnet:?kt=martin+luther+king+mp3
意味：文字列で与えられた「キーワードトピック」（kt）に関する選択肢を表示せよ
(4)
magnet:?xt.1=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C&xt.2=urn:sha1:TXGCZQTH26NL6OUQAJJPFALHG2LTGBC7
意味：与えられた二つの完全一致トピックに関する選択肢を表示せよ
(5)
magnet:?mt=
http://weblog.foo/all-my-favorites.rss意味：与えられたURIから取得できる「マニフェストトピック」（mt）に関する選択肢を表示せよ。これはURNでもよい。マニフェストトピックには、ほかの項目の一覧が含まれる。
うわっ！ Bitcoinクライアントを起動するだけの軽量なURLハンドラから、Freenetを必要とするところまで行くのは少し飛躍だ。これは本当にオプションであるべきだ。
いや、実際にはURNハンドラーだし、君の言う「重さ」に上限を決めたわけでもない。それより自分は、堅牢であることと、自分自身が身動きの取れない状態に追い込まれないことのほうを気にする。後方互換性と将来の拡張性を最初から考えておくための手間は、自分の考えでは小さな代償だ。いずれにせよ、これはまだ検討しているだけで、freenetをインストールせずにできればと思っている。（自分の予想どおり）freenetのウェブサーバー全体が必要でないなら、少なくとも、freenetとの読み書きに必要なコードの塊はずっと小さくて済むはずだ。それから、URIには当然、このfreenetの機能をオプションのパラメーターとして含めるべきだ。そうすれば、指定されなくても、基本的な取引に必要な情報はそのまま有効になる。URIを公開するときに使うことは必須にならないが、使われた場合には、ハンドラーはそのパラメーターを受け取れるようにしておくべきだ。そうでなければ、君が提案しているオプションの選択は、互換性のない二つの別々のURIスキームのどちらかを選ぶことになってしまう。念には念を入れよ、だ。
DataWraithただ、トランザクションに追加情報を付けられるのは確かにとても良い。ecの最初の投稿と、さらなる詳細が必要だという点を踏まえ、以下のURLパラメーター（あるいはその短縮版）を持つべきだと思う。
- address: bitcoinの送信先アドレス。人ごとに異なるアドレスを渡せるので、これは送信者の識別にもなりうる。
- amount（オプション）: 送る金額。
- message（オプション）: トランザクションを説明する短いメッセージ（Bitcoinクライアントのフィールドと同じ）。
- details（オプション）: トランザクションの詳細をエンコードしたURL。たとえばオンラインショップでの購入なら、購入の詳細にリンクできる。これ自体がフル機能のURLになるので、匿名性を保つためにfreenetやi2p、torにリンクすることもできる。
アドレスというのが何を指しているのか、よく分からない。bitcoinの署名が与える「アドレス」（場所というより名前に近い）以外には思い当たらない。すでに何かの別名を決めてあるのでない限り、人ごとに違うアドレスを渡せる理由が分からない。つまり、bitcoinノードの別名を符号化して変換する命名の仕組みを追加しようということ？ そういう意味なら、それほど手間をかけずにできるだろう。
金額：うん、言うまでもない。
メッセージ：ここでURIのデータは扱いにくくなる。メッセージというのは、当然、人と人とのそれなりの量のやり取りのことで、URIそのものの中で届けることは想定されていなかった。補足の文書を参照する必要が出てくるのは、ここからだ。支払う側は、ソフトウェアの画面（単体のプログラムでも、Firefoxのアドオンでも）でメッセージを送れる。リンクは最低限、ソフトウェアに渡さなければならない受取人と金額を示す。受け取る側が何か文章を伝えたいなら、自分が公開している文書（つまり、リンクを載せている場所）で伝えればよい。送る側の文章は通常の経路を使えばいい。リンクがbitcoinの画面を呼び出し、そこにメモを書き込む欄があるのだから。受け取る側（支払いを受ける人）が伝えなければならないメッセージで、リンクを載せている文書の中では伝えられないものが何かあるだろうか？ 支払う側が伝えなければならないメッセージで、画面ではできないのに、リンクをクリックすればできるものが何かあるだろうか？ もしあるなら、リンクがpostやgetのようなメソッドを呼び出すことになる。それはhttp/sだけの機能で、専用のURIスキームを持つ意味がなくなる。PostとGetの機能は、TCP/IPの階層的な名前空間や、物理的なファイルパス名の中で扱う必要がある。
詳細：自分は最初から、URIスキームが、必須のパラメーターで渡される基本的な情報を補える、より豊かなデータ構造を持つ文書を参照できることが望ましいと主張してきた。それらの文書の置き場所の案も出した。それにはアクセスのしやすさの問題が伴ったが、解決できれば、bitcoinノードの匿名性を高め、P2Pでない、つまり階層的な名前空間への依存を避けられる。美しいネットワークのアドレス指定のプロトコルを、後退した、劣った、ひどく醜いものに（あるいは無理やり継ぎ足して）写し替えるなど、すべての主体に固定の場所という発想を押しつけ、移動すれば組み込まれた関連づけを全部失うようなものだ。自分には、美しい石造りの建物に安っぽいプラスチックの塗料を、それも明るい緑色の塗料を塗るのと同じくらい無神経に思える。パラメーターにURLを使うことこそ、自分が避けたいぶち壊しだ。URLはURNではなく、それが指す名前空間は階層的で、最終的には固定のIPに置かれていなければならないからだ。
この 「匿名性を保つためにfreenetやi2p、torにリンクすることもできる」という点について言えば、君は明らかに、あまりよく考えていない。freenetにリンクするだけでいいのなら、最初からfreenetを、URIが参照する置き場所そのものとして組み込んでも同じことだ。そこが問題なのだ。freenetにファイルを置いておくだけで、普通のウェブサイト上のURLやURNで誰でも取り出せると期待することはできない。訪れた人がそのリンクを扱うクライアントソフトウェアを持っていない限り、そのリンクが示す参照は役に立たない。URIハンドラーがfreenetの名前空間を指せるようにできるのなら、最初からファイルをそこに置くほうがずっとよいと思う。http/sは階層的な名前空間の上で動き、P2Pのクライアントは階層的でない名前空間の上で動くので、一つのパラメーターで両方を相互に指すことはできない。物理的な場所に自分の身元を結びつけてしまった後で、匿名になろうと決めても遅すぎる。
誤解していたら申し訳ない、DataWraith。だが君は、二つの名前空間のモデルの違いも、それぞれの長所と短所も、よく分かっていないように見える。自分は今でも、ほかのどんな方式でも喜んで検討する。君の批判を頭ごなしに退けているわけでも、自分の好みを標準にすべきだと言い張っているわけでもない。何にせよ、できる限り最良のURIスキームを作りたいだけだ。いずれにしても、考えてくれてありがとう。
編集:
「金額：うん、言うまでもない。」という自分のコメントについては、撤回する。リンクを支払いのきっかけとしてだけ考えていたが、もちろん、金額やほかのパラメーターが空欄なら、支払う側の求めに応じて支払いを始めるための、相手を示すリンクとして働くのが既定になるべきだ。簡単な寄付ボタンなら、パラメーターは一つで済み、転送もログインも確認も、金額の計算や通貨の変更も要らずに、すぐに送れる。クレジットカードを持っていなくても、自分の送金が、馬で運ぶ郵便にまで置いていかれるような遅さを味わわずに済む。（ざまあみろ、PlayPal）。それと、DataWraithが提案した命名の別名、いわゆる（アドレスを持つ）という案は、君の意図がそういうことならだが、自分のbitcoinにぜひ実装する価値がある。😉
Karmicads、時間を割いて詳しく返信してくれてありがとう。
Karmicadsの投稿（2010年5月2日02:15 UTC）ちょうど、freenet上の保存されたデータファイルと対話するための既存のプロトコルがあるようだ
ああ、Freenetの利用について言っていたのはそういう意味だったのか。ユーザーがFreenetを実行し、BitcoinがFreenetの制御プロトコルを使って通信する。しかし、Freenetの実行にはかなりのコンピューターリソース、特に帯域幅が必要であり、個人的にはそれだけの理由でFreenetノードを動かしたくない。だからこれをオプションにしたかった。
Karmicadsの投稿（2010年5月2日07:07 UTC）誤解させていたらすまない。ほかの人たちとよく検討したり合意したりしないままmagnetリンクを使うつもりはないし、ひとまず支持しているのも、すでに普及しているからではない。
既存の仕組みを再発明したくないという印象を受けた。そしてだからこそ普及度が重要で――他のソフトウェアでのmagnetリンクの既存の受容がプラスだった。
Karmicadsの投稿（2010年5月2日07:07 UTC）DataWraithの投稿（2010年5月1日13:40 UTC）magnetリンクはピアツーピアネットワーク上のファイルまたはファイル群を参照するために設計されたもので、よく知られているパラメーターはどれもファイル（ファイル名、サイズなど）を指す。
すまないがDataWraith、失礼ながら同意できない。まず、ハードドライブ上のファイルは、入れ子になった場所の階層的な名前空間、つまりドメインとディレクトリに対応づけられている。多くのP2Pネットワークのやり方が根本的に違うのは、名前空間が階層的でなく、扱うデータがアドレスではなく内容の一意性によって参照される点だ。対象がファイルであれ何であれ、決まった固定のアドレスによってではなく、固有の内容の同一性によって参照される。同一のファイルは本質的に同じものであり、P2Pアプリケーションは、複数のインスタンスを同じ対象への複数の供給元として使える。magnetのパラメーターは、どんなP2Pアプリケーションにもよく合っている。
分かった、すまない。ここで自分の言いたいことをはっきり伝えられていなかったようだ。magnetリンクがコンテンツを参照する仕組みは理解している。
おそらくメンタルモデルの違いだろう：自分にとって、Bitcoinのトランザクションは、適切な言葉がないが、ものというよりはプロセスだ。自分の認識では、magnetリンクはもの（通常はファイル――コンテンツハッシュまたは場所による）を参照するものであり、プロセスを参照するために使おうとするのは少し不自然に感じる。magnetリンクは取得しに行く必要があるものを特定するが、Bitcoinのトランザクションはリンク自体で完全に記述される（リンクをクリックした後に「はい、コインを送ります」と言う必要はあるが）。
自分には、magnetリンクを本来の目的ではないものに（悪）用することのように思える。magnetリンクはed2k://やfreenet://などの代替として、ファイルの取得方法を記述するために生まれたものだからだ。
Bitcoinリンクは、magnet:よりもmailto:に近いものであるべきだと思う。
Karmicadsの投稿（2010年5月2日07:07 UTC）いや、実際にはURNハンドラーだし、君の言う「重さ」に上限を決めたわけでもない。
ああ、自分の間違いだった、すまない。
Karmicadsの投稿（2010年5月2日07:07 UTC）いずれにせよ、これはまだ検討しているだけで、freenetをインストールせずにできればと思っている。（自分の予想どおり）freenetのウェブサーバー全体が必要でないなら、少なくとも、freenetとの読み書きに必要なコードの塊はずっと小さくて済むはずだ。
確か、ウェブサーバーはFreenet自体にかなり統合されている。よりシンプルなFCPプロトコルを使ってFreenetインスタンスと通信することもできるが、Freenet上のコンテンツの性質上、公開アクセス可能なインスタンスをホストする人は多くないので、自分で運用する必要がある。それを望むこと自体を悪く思ってはいないが、自分はやる気がないだけだ。むしろTORの隠しサービスをホストしたい――だからdetailsパラメーターにFreenet固有ではなく汎用的なフルURLを使うことを提案した。
Karmicadsの投稿（2010年5月2日07:07 UTC）
- address: bitcoinの送信先アドレス。人ごとに異なるアドレスを渡せるので、これは送信者の識別にもなりうる。
- amount（オプション）: 送る金額。
- message（オプション）: トランザクションを説明する短いメッセージ（Bitcoinクライアントのフィールドと同じ）。
- details（オプション）: トランザクションの詳細をエンコードしたURL。たとえばオンラインショップでの購入なら、購入の詳細にリンクできる。これ自体がフル機能のURLになるので、匿名性を保つためにfreenetやi2p、torにリンクすることもできる。
アドレスというのが何を指しているのか、よく分からない。bitcoinの署名が与える「アドレス」（場所というより名前に近い）以外には思い当たらない。すでに何かの別名を決めてあるのでない限り、人ごとに違うアドレスを渡せる理由が分からない。つまり、bitcoinノードの別名を符号化して変換する命名の仕組みを追加しようということ？ そういう意味なら、それほど手間をかけずにできるだろう。
まあ、bitcoinの署名のことだ。Bitcoinクライアントにそう表示されているから「アドレス」と呼んだ（「アドレスを変更」と表示される）。交換サイトが現在行っているように、異なるエイリアスを使うべきだと確かに考えていた：コインを送るアドレス（または署名、あるいは何でも）を受け取り、そのアドレスはあなたにだけ渡されたものなので、受取人は支払いがあなたからだと分かる。
エイリアスを変換するシステムはもちろん良いが、それはアドレス帳やmybitcoin.comなどで処理する方がよいと思う。
Karmicadsの投稿（2010年5月2日07:07 UTC）メッセージ：ここでURIのデータは扱いにくくなる。メッセージというのは、当然、人と人とのそれなりの量のやり取りのことで、URIそのものの中で届けることは想定されていなかった。受け取る側が何か文章を伝えたいなら、自分が公開している文書（つまり、リンクを載せている場所）で伝えればよい。送る側の文章は通常の経路を使えばいい。リンクがbitcoinの画面を呼び出し、そこにメモを書き込む欄があるのだから。受け取る側（支払いを受ける人）が伝えなければならないメッセージで、リンクを載せている文書の中では伝えられないものが何かあるだろうか？
そう、まさにその通りだ！ 送信側のテキストは通常のルートでよい。だが、送信されるテキストを事前に指定したい場合はどうか？
これにはmailto:リンクのアナロジーがある：誰かにメールを送ってほしい場合、使うべきsubjectも指定できる：mailto:alice@example.org?subject=Test。だから、例えばeBayで何かを売っている場合、「eBayオークション#12345の支払い」というメッセージを含むBitcoinリンクを買い手に渡せば、本人が入力する必要がなくなり、コードが#12345より暗号的な場合にミスを防げる。
Karmicadsの投稿（2010年5月2日07:07 UTC）詳細：自分は最初から、URIスキームが、必須のパラメーターで渡される基本的な情報を補える、より豊かなデータ構造を持つ文書を参照できることが望ましいと主張してきた。それらの文書の置き場所の案も出した。それにはアクセスのしやすさの問題が伴ったが、解決できれば、bitcoinノードの匿名性を高め、P2Pでない、つまり階層的な名前空間への依存を避けられる。美しいネットワークのアドレス指定のプロトコルを、後退した、劣った、ひどく醜いものに（あるいは無理やり継ぎ足して）写し替えるなど、すべての主体に固定の場所という発想を押しつけ、移動すれば組み込まれた関連づけを全部失うようなものだ。自分には、美しい石造りの建物に安っぽいプラスチックの塗料を、それも明るい緑色の塗料を塗るのと同じくらい無神経に思える。パラメーターにURLを使うことこそ、自分が避けたいぶち壊しだ。URLはURNではなく、それが指す名前空間は階層的で、最終的には固定のIPに置かれていなければならないからだ。
すまない、URI、URLなどの用語をアドレスバーに入力するからつい混同して使いがちだ %)。混乱させたなら申し訳ない。
ここで自分が望んでいたのは、この追加情報を汎用的にすることだ。いくつかの例で明確になるかもしれない：
https://www.myonlineshop.com/purchaseDetails/123456http://pastie.org/942292- freenet://[Freenet上のリソース]/
http://kpvz7ki2v5agwt35.onion/wiki/index.php/PurchaseDetailsHere- magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C
リンクの作成者が追加情報の置き場所を選び、受取人がFreenet/Tor/I2Pをインストールするほど補足情報が必要かどうかを判断する。これがリンク自体に短いメッセージを含める理由の一つだ：追加情報はトランザクションに不可欠であるべきではない。
Karmicadsの投稿（2010年5月2日07:07 UTC）この 「匿名性を保つためにfreenetやi2p、torにリンクすることもできる」という点について言えば、君は明らかに、あまりよく考えていない。freenetにリンクするだけでいいのなら、最初からfreenetを、URIが参照する置き場所そのものとして組み込んでも同じことだ。
だが、それだとFreenetの使用が必須にならないか？ もっと柔軟であってほしい。
また、オンラインショップを運営する場合、Freenetをインストールさせるよりも、自分のウェブサイトで詳細を確認してもらう方がよい。Freenetの評判を考えると、ショップの評判がFreenetと結びつくのは望ましくないかもしれない。
Karmicadsの投稿（2010年5月2日07:07 UTC）そこが問題なのだ。freenetにファイルを置いておくだけで、普通のウェブサイト上のURLやURNで誰でも取り出せると期待することはできない。訪れた人がそのリンクを扱うクライアントソフトウェアを持っていない限り、そのリンクが示す参照は役に立たない。
そう。これがHTTP(S)のURLも許可すべきもう一つの理由だ。理解が正しければ、トランザクションにFreenetの使用を必須にしたいようだが、それには強く反対する。
Karmicadsの投稿（2010年5月2日07:07 UTC）http/sは階層的な名前空間の上で動き、P2Pのクライアントは階層的でない名前空間の上で動くので、一つのパラメーターで両方を相互に指すことはできない。物理的な場所に自分の身元を結びつけてしまった後で、匿名になろうと決めても遅すぎる。
すべてのトランザクションに完璧な匿名性が必要なわけではない。寄付を受けるオープンソースプロジェクトやオンラインショップを考えてみてほしい。（a）短いメッセージパラメーターで提供できる以上の詳細が必要で、（b）完全に匿名でありたいなら、FreenetやTorやI2PのURL（またはURN？――ややこしい :-/ ）を指定すればよい。追加の匿名性が不要なら、Freenet/Tor/I2P/その他を運用する手間をかける必要はない。
Karmicadsの投稿（2010年5月2日07:07 UTC）誤解していたら申し訳ない、DataWraith。だが君は、二つの名前空間のモデルの違いも、それぞれの長所と短所も、よく分かっていないように見える。自分は今でも、ほかのどんな方式でも喜んで検討する。君の批判を頭ごなしに退けているわけでも、自分の好みを標準にすべきだと言い張っているわけでもない。何にせよ、できる限り最良のURIスキームを作りたいだけだ。いずれにしても、考えてくれてありがとう。
まあ、みんな同じ目標に向かっている。可能な限り最良のシステムに到達できることを願う。:-)
詳しく説明してくれて、自分の提案に辛抱強くつきあってくれて、ありがとう。
freenet URIはこのようなものだ：
http://127.0.0.1:8888/USK@oshw3DxmJUt7q4ThF4dCez5IXbc9hCGcv0VuwLRCmeQ,ckeXv20F1gBzkqssB4RXHZ2nB1YRT8Pb8KYZk8wj-bs,AQACAAE/occamsrazor/6/f.pdf
ほら、同じやり方で簡単にできる。例えば:
http://127.0.0.1:8330/?to=<bitcoinaddress>;amount=<amount>
BitcoinはJSON-RPCのポート8332と同様に、ローカルループバックのポート8330で応答できる。HTTP応答を返すことになる。
DataWraithの投稿（2010年5月2日11:13 UTC）Bitcoinリンクは、magnet:よりもmailto:に近いものであるべきだと思う。
それは可能だと思う。
BitcoinがHTTP応答でHTMLのUIをユーザーに表示して処理することも可能だが、ユーザーとしては、ウェブサイトが騙そうとしているのか、本当に自分のBitcoinサーバーと通信しているのか疑問に思うだろう。
HTTP応答は、JavaScriptの戻るボタンに相当するHTMLにして、元のページに戻すだけでよいだろう。その後、Bitcoinが「ビットコインを送る」ダイアログを、送付先のビットコインアドレスと金額が既に入力された状態でポップアップ表示する。メールアドレスが入力された新規メールがポップアップするmailto:リンクと同じように動作する。
127.0.0.1のループバックはマシン上のどのユーザーからもアクセス可能で、ユーザーごとの分離はないが、ダイアログのフィールドを事前入力する利便性機能を提供するだけなので問題ない。送信を押す必要はまだある。スペースやEnterを入力している最中にフォアグラウンドに飛び出してこないように、送信ボタンが選択されていない状態にする必要がある。
ほら、同じやり方で簡単にできる：
http://127.0.0.1:8330/?to=<bitcoinaddress>;amount=<amount>
非常に実用的な回答だ。気に入った。
しかし、ここで説明されているIP/Bitcoinアドレスの複合URI（URN？ URL？）スキームとはどのように連携するのだろうか？ [link]topic 158]
ほぼ1ヶ月経ってしまった、ごめん。
http://127.0.0.1:8330/?to=domain.com&amount=200.00&comment=order_12345またはhttp://127.0.0.1:8330/?to=<bitcoinaddress><separatorchar>1.2.3.4&amount=200.00
しかし、リンクがすでに入力を代行してくれる以上、ビットコインアドレスの代わりにドメインアドレスを使うことにそれほどの利点があるとは思えない。ビットコインアドレスであれば、ユーザーは身元不明の支払いを送ることができない。正しいビットコインアドレスが与えられるまで支払いを送ることができないのだ。
ドメインで送信する良い点は、送信先を視覚的に確認できることだ。
より重要な問題は、ブラウザーが127.0.0.1に接続することを許可されていない場合はどうなるかということだ: topic 63
そして、もしそうだとすると、127.0.0.1が含まれていたFreenetリンクの例はどうなるのだろうか？
しかし、リンクがすでに入力を代行してくれる以上、ビットコインアドレスの代わりにドメインアドレスを使うことにそれほどの利点があるとは思えない。ビットコインアドレスであれば、ユーザーは身元不明の支払いを送ることができない。正しいビットコインアドレスが与えられるまで支払いを送ることができないのだ。
ドメインで送信する良い点は、送信先を視覚的に確認できることだ。
Bitcoinアドレスの複雑さをカジュアルユーザーから隠すことは良いことだと思う。それが無理なら、アドレストランザクションに観察可能だが変更不可能なメッセージを埋め込めるようにすべきだ。これが技術的に実現不可能な理由があるだろうか？
サトシ・ナカモトより重要な問題は、ブラウザーが127.0.0.1に接続することを許可されていない場合はどうなるかということだ: topic 63
そして、もしそうだとすると、127.0.0.1が含まれていたFreenetリンクの例はどうなるのだろうか？
問題を誤解していると思う。私のブラウザーは常に127.0.0.1にアクセスできる（奇妙なIEの設定やウイルスがなければ）。URLバーにアドレスを入力するかリンクをクリックすれば、正常に動作する。しかし、JavaScriptを使ってドメイン間（または同じドメインの異なるポート間）でPOSTリクエストを完了することはできない。
このリンクをクリックしてみてほしい：http://127.0.0.1/
おそらく何も表示されないだろう（システムでWebサーバーを動かしていない限り）が、ブラウザーは喜んでそこに移動しようとする。
XMLHTTPRequestが、あのスレッドで議論していたものだ。
ええ、クロスドメインのJavaScript呼び出しは禁止されているということを言いたかったのです。つまり、127.0.0.1上にないJavaScriptから127.0.0.1を呼び出すことはできません。考えてみると、ブラウザーが悪意のあるクロスドメインJavaScriptに人々のFacebookページを変更させたら、かなり面白いことになりますね。
ええ、クロスドメインのJavaScript呼び出しは禁止されているということを言いたかったのです。つまり、127.0.0.1上にないJavaScriptから127.0.0.1を呼び出すことはできません。考えてみると、ブラウザーが悪意のあるクロスドメインJavaScriptに人々のFacebookページを変更させたら、かなり面白いことになりますね。
http://127.0.0.1:8330?pay=domain.com&amount=x&return=<wheretoreturn.php> のような場所を指すiframeを置く方法が考えられる。そのiframeの中には小さなビットコインのインターフェースが表示され、いくらを誰に支払うかと、決済の確定・取消のボタンが並ぶ。確定すればコインがそのドメインに送られ、クエリ文字列のreturnに指定した場所へリダイレクトされる。ビットコイン側で ?paid=trueや ?paid=falseをリダイレクト先に付けておけば、ドメイン側の戻り先スクリプトが受領を正しく確認したり、注文を取り消したりできる。
Edit: 決済を確定する前に、このビットコインのインターフェースでパスワードも要求すべきだ。さもないと誰かのポート8330が開いているのを走査され、自動的に支払いを送らされてしまう。
Edit: 決済を確定する前に、このビットコインのインターフェースでパスワードも要求すべきだ。さもないと誰かのポート8330が開いているのを走査され、自動的に支払いを送らされてしまう。
それは正確には違う。現時点では、BitcoinはRPCをループバックインターフェース127.0.0.1にしかバインドしていない。このウェブインターフェースも同様だろうと思う。とはいえ、トロイの木馬がウォレットを簡単に送りつけられてしまわないよう、パスワードは必ず用意すべきだ。ウォレットの暗号化も必要になってくる。
問題を誤解していると思う。私のブラウザーは常に127.0.0.1にアクセスできる（奇妙なIEの設定やウイルスがなければ）。URLバーにアドレスを入力するかリンクをクリックすれば、正常に動作する。しかし、JavaScriptを使ってドメイン間（または同じドメインの異なるポート間）でPOSTリクエストを完了することはできない。
私もそう思っていた。
マルッティ・マルミの投稿（2010年6月16日08:26 UTC）ええ、クロスドメインのJavaScript呼び出しは禁止されているということを言いたかったのです。つまり、127.0.0.1上にないJavaScriptから127.0.0.1を呼び出すことはできません。考えてみると、ブラウザーが悪意のあるクロスドメインJavaScriptに人々のFacebookページを変更させたら、かなり面白いことになりますね。
JavaScriptが127.0.0.1へのクロスドメインPOSTリクエストを実行することが実際に可能だという報告が入ってきた。他のドメインではなく、特にそのドメインだけだ。素晴らしい……
もしこれが事実であれば、ウェブブラウジングをするシステムで -serverスイッチやbitcoindを使用しないでほしい。
パスワードフィールドの追加に取りかかる。
このアイデアについて誰か何かしているのか気になっている。このスレッドとここで説明されている素晴らしい開発に従って、インターネットブラウザー機能の実装の可能性を調査しているところだ。まずこれを試して、Firefoxアドオンが発展する中で他の機能と一緒に含めるのが、より簡単な最初の一歩かもしれない（学びながら進めている）。
これが実現する前に、URIがどのような形式を取るかについてコンセンサスが必要だ。URIスキームについて少し調査したが、W3Cの承認なしのほとんどのアプローチは好ましくないとされている。W3Cが暫定的なURIスキームを承認して保留にするカテゴリーがあるが、保証はない（仮特許のようなもの）。しかし、最も適切なスキームはマグネットURIのようだ。特定のアドレスではなく、コンテンツの一意性から生成されるハッシュによってリソースを見つけるよう設計されている。マグネットはピアツーピアネットワーク上のアプリケーションでの使用を意図しており、アプリケーション固有のデータへの参照用の予約パラメーターがある。基本的に、アプリケーション固有のパラメーターの前にxを付けるだけだ。例：xbitcoin1:?
これはとてもクールに見える！
私はW3Cのティム・バーナーズ＝リーと一緒にWeb標準ベースのプロジェクトに取り組んでいる開発チームの一員だ。
bitcoinスキームを登録するというアイデアを、向こうの何人かに持ちかけることはできる……ただ正直に言うと、君たちが必要としているものに対してはオーバーキルかもしれない。
たとえばHTML5の中で、bitcoinアドレスをRDF(a)でモデル化してみてはどうだろう。
必要なのは次のどちらかだけだ。1) ごく単純なオントロジー
<meta property=“bitcoin:address” content=“u34827uirhe243” />
あるいはOnlineAccount経由でFOAFとSOICのオントロジーを使う方法もある。
今朝、W3Cの何人かと、FSFと協働しているGNU Social / Diasporaの人たち、それからマイクロペイメントの標準化を目指しているpayswarmの人たちにお知らせを投稿しておいた。
要するに、bitcoinの意味論をHTMLで表現するのにマークアップはとても簡単だと思う。
このプロジェクトが大好きだ。みんなで何か形にできるといいな！😊
http://127.0.0.1:[bitcoinwebport]/whatever (http://127.0.0.1:%5Bbitcoinwebport%5D/whatever) を使うのは少し制約が大きい。ユーザーがbitcoinクライアントを持っていて、しかもそれが起動している必要がある。
一方、bitcoin:?whateverを使えば、ブラウザーにURIハンドラを追加できるので、クライアントが起動していなければ情報を渡して起動し、起動していればウィンドウを開ける。 さらに、ウェブサイトをURIハンドラとして登録できるようになる。だから、アプリを必要とせず、mybitcoinや他のウォレットサービスを提供するサイトをハンドラとして登録して、リクエストを代理処理させることもできる。このスタイルで標準化することには説得力ある根拠があると思う。