ビットコイン・インスティテュート

Bitcoin用URIスキーム

15 件のメッセージ BitcoinTalk ec, サトシ・ナカモト, The Madhatter, Karmicads, DataWraith, lachesis, マルッティ・マルミ, bencoder 2010年2月16日 — 2010年7月18日
ec 2010年2月16日 原文 · 個別ページ

こんにちは、ビットコインのシステムに興味を持ち、一つアイデアがある：

ビットコインアドレスは、例えばトレントのマグネットリンクのようなURIスキームを実装することで改善できるだろう。

つまり、1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ の代わりに、より明確に bitcoin:?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ と表記でき、さらにブラウザでこのようなリンクのクリックをビットコインクライアントにリダイレクトするよう設定できる。これにより、ホームページに「寄付ボタン」を、ウェブショップに「支払いボタン」を実装できるようになるだろう。

IPを含める必要がある場合、URIでは bitcoin://HOST_OR_IP:PORT?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ と記述できる。希望すれば金額も bitcoin:?amount=42.00;addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ のように指定できる（もちろんユーザーがセキュアなビットコインクライアントで確認するためのものだ）。

以上、私の0.02 ฿（気に入らなければ bitcoin:?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ に返してくれ）

ec 2010年2月16日 原文 · 個別ページ

URIスキームはQRコードを使ったモバイルウォレットの実装にも役立つだろう。X bitcoinを払いたい友人がBitcoinアドレスを手動で入力する必要がなく、自分の携帯電話の画面を撮影するだけで済むようになる。

The Madhatter 2010年2月24日 原文 · 個別ページ

ああ、俺もまったく同じことを考えていた。マグネットリンク方式は最高だろう。Cheesy

サトシ・ナカモト（Satoshi Nakamoto） 2010年2月24日 原文 · 個別ページ

販売時点で便利だろうな。レジがBitcoinアドレスと金額をエンコードしたQRコードを画面に表示し、携帯電話で撮影するのだ。

Karmicads 2010年5月1日 原文 · 個別ページ

このアイデアについて誰か何かしているのか気になっている。このスレッドとここで説明されている素晴らしい開発に従って、インターネットブラウザ機能の実装の可能性を調査しているところだ。まずこれを試して、Firefoxアドオンが発展する中で他の機能と一緒に含めるのが、より簡単な最初の一歩かもしれない（学びながら進めている）。

これが実現する前に、URIがどのような形式を取るかについてコンセンサスが必要だ。URIスキームについて少し調査したが、W3Cの承認なしのほとんどのアプローチは好ましくないとされている。W3Cが暫定的なURIスキームを承認して保留にするカテゴリーがあるが、保証はない（仮特許のようなもの）。しかし、最も適切なスキームはマグネットURIのようだ。特定のアドレスではなく、コンテンツの一意性から生成されるハッシュによってリソースを見つけるよう設計されている。マグネットはピアツーピアネットワーク上のアプリケーションでの使用を意図しており、アプリケーション固有のデータへの参照用の予約パラメータがある。基本的に、アプリケーション固有のパラメータの前にxを付けるだけだ。例：xbitcoin1:?

新しいトップレベルURIスキームの実装を試みないのが良いかもしれない。普遍的に認識されていなければ、即興的な手法と見なされるからだ。マグネットシステムの採用はこれを回避するが、マグネット自体も非公式の未登録スキームだ。マグネットの利点は共有可能でオープンなことだ。

これは非常に良さそうに見えるかもしれない。bitcoinは結局P2Pアプリケーションであり、そのネットワークは似た原理で動作しているからだ。しかし、リンクをクリックする人がbitcoinユーザーでない場合はどうか？ 既存のネットワークに含まれない情報、例えば販売する商品、配送情報、その他の問題を組み込みたい場合はどうか。bitcoinはトランザクション自体のみを処理するという理解なので、ユーザーは他のすべての取り決め、契約、コミュニケーションをbitcoinとは独立に行う必要がある。ここで匿名性が損なわれる。従来の「階層的なハードワイヤード、または非匿名の技術」に頼る傾向があるからだ。これはbitcoinへの批判ではまったくない。bitcoinは素晴らしいトランザクション方法だ。しかし、トランザクションはコインの片面にすぎない（このひどいダジャレを許してくれ）。Grin

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や環境変数を設定する必要があるかもしれない。

この調査中に訪れた他の関連サイト：

アイデア/コメント/フィードバックは歓迎する。Wink Steve

Karmicads 2010年5月2日 原文 · 個別ページ

速報：…

ちょうど、freenet上の保存されたデータファイルと対話するための既存のプロトコルがあるようだ。Grin ＜やった！＞ Grin

