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の統合と共にサポートしている。