BIP: 21
Layer: Applications
Title: URI Scheme
Authors: Nils Schneider <nils.schneider@gmail.com>
Matt Corallo <bip21@bluematt.me>
Status: Closed
Type: Specification
Assigned: 2012-01-29
Replaces: 20
Proposed-Replacement: 321BIP 321 によって置換
本 BIP は BIP 321 によって置換・更新された。代わりに BIP 321 (https://github.com/bitcoin/bips/blob/master/bip-0321.mediawiki) を参照してほしい。
原 BIP
本 BIP は、ルーク・ダッシュジュニアによる先行する BIP 0020 (https://github.com/bitcoin/bips/blob/master/bip-0020.mediawiki) の改訂版である。BIP 0020 はそれ以前のニルス・シュナイダーによる文書を基にしていた。BIP 0020 にあった代替決済額機能は削除されている。
アブストラクト
本 BIP は、ビットコインの決済を行うための URI スキームを提案する。
動機
この URI スキームの目的は、ウェブページのリンクをクリックしたり QR コードをスキャンしたりするだけで、利用者が容易に決済を行えるようにすることである。
仕様
取り扱い上の一般規則 (重要！)
ビットコインクライアントは、利用者の承認を得ずに URI に対して動作してはならない (MUST NOT) 。 各決済を個別に手動で承認するよう利用者に求めるべき (SHOULD) であるが、場合によっては利用者がこの判断を自動化することを許してもよい (MAY) 。
オペレーティングシステム統合
グラフィカルなビットコインクライアントは、すでに別のハンドラーが登録されていない限り、既定で「bitcoin:」 URI スキームのハンドラーとして自身を登録するべき (SHOULD) である。すでに登録されたハンドラーがある場合は、初回起動時にその変更を利用者に促してもよい (MAY) 。
一般書式
ビットコイン URI は RFC 3986 で定められた URI の一般書式に従う。パス成分はビットコインアドレスから成り、クエリ成分は追加の決済オプションを提供する。
クエリ成分の要素には有効範囲外の文字を含むことがある。それらはまず UTF-8 に従ってエンコードし、対応する UTF-8 の各オクテットを RFC 3986 に従ってパーセントエンコードしなければならない。
ABNF 文法
(より単純な構文表現も後述する)
bitcoinurn = "bitcoin:" bitcoinaddress [ "?" bitcoinparams ]
bitcoinaddress = *base58
bitcoinparams = bitcoinparam [ "&" bitcoinparams ]
bitcoinparam = [ amountparam / labelparam / messageparam / otherparam / reqparam ]
amountparam = "amount=" *digit [ "." *digit ]
labelparam = "label=" *qchar
messageparam = "message=" *qchar
otherparam = qchar *qchar [ "=" *qchar ]
reqparam = "req-" qchar *qchar [ "=" *qchar ]ここで「qchar」 は RFC 3986 の URI クエリ成分として有効な文字に対応するが、本 BIP が区切りとして用いる「=」 と「&」 を除く。
スキーム成分 (「bitcoin:」 ) は大文字小文字を区別せず、実装は大文字小文字の任意の組み合わせを受け入れなければならない。URI のそれ以外の部分は、クエリパラメータのキーを含め、大文字小文字を区別する。
クエリキー
- label: 当該アドレスのラベル (例: 受取人の名前)
- address: ビットコインアドレス
- message: トランザクションを利用者に説明するメッセージ (後述の例を参照)
- (その他): 任意。将来の拡張用。
送金額
送金額が指定される場合、十進数の BTC で指定しなければならない (MUST) 。 すべての金額はカンマを含まず、整数部と小数部の区切り文字としてピリオド (.) を用いなければならない (MUST) 。 すなわち amount=50.00 や amount=50 は 50 BTC として扱われ、amount=50,000.00 は無効である。
ビットコインクライアントは、利用者を欺かない範囲で、任意の書式で金額を表示してよい (MAY) 。 最も混乱を招かない書式を第一に選び、その上で要求された金額に対して最も合理的な書式を選ぶべき (SHOULD) である。 例えば、利用者の多数が BTC 単位で作業している間は、mBTC や TBC の方がより論理的な解釈であっても、既定では常に BTC で値を表示するべきである。
根拠
個人識別子ではなく、決済識別子
現在のベストプラクティスでは、すべてのトランザクションに対して固有のアドレスを用いるべきとされている。 したがって、URI スキームが表現すべきは、個人情報の交換ではなく、一回限りの決済である。
アクセシビリティ (URI スキーム名)
外部の人がたまたまそのような URI を目にしたとき、URI スキーム名そのものがすでに記述になっている。 あとは少し検索すれば、決済を行うのに必要な情報源にたどり着ける。 他に提案された名称はずっと暗号めいて聞こえる。誰かが好奇心からそれを検索する見込みは、ぐっと低い。 そのうえ、見つかるものの大半は技術仕様であり、ビットコインの入門としては最良ではない。
前方互換性
req- 接頭辞付きの変数は必須とみなされる。クライアントが req- 接頭辞付きの変数のいずれかを実装していない場合、URI 全体を無効と見なさなければならない (MUST) 。req- 接頭辞のない、未実装の他の変数は、安全に無視できる。
後方互換性
本 BIP の執筆時点で、いくつかのクライアントはこれに類似した bitcoin: URI スキームをすでに実装しているが、追加の「req-」 接頭辞要件を伴わないことが多い。したがって、本 BIP の最終化から 6 か月の猶予期間が経過するまでは、req- 接頭辞付きの追加変数を本番運用上 (mission-critical) に用いないことを推奨する。これにより、クライアント開発者は新版をリリースし、旧クライアントの利用者は更新できる。
付録
より単純な構文
この節は規範的ではなく、可能な構文をすべて網羅するものでもない。 規範的な構文には上記の BNF 文法を参照してほしい。
[foo] は省略可、<bar> は置換用プレースホルダーである。
bitcoin:<address>[?amount=<amount>][?label=<label>][?message=<message>]例
注: 以下の例で用いるアドレスは、誤った送金を防ぐため意図的に無効にしている。
アドレスのみ:
bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W名前付きのアドレス:
bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?label=Luke-Jr「Luke-Jr」 への 20.30 BTC の請求:
bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=20.3&label=Luke-Jrメッセージ付きの 50 BTC の請求:
bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=50&label=Luke-Jr&message=Donation%20for%20project%20xyz(現時点で) 解釈不能で必須かつ無効になる変数を含む将来版:
bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?req-somethingyoudontunderstand=50&req-somethingelseyoudontget=999(現時点で) 解釈不能だが必須でなく、有効になる変数を含む将来版:
bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?somethingyoudontunderstand=50&somethingelseyoudontget=999文字は適切に URI エンコードされなければならない。
参照実装
Bitcoin-Qt は、コミット 70f55355e29c8e45b607e782c5d76609d23cc858 の時点で、(req- 接頭辞のない) 旧版の Bitcoin URI を、Windows および KDE の統合と共にサポートしている。