申し訳ない、自分が提案した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、もし読んでいるなら、あなたに注目している。Wink

DataWraith 2010年5月2日 原文 · 個別ページ

Karmicads、詳細な返信をありがとう。

Quote from: Karmicads on May 02, 2010, 02:15:51 AM

速報：…

ちょうど、freenet上の保存されたデータファイルと対話するための既存のプロトコルがあるようだ。Grin ＜やった！＞ Grin

申し訳ない、自分が提案した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、もし読んでいるなら、あなたに注目している。Wink

ああ、Freenetの利用について言っていたのはそういう意味だったのか。ユーザーがFreenetを実行し、BitcoinがFreenetの制御プロトコルを使って通信する。しかし、Freenetの実行にはかなりのコンピュータリソース、特に帯域幅が必要であり、個人的にはそれだけの理由でFreenetノードを動かしたくない。だからこれをオプションにしたかった。

既存の仕組みを再発明したくないという印象を受けた。そしてだからこそ普及度が重要で――他のソフトウェアでのmagnetリンクの既存の受容がプラスだった。

すまないが、敬意を込めつつ、同意しかねる。最初の問題は、ハードドライブ上のファイルがネストされた場所の階層的な名前空間、つまりドメインとディレクトリにマッピングされていることだ。多くのP2Pネットワークのアプローチの根本的な違いは、名前空間が階層的でなく、サポートするデータがアドレスではなくコンテンツの一意性によって参照されることだ。ターゲットがファイルであろうと何であろうと、特定の固定アドレスではなく、固有のコンテンツのアイデンティティによって参照される。同一のファイルは本質的に同じアイデンティティであり、P2Pアプリケーションは同一アイテムへの複数のフィードとして複数のインスタンスを使用できる。magnetのパラメータはあらゆるP2Pアプリケーションに適している。 了解、ここで自分の言いたいことを完全に明確にしていなかったようだ。magnetリンクがコンテンツを参照する仕組みは理解している。

おそらくメンタルモデルの違いだろう：自分にとって、Bitcoinのトランザクションは、適切な言葉がないが、ものというよりはプロセスだ。自分の認識では、magnetリンクはもの（通常はファイル――コンテンツハッシュまたは場所による）を参照するものであり、プロセスを参照するために使おうとするのは少し不自然に感じる。magnetリンクは取得しに行く必要があるものを特定するが、Bitcoinのトランザクションはリンク自体で完全に記述される（リンクをクリックした後に「はい、コインを送ります」と言う必要はあるが）。

自分には、magnetリンクを本来の目的ではないものに（悪）用することのように思える。magnetリンクはed2k://やfreenet://などの代替として、ファイルの取得方法を記述するために生まれたものだからだ。

Bitcoinリンクは、magnet:よりもmailto:に近いものであるべきだと思う。

そうだ、すまない。

確か、ウェブサーバーはFreenet自体にかなり統合されている。よりシンプルなFCPプロトコルを使ってFreenetインスタンスと通信することもできるが、Freenet上のコンテンツの性質上、公開アクセス可能なインスタンスをホストする人は多くないので、自分で運用する必要がある。それを望む気持ちは否定しないが、自分はやりたくない。むしろTORの隠しサービスをホストしたい――だからdetailsパラメータにFreenet固有ではなく汎用的なフルURLを使うことを提案した。

アドレスという意味がよく分からないが、Bitcoinの署名で提供される「アドレス」以外を指しているのか。すでにエイリアスが定義されていない限り、異なる人に異なるアドレスを渡す方法が分からない。つまり、Bitcoinノードのエイリアスをエンコードして変換する命名システムを追加することを提案しているのか？それはそれほど手間なくできるだろう。 まあ、BitcoinのSignatureのことだ。Bitcoinクライアントにそう表示されているから「アドレス」と呼んだ（「アドレスを変更」と表示される）。交換サイトが現在行っているように、異なるエイリアスを使うべきだと確かに考えていた：コインを送るアドレス（または署名、あるいは何でも）を受け取り、そのアドレスはあなたにだけ渡されたものなので、受取人は支払いがあなたからだと分かる。

エイリアスを変換するシステムはもちろん良いが、それはアドレス帳やmybitcoin.comなどで処理する方がよいと思う。

そう、まさにその通りだ！送信側のテキストは通常のルートでよい。だが、送信されるテキストを事前に指定したい場合はどうか？

