Bitcoin URI

ビットコインURIはリンクであり、クリックすると支払い情報がすでに入力された状態でウォレットが開きます。BIP21が2012年1月29日にこの形式を定めました。スキームはbitcoin:、その後にアドレス、そして疑問符の後に任意のパラメータが続きます。アドレスだけではなくURIを受け取れば、正確にコピーしなければならないものの一覧から金額が外れます。

仕組み

BIP21の文法は意図的に小さく、この形式が10年以上にわたり変更されずに生き残ってきた主な理由はそこにあります。

完全なURIはbitcoin:bc1q...w5mdq?amount=0.00042&label=Coffee%20Shop&message=Order%20118のように書きます。コロンと疑問符の間にあるものがすべて宛先アドレスです。その後ろはアンパサンドで結合されたname=valueの組の集合であり、BIP21が定義しているのは3つだけです。

• amountはビットコインの10進数で、サトシ単位ではなく、ピリオドを使い、カンマや通貨記号を付けずに書きます。amount=0.01はビットコインの100分の1、すなわち1,000,000サトシを意味します。
• labelは支払いを受ける相手を指定するもので、店舗や個人などが入ります。
• messageは支払いの目的を表します。

両方のテキスト項目はUTF-8のパーセントエンコードであり、空白は%20になり、ラベル内のアンパサンドは%26になります。

2つの規則がこの形式の拡張性を保っています。未知のパラメータは無視されるため、古いウォレットでも新しいURIを支障なく読めます。req-で始まるパラメータは例外です。これを理解できないウォレットは、何を意図していたかを推測するのではなく、URI全体を拒否しなければなりません。この1つの規則がアップグレードの仕組みのすべてであり、それ以来あらゆる拡張を、古いソフトウェアを壊すことなく取り込んできました。

現在この形式が実際に生きているのは、こうした拡張の部分です。

• r=はBIP72が追加したもので、BIP70の支払いリクエストを指していました。この経路はすでに廃れています。
• pj=はBIP78によるもので、PayJoinのエンドポイントを指定し、支払者と受取人が共同で協調型のトランザクションを構築できるようにします。
• lightning=はオンチェーンのアドレスと併せてBOLT11のインボイスを運びます。これを理解するウォレットはライトニングネットワークで支払い、理解しないウォレットはアドレスにフォールバックし、加盟店の決済画面はその結果を単一の統合QRコードとして表示します。
• BIP353は_bitcoin-paymentラベルの下のDNSSEC署名付きTXTレコード内にURI全体を公開するため、人間が読める名前が支払い指示に解決されます。

アドレス自体は任意です。BIP21の文法はアドレス文字を0文字でも許容しており、bitcoin:?r=...がそう動作していたように、今日のオファーのみのURIもそう動作します。

ビットコインを購入するときにこれが重要な理由

ビットコインURIが最も重要になるのは出金の場面です。管理していない取引所からコインが出て、自分が管理する場所に届くときです。

当サイトに掲載している取引所のほぼすべて、KrakenやRiverからRelaiやBitpandaに至るまで、宛先アドレス用の単なるテキストボックスを用意しています。そのボックスが求めるのはアドレスであり、URIではありません。bitcoin:bc1q...を貼り付けると、通常は検証エラーになり、ときには警告なしに切り詰められた項目と出金の失敗を招きます。コロンと疑問符の間にあるものを取り出し、それだけを貼り付けてください。

やり取りは逆方向にも流れます。自身のハードウェアウォレットの受取画面、加盟店の決済画面、個人間取引はいずれも、アドレスそのものではなくURIを渡してきます。URIのほうが安全なのは1つの点だけです。金額がURIと一緒に移動するため、合計額を打ち間違えることがありません。最も重要な点では安全ではありません。URIの中身は何も署名されていません。label項目は文字列を作成した者が選ぶ自由記述であるため、フィッシングページがlabel=Kraken%20Withdrawalと書き込み、ウォレットが何の注記もなくその言葉を表示することがあります。

だからこそ、ハードウェアウォレットの画面が決定的な管理手段となります。URIが何を主張していても、署名デバイスは、これから支払うアドレスを、クリップボードのマルウェアが書き換えられない画面に表示します。先頭と末尾の文字を、リンクを生成したブラウザのタブではなく、デバイス上で比較してください。

実例：喫茶店の請求書を支払う

レジがQRコードを印刷し、スマートフォンがbitcoin:bc1q...w5mdq?amount=0.00042&label=Kaffeehaus&message=Table%207を読み取ったとします。

ウォレットはそこから3つの事実を解析します。0.00042ビットコインを支払い、そのアドレスに送信し、確認画面にKaffeehausとTable 7という言葉を表示する、という3つです。その後、URIが一切求めていないいくつかの処理を行います。未使用の出力のうちどれを使うかを選び、自身が把握するメモリプールの状況から手数料率を見積もり、お釣りの出力を追加し、承認を待ちます。

行わないのは、受取人に関する何かを検証することです。店舗がそのアドレスを管理しているか、0.00042ビットコインが合意された価格か、ラベルが正直か、といったことは確認していません。これらの確認は利用者自身の役割です。コーヒー1杯なら、失うのはコーヒー1杯です。5桁の送金なら、承認する前に署名デバイス上でアドレスを4文字ずつ区切って読む価値があります。

ビットコインURI vsアドレス

アドレスは指示を伴わない宛先そのものです。現代のbech32アドレスは、単一鍵のsegwit出力では42文字、taproot出力では62文字になり、いくら送るのか、誰に送るのかについては何も語りません。URIは入れ物です。アドレスに、任意の金額、ラベル、メッセージを加えたものです。URIからアドレスを復元するには、スキームと最初の疑問符の間のテキストを読めばいつでも可能です。逆方向はできません。アドレスはもともと金額を運んだことがないからです。

ビットコインURI vs BOLT11インボイス

BOLT11インボイスはライトニングネットワークにおける同等物であり、重要な3つの点で動作が異なります。1回限りであり、アドレスではなく支払いハッシュにコミットし、有効期限があり、加盟店が値を設定しない場合は既定で3,600秒です。ビットコインURIは有効期限がなく、2回支払うこともできます。これは寄付ページでは利点であり、請求書では危険です。統合QRコードは、通常のURIのlightning=パラメータの中にBOLT11の文字列を入れることで、どちらかを選ぶ必要をなくし、各ウォレットが対応する経路を使えるようにします。