これにはmailto:リンクのアナロジーがある：誰かにメールを送ってほしい場合、使うべきsubjectも指定できる：mailto:alice@example.org?subject=Test。だから、例えばeBayで何かを売っている場合、「eBayオークション#12345の支払い」というメッセージを含むBitcoinリンクを買い手に渡せば、本人が入力する必要がなくなり、コードが#12345より暗号的な場合にミスを防げる。

すまない、URI、URLなどの用語をアドレスバーに入力するからつい混同して使いがちだ。混乱させたなら申し訳ない。

ここで自分が望んでいたのは、この追加情報を汎用的にすることだ。いくつかの例で明確になるかもしれない：

リンクの作成者が追加情報の置き場所を選び、受取人がFreenet/Tor/I2Pをインストールするほど補足情報が必要かどうかを判断する。これがリンク自体に短いメッセージを含める理由の一つだ：追加情報はトランザクションに不可欠であるべきではない。

だが、それだとFreenetの使用が必須にならないか？もっと柔軟であってほしい。

また、オンラインショップを運営する場合、Freenetをインストールさせるよりも、自分のウェブサイトで詳細を確認してもらう方がよい。Freenetの評判を考えると、ショップの評判がFreenetと結びつくのは望ましくないかもしれない。

そう。これがHTTP(S)のURLも許可すべきもう一つの理由だ。理解が正しければ、トランザクションにFreenetの使用を必須にしたいようだが、それには強く反対する。

すべてのトランザクションに完璧な匿名性が必要なわけではない。寄付を受けるオープンソースプロジェクトやオンラインショップを考えてみてほしい。（a）短いメッセージパラメータで提供できる以上の詳細が必要で、（b）完全に匿名でありたいなら、FreenetやTorやI2PのURL（またはURN？――ややこしい :-/ ）を指定すればよい。追加の匿名性が不要なら、Freenet/Tor/I2P/その他を運用する手間をかける必要はない。

まあ、みんな同じ目標に向かっている。可能な限り最良のシステムに到達できることを願う。:-)

丁寧な説明と、自分の提案への忍耐に感謝する。

サトシ・ナカモト（Satoshi Nakamoto） 2010年5月16日 原文 · 個別ページ

Quote from: Karmicads on May 01, 2010, 06:06:53 AM

このアイデアについて誰か何かしているのか気になっている。このスレッドとここで説明されている素晴らしい開発に従って、インターネットブラウザ機能の実装の可能性を調査しているところだ。まずこれを試して、Firefoxアドオンが発展する中で他の機能と一緒に含めるのが、より簡単な最初の一歩かもしれない（学びながら進めている）。

これが実現する前に、URIがどのような形式を取るかについてコンセンサスが必要だ。URIスキームについて少し調査したが、W3Cの承認なしのほとんどのアプローチは好ましくないとされている。W3Cが暫定的なURIスキームを承認して保留にするカテゴリーがあるが、保証はない（仮特許のようなもの）。しかし、最も適切なスキームはマグネットURIのようだ。特定のアドレスではなく、コンテンツの一意性から生成されるハッシュによってリソースを見つけるよう設計されている。マグネットはピアツーピアネットワーク上のアプリケーションでの使用を意図しており、アプリケーション固有のデータへの参照用の予約パラメータがある。基本的に、アプリケーション固有のパラメータの前にxを付けるだけだ。例：xbitcoin1:?

新しいトップレベルURIスキームの実装を試みないのが良いかもしれない。普遍的に認識されていなければ、即興的な手法と見なされるからだ。マグネットシステムの採用はこれを回避するが、マグネット自体も非公式の未登録スキームだ。マグネットの利点は共有可能でオープンなことだ。

これは非常に良さそうに見えるかもしれない。bitcoinは結局P2Pアプリケーションであり、そのネットワークは似た原理で動作しているからだ。しかし、リンクをクリックする人がbitcoinユーザーでない場合はどうか？ 既存のネットワークに含まれない情報、例えば販売する商品、配送情報、その他の問題を組み込みたい場合はどうか。bitcoinはトランザクション自体のみを処理するという理解なので、ユーザーは他のすべての取り決め、契約、コミュニケーションをbitcoinとは独立に行う必要がある。ここで匿名性が損なわれる。従来の「階層的なハードワイヤード、または非匿名の技術」に頼る傾向があるからだ。これはbitcoinへの批判ではまったくない。bitcoinは素晴らしいトランザクション方法だ。しかし、トランザクションはコインの片面にすぎない（このひどいダジャレを許してくれ）。Grin

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や環境変数を設定する必要があるかもしれない。

この調査中に訪れた他の関連サイト：

アイデア/コメント/フィードバックは歓迎する。Wink Steve

http://127.0.0.1:8888/USK@oshw3DxmJUt7q4ThF4dCez5IXbc9hCGcv0VuwLRCmeQ,ckeXv20F1gBzkqssB4RXHZ2nB1YRT8Pb8KYZk8wj-bs,AQACAAE/occamsrazor/6/f.pdf

そうだな、同じ方法で簡単にできる。例えば: http://127.0.0.1:8330/?to=;amount=

BitcoinはJSON-RPCのポート8332と同様に、ローカルループバックのポート8330で応答できる。HTTP応答を返すことになる。

Quote from: DataWraith on May 02, 2010, 11:13:09 AM

Karmicads、詳細な返信をありがとう。

Quote from: Karmicads on May 02, 2010, 02:15:51 AM

Freenet上の保存データと対話するための既存のプロトコルがちょうどあるようだ

ああ、Freenetの利用について言っていたのはそういう意味だったのか。ユーザーがFreenetを実行し、BitcoinがFreenetの制御プロトコルを使って通信する。しかし、Freenetの実行にはかなりのコンピュータリソース、特に帯域幅が必要であり、個人的にはそれだけの理由でFreenetノードを動かしたくない。だからこれをオプションにしたかった。

既存の仕組みを再発明したくないという印象を受けた。そしてだからこそ普及度が重要で――他のソフトウェアでのmagnetリンクの既存の受容がプラスだった。

すまないが、敬意を込めつつ、同意しかねる。最初の問題は、ハードドライブ上のファイルがネストされた場所の階層的な名前空間、つまりドメインとディレクトリにマッピングされていることだ。多くのP2Pネットワークのアプローチの根本的な違いは、名前空間が階層的でなく、サポートするデータがアドレスではなくコンテンツの一意性によって参照されることだ。ターゲットがファイルであろうと何であろうと、特定の固定アドレスではなく、固有のコンテンツのアイデンティティによって参照される。同一のファイルは本質的に同じアイデンティティであり、P2Pアプリケーションは同一アイテムへの複数のフィードとして複数のインスタンスを使用できる。magnetのパラメータはあらゆるP2Pアプリケーションに適している。 了解、ここで自分の言いたいことを完全に明確にしていなかったようだ。magnetリンクがコンテンツを参照する仕組みは理解している。

おそらくメンタルモデルの違いだろう：自分にとって、Bitcoinのトランザクションは、適切な言葉がないが、ものというよりはプロセスだ。自分の認識では、magnetリンクはもの（通常はファイル――コンテンツハッシュまたは場所による）を参照するものであり、プロセスを参照するために使おうとするのは少し不自然に感じる。magnetリンクは取得しに行く必要があるものを特定するが、Bitcoinのトランザクションはリンク自体で完全に記述される（リンクをクリックした後に「はい、コインを送ります」と言う必要はあるが）。

自分には、magnetリンクを本来の目的ではないものに（悪）用することのように思える。magnetリンクはed2k://やfreenet://などの代替として、ファイルの取得方法を記述するために生まれたものだからだ。

Bitcoinリンクは、magnet:よりもmailto:に近いものであるべきだと思う。

そうだ、すまない。

確か、ウェブサーバーはFreenet自体にかなり統合されている。よりシンプルなFCPプロトコルを使ってFreenetインスタンスと通信することもできるが、Freenet上のコンテンツの性質上、公開アクセス可能なインスタンスをホストする人は多くないので、自分で運用する必要がある。それを望む気持ちは否定しないが、自分はやりたくない。むしろTORの隠しサービスをホストしたい――だからdetailsパラメータにFreenet固有ではなく汎用的なフルURLを使うことを提案した。

アドレスという意味がよく分からないが、Bitcoinの署名で提供される「アドレス」以外を指しているのか。すでにエイリアスが定義されていない限り、異なる人に異なるアドレスを渡す方法が分からない。つまり、Bitcoinノードのエイリアスをエンコードして変換する命名システムを追加することを提案しているのか？それはそれほど手間なくできるだろう。 まあ、BitcoinのSignatureのことだ。Bitcoinクライアントにそう表示されているから「アドレス」と呼んだ（「アドレスを変更」と表示される）。交換サイトが現在行っているように、異なるエイリアスを使うべきだと確かに考えていた：コインを送るアドレス（または署名、あるいは何でも）を受け取り、そのアドレスはあなたにだけ渡されたものなので、受取人は支払いがあなたからだと分かる。

エイリアスを変換するシステムはもちろん良いが、それはアドレス帳やmybitcoin.comなどで処理する方がよいと思う。

そう、まさにその通りだ！送信側のテキストは通常のルートでよい。だが、送信されるテキストを事前に指定したい場合はどうか？

これにはmailto:リンクのアナロジーがある：誰かにメールを送ってほしい場合、使うべきsubjectも指定できる：mailto:alice@example.org?subject=Test。だから、例えばeBayで何かを売っている場合、「eBayオークション#12345の支払い」というメッセージを含むBitcoinリンクを買い手に渡せば、本人が入力する必要がなくなり、コードが#12345より暗号的な場合にミスを防げる。

すまない、URI、URLなどの用語をアドレスバーに入力するからつい混同して使いがちだ。混乱させたなら申し訳ない。

ここで自分が望んでいたのは、この追加情報を汎用的にすることだ。いくつかの例で明確になるかもしれない：

リンクの作成者が追加情報の置き場所を選び、受取人がFreenet/Tor/I2Pをインストールするほど補足情報が必要かどうかを判断する。これがリンク自体に短いメッセージを含める理由の一つだ：追加情報はトランザクションに不可欠であるべきではない。

だが、それだとFreenetの使用が必須にならないか？もっと柔軟であってほしい。

また、オンラインショップを運営する場合、Freenetをインストールさせるよりも、自分のウェブサイトで詳細を確認してもらう方がよい。Freenetの評判を考えると、ショップの評判がFreenetと結びつくのは望ましくないかもしれない。

そう。これがHTTP(S)のURLも許可すべきもう一つの理由だ。理解が正しければ、トランザクションにFreenetの使用を必須にしたいようだが、それには強く反対する。

すべてのトランザクションに完璧な匿名性が必要なわけではない。寄付を受けるオープンソースプロジェクトやオンラインショップを考えてみてほしい。（a）短いメッセージパラメータで提供できる以上の詳細が必要で、（b）完全に匿名でありたいなら、FreenetやTorやI2PのURL（またはURN？――ややこしい :-/ ）を指定すればよい。追加の匿名性が不要なら、Freenet/Tor/I2P/その他を運用する手間をかける必要はない。

まあ、みんな同じ目標に向かっている。可能な限り最良のシステムに到達できることを願う。:-)

丁寧な説明と、自分の提案への忍耐に感謝する。

それは可能だと思う。

BitcoinがHTTP応答でHTMLのUIをユーザーに表示して処理することも可能だが、ユーザーとしては、ウェブサイトが騙そうとしているのか、本当に自分のBitcoinサーバーと通信しているのか疑問に思うだろう。

HTTP応答は、JavaScriptの戻るボタンに相当するHTMLにして、元のページに戻すだけでよいだろう。その後、Bitcoinが「ビットコインを送る」ダイアログを、送付先のビットコインアドレスと金額が既に入力された状態でポップアップ表示する。メールアドレスが入力された新規メールがポップアップするmailto:リンクと同じように動作する。

127.0.0.1のループバックはマシン上のどのユーザーからもアクセス可能で、ユーザーごとの分離はないが、ダイアログのフィールドを事前入力する利便性機能を提供するだけなので問題ない。送信を押す必要はまだある。スペースやEnterを入力している最中にフォアグラウンドに飛び出してこないように、送信ボタンが選択されていない状態にする必要がある。

lachesis 2010年6月11日 原文 · 個別ページ

Quote from: satoshi on May 16, 2010, 10:37:21 PM

Quote from: Karmicads on May 01, 2010, 06:06:53 AM

このアイデアについて誰か何かしているのか気になっている。このスレッドとここで説明されている素晴らしい開発に従って、インターネットブラウザ機能の実装の可能性を調査しているところだ。まずこれを試して、Firefoxアドオンが発展する中で他の機能と一緒に含めるのが、より簡単な最初の一歩かもしれない（学びながら進めている）。

これが実現する前に、URIがどのような形式を取るかについてコンセンサスが必要だ。URIスキームについて少し調査したが、W3Cの承認なしのほとんどのアプローチは好ましくないとされている。W3Cが暫定的なURIスキームを承認して保留にするカテゴリーがあるが、保証はない（仮特許のようなもの）。しかし、最も適切なスキームはマグネットURIのようだ。特定のアドレスではなく、コンテンツの一意性から生成されるハッシュによってリソースを見つけるよう設計されている。マグネットはピアツーピアネットワーク上のアプリケーションでの使用を意図しており、アプリケーション固有のデータへの参照用の予約パラメータがある。基本的に、アプリケーション固有のパラメータの前にxを付けるだけだ。例：xbitcoin1:?

新しいトップレベルURIスキームの実装を試みないのが良いかもしれない。普遍的に認識されていなければ、即興的な手法と見なされるからだ。マグネットシステムの採用はこれを回避するが、マグネット自体も非公式の未登録スキームだ。マグネットの利点は共有可能でオープンなことだ。

これは非常に良さそうに見えるかもしれない。bitcoinは結局P2Pアプリケーションであり、そのネットワークは似た原理で動作しているからだ。しかし、リンクをクリックする人がbitcoinユーザーでない場合はどうか？ 既存のネットワークに含まれない情報、例えば販売する商品、配送情報、その他の問題を組み込みたい場合はどうか。bitcoinはトランザクション自体のみを処理するという理解なので、ユーザーは他のすべての取り決め、契約、コミュニケーションをbitcoinとは独立に行う必要がある。ここで匿名性が損なわれる。従来の「階層的なハードワイヤード、または非匿名の技術」に頼る傾向があるからだ。これはbitcoinへの批判ではまったくない。bitcoinは素晴らしいトランザクション方法だ。しかし、トランザクションはコインの片面にすぎない（このひどいダジャレを許してくれ）。Grin

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や環境変数を設定する必要があるかもしれない。

この調査中に訪れた他の関連サイト：

アイデア/コメント/フィードバックは歓迎する。Wink Steve

http://127.0.0.1:8888/USK@oshw3DxmJUt7q4ThF4dCez5IXbc9hCGcv0VuwLRCmeQ,ckeXv20F1gBzkqssB4RXHZ2nB1YRT8Pb8KYZk8wj-bs,AQACAAE/occamsrazor/6/f.pdf

そうだな、同じ方法で簡単にできる。例えば: http://127.0.0.1:8330/?to=;amount=

BitcoinはJSON-RPCのポート8332と同様に、ローカルループバックのポート8330で応答できる。HTTP応答を返すことになる。

Quote from: DataWraith on May 02, 2010, 11:13:09 AM

Karmicads、詳細な返信をありがとう。

Quote from: Karmicads on May 02, 2010, 02:15:51 AM

Freenet上の保存データと対話するための既存のプロトコルがちょうどあるようだ

ああ、Freenetの利用について言っていたのはそういう意味だったのか。ユーザーがFreenetを実行し、BitcoinがFreenetの制御プロトコルを使って通信する。しかし、Freenetの実行にはかなりのコンピュータリソース、特に帯域幅が必要であり、個人的にはそれだけの理由でFreenetノードを動かしたくない。だからこれをオプションにしたかった。

既存の仕組みを再発明したくないという印象を受けた。そしてだからこそ普及度が重要で――他のソフトウェアでのmagnetリンクの既存の受容がプラスだった。

すまないが、敬意を込めつつ、同意しかねる。最初の問題は、ハードドライブ上のファイルがネストされた場所の階層的な名前空間、つまりドメインとディレクトリにマッピングされていることだ。多くのP2Pネットワークのアプローチの根本的な違いは、名前空間が階層的でなく、サポートするデータがアドレスではなくコンテンツの一意性によって参照されることだ。ターゲットがファイルであろうと何であろうと、特定の固定アドレスではなく、固有のコンテンツのアイデンティティによって参照される。同一のファイルは本質的に同じアイデンティティであり、P2Pアプリケーションは同一アイテムへの複数のフィードとして複数のインスタンスを使用できる。magnetのパラメータはあらゆるP2Pアプリケーションに適している。 了解、ここで自分の言いたいことを完全に明確にしていなかったようだ。magnetリンクがコンテンツを参照する仕組みは理解している。

おそらくメンタルモデルの違いだろう：自分にとって、Bitcoinのトランザクションは、適切な言葉がないが、ものというよりはプロセスだ。自分の認識では、magnetリンクはもの（通常はファイル――コンテンツハッシュまたは場所による）を参照するものであり、プロセスを参照するために使おうとするのは少し不自然に感じる。magnetリンクは取得しに行く必要があるものを特定するが、Bitcoinのトランザクションはリンク自体で完全に記述される（リンクをクリックした後に「はい、コインを送ります」と言う必要はあるが）。

自分には、magnetリンクを本来の目的ではないものに（悪）用することのように思える。magnetリンクはed2k://やfreenet://などの代替として、ファイルの取得方法を記述するために生まれたものだからだ。

Bitcoinリンクは、magnet:よりもmailto:に近いものであるべきだと思う。

そうだ、すまない。

確か、ウェブサーバーはFreenet自体にかなり統合されている。よりシンプルなFCPプロトコルを使ってFreenetインスタンスと通信することもできるが、Freenet上のコンテンツの性質上、公開アクセス可能なインスタンスをホストする人は多くないので、自分で運用する必要がある。それを望む気持ちは否定しないが、自分はやりたくない。むしろTORの隠しサービスをホストしたい――だからdetailsパラメータにFreenet固有ではなく汎用的なフルURLを使うことを提案した。

アドレスという意味がよく分からないが、Bitcoinの署名で提供される「アドレス」以外を指しているのか。すでにエイリアスが定義されていない限り、異なる人に異なるアドレスを渡す方法が分からない。つまり、Bitcoinノードのエイリアスをエンコードして変換する命名システムを追加することを提案しているのか？それはそれほど手間なくできるだろう。 まあ、BitcoinのSignatureのことだ。Bitcoinクライアントにそう表示されているから「アドレス」と呼んだ（「アドレスを変更」と表示される）。交換サイトが現在行っているように、異なるエイリアスを使うべきだと確かに考えていた：コインを送るアドレス（または署名、あるいは何でも）を受け取り、そのアドレスはあなたにだけ渡されたものなので、受取人は支払いがあなたからだと分かる。

エイリアスを変換するシステムはもちろん良いが、それはアドレス帳やmybitcoin.comなどで処理する方がよいと思う。

そう、まさにその通りだ！送信側のテキストは通常のルートでよい。だが、送信されるテキストを事前に指定したい場合はどうか？

これにはmailto:リンクのアナロジーがある：誰かにメールを送ってほしい場合、使うべきsubjectも指定できる：mailto:alice@example.org?subject=Test。だから、例えばeBayで何かを売っている場合、「eBayオークション#12345の支払い」というメッセージを含むBitcoinリンクを買い手に渡せば、本人が入力する必要がなくなり、コードが#12345より暗号的な場合にミスを防げる。

すまない、URI、URLなどの用語をアドレスバーに入力するからつい混同して使いがちだ。混乱させたなら申し訳ない。

ここで自分が望んでいたのは、この追加情報を汎用的にすることだ。いくつかの例で明確になるかもしれない：

リンクの作成者が追加情報の置き場所を選び、受取人がFreenet/Tor/I2Pをインストールするほど補足情報が必要かどうかを判断する。これがリンク自体に短いメッセージを含める理由の一つだ：追加情報はトランザクションに不可欠であるべきではない。

だが、それだとFreenetの使用が必須にならないか？もっと柔軟であってほしい。

また、オンラインショップを運営する場合、Freenetをインストールさせるよりも、自分のウェブサイトで詳細を確認してもらう方がよい。Freenetの評判を考えると、ショップの評判がFreenetと結びつくのは望ましくないかもしれない。

そう。これがHTTP(S)のURLも許可すべきもう一つの理由だ。理解が正しければ、トランザクションにFreenetの使用を必須にしたいようだが、それには強く反対する。

すべてのトランザクションに完璧な匿名性が必要なわけではない。寄付を受けるオープンソースプロジェクトやオンラインショップを考えてみてほしい。（a）短いメッセージパラメータで提供できる以上の詳細が必要で、（b）完全に匿名でありたいなら、FreenetやTorやI2PのURL（またはURN？――ややこしい :-/ ）を指定すればよい。追加の匿名性が不要なら、Freenet/Tor/I2P/その他を運用する手間をかける必要はない。

まあ、みんな同じ目標に向かっている。可能な限り最良のシステムに到達できることを願う。:-)

丁寧な説明と、自分の提案への忍耐に感謝する。

それは可能だと思う。

BitcoinがHTTP応答でHTMLのUIをユーザーに表示して処理することも可能だが、ユーザーとしては、ウェブサイトが騙そうとしているのか、本当に自分のBitcoinサーバーと通信しているのか疑問に思うだろう。

HTTP応答は、JavaScriptの戻るボタンに相当するHTMLにして、元のページに戻すだけでよいだろう。その後、Bitcoinが「ビットコインを送る」ダイアログを、送付先のビットコインアドレスと金額が既に入力された状態でポップアップ表示する。メールアドレスが入力された新規メールがポップアップするmailto:リンクと同じように動作する。

127.0.0.1のループバックはマシン上のどのユーザーからもアクセス可能で、ユーザーごとの分離はないが、ダイアログのフィールドを事前入力する利便性機能を提供するだけなので問題ない。送信を押す必要はまだある。スペースやEnterを入力している最中にフォアグラウンドに飛び出してこないように、送信ボタンが選択されていない状態にする必要がある。

非常に実用的な回答だ。気に入った。

しかし、ここで説明されているIP/Bitcoinアドレスの複合URI（URN？ URL？）スキームとはどのように連携するのだろうか？ [link]topic 158]

ほぼ1ヶ月経ってしまったが、申し訳ない。

サトシ・ナカモト（Satoshi Nakamoto） 2010年6月16日 原文 · 個別ページ

http://127.0.0.1:8330/?to=domain.com&amount=200.00&comment=order_12345 または http://127.0.0.1:8330/?to=1.2.3.4&amount=200.00

しかし、リンクがすでに入力を代行してくれる以上、ビットコインアドレスの代わりにドメインアドレスを使うことにそれほどの利点があるとは思えない。ビットコインアドレスであれば、ユーザーは身元不明の支払いを送ることができない。正しいビットコインアドレスが与えられるまで支払いを送ることができないのだ。

ドメインで送信する良い点は、送信先を視覚的に確認できることだ。

より重要な問題は、ブラウザが127.0.0.1に接続することを許可されていない場合はどうなるかということだ: topic 63

そして、もしそうだとすると、127.0.0.1が含まれていたFreenetリンクの例はどうなるのだろうか？

lachesis 2010年6月16日 原文 · 個別ページ

Quote from: satoshi on June 16, 2010, 12:15:47 AM

http://127.0.0.1:8330/?to=domain.com&amount=200.00&comment=order_12345 または http://127.0.0.1:8330/?to=1.2.3.4&amount=200.00

しかし、リンクがすでに入力を代行してくれる以上、ビットコインアドレスの代わりにドメインアドレスを使うことにそれほどの利点があるとは思えない。ビットコインアドレスであれば、ユーザーは身元不明の支払いを送ることができない。正しいビットコインアドレスが与えられるまで支払いを送ることができないのだ。

ドメインで送信する良い点は、送信先を視覚的に確認できることだ。

より重要な問題は、ブラウザが127.0.0.1に接続することを許可されていない場合はどうなるかということだ: topic 63

そして、もしそうだとすると、127.0.0.1が含まれていたFreenetリンクの例はどうなるのだろうか？

マルッティ・マルミ（sirius） 2010年6月16日 原文 · 個別ページ

ええ、クロスドメインのJavaScript呼び出しは禁止されているということを言いたかったのです。つまり、127.0.0.1上にないJavaScriptから127.0.0.1を呼び出すことはできません。考えてみると、ブラウザが悪意のあるクロスドメインJavaScriptに人々のFacebookページを変更させたら、かなり面白いことになりますね。

bencoder 2010年6月16日 原文 · 個別ページ

Quote from: sirius-m on June 16, 2010, 08:26:14 AM

ええ、クロスドメインのJavaScript呼び出しは禁止されているということを言いたかったのです。つまり、127.0.0.1上にないJavaScriptから127.0.0.1を呼び出すことはできません。考えてみると、ブラウザが悪意のあるクロスドメインJavaScriptに人々のFacebookページを変更させたら、かなり面白いことになりますね。

lachesis 2010年6月16日 原文 · 個別ページ

Quote from: bencoder on June 16, 2010, 12:59:40 PM

Quote from: sirius-m on June 16, 2010, 08:26:14 AM

ええ、クロスドメインのJavaScript呼び出しは禁止されているということを言いたかったのです。つまり、127.0.0.1上にないJavaScriptから127.0.0.1を呼び出すことはできません。考えてみると、ブラウザが悪意のあるクロスドメインJavaScriptに人々のFacebookページを変更させたら、かなり面白いことになりますね。

サトシ・ナカモト（Satoshi Nakamoto） 2010年7月18日 原文 · 個別ページ

Quote from: lachesis on June 16, 2010, 06:14:05 AM

Quote from: satoshi on June 16, 2010, 12:15:47 AM

しかし、リンクが既にタイピングを代行してくれるのなら、ドメインアドレスの代わりにbitcoinアドレスを使うことにそれほどメリットがあるとは思えない。bitcoinアドレスを使えば、ユーザーは身元不明の支払いを送ることができない。正しいbitcoinアドレスが渡されるまで支払いを送ることができないからだ。

私もそう思っていた。

Quote from: sirius-m on June 16, 2010, 08:26:14 AM

ええ、クロスドメインのJavaScript呼び出しは禁止されているということを言いたかったのです。つまり、127.0.0.1上にないJavaScriptから127.0.0.1を呼び出すことはできません。考えてみると、ブラウザが悪意のあるクロスドメインJavaScriptに人々のFacebookページを変更させたら、かなり面白いことになりますね。

JavaScriptが127.0.0.1へのクロスドメインPOSTリクエストを実行することが可能だという報告が入ってきた。他のドメインではなく、特にそのドメインだけだ。素晴らしい……

もしこれが事実であれば、ウェブブラウジングをするシステムで-serverスイッチやbitcoindを使用しないでほしい。

パスワードフィールドの追加に取りかかる。