BOLT 12

カフェが任意の寄付用に一つのコードをカウンターに置きたいとします。同じ通常のBOLT 11インボイスを繰り返し払うと問題が生じます。BOLT 12では代わりにofferを公開します。お客さんのウォレットはそれを基にinvoice_requestを送り、自分用のインボイスを求めます。受取側が新しいinvoiceを返してから、初めて支払えます。一枚のQRを複数の人が使っても、同じインボイスを共有するわけではありません。fetchinvoiceなどでインボイスを取得しても、まだ送金はしていません。オファーだけでカフェが他人のウォレットから追加の支払いを引き落とせるわけでもありません。 [1] [3] [4]

オファーの価格はビットコインだけでなく別の通貨でも示せます。offer_currencyはISO 4217のコードを使い、たとえばUSDの金額はセント単位です。インボイス発行時には数量や為替換算が反映されることがあります。ただし、最終的なビットコインのinvoice_amountはsatoshiの千分の一であるmillisatoshi単位で、1000 msat = 1 satです。支払う人は、元の値札だけでなく、この金額と手数料を支払い前に知る必要があります。要求が正確なinvreq_amountを指定していれば、インボイスは一致しなければなりません。それ以外は許可した範囲をウォレットが確認し、範囲外なら改めて承認を求めるべきです。換算を、どんな価格にも黙って同意したことにしてはいけません。 [1] [3]

印刷したコードを置いたままでも、オファー自体はoffer_absolute_expiryで期限を設定できます。各インボイスには別途、作成時刻invoice_created_atと有効期間invoice_relative_expiryがあります。期間がなければ標準は7200秒、つまり二時間です。古いインボイスは永久に有効な連絡先ではありません。ウォレットはメッセージに書かれた必須機能にも対応する必要があります。未知の偶数ビットは必須機能として拒否し、未知の奇数ビットは任意として無視できます。安全な互換性のための仕組みであり、利用者がコードを手直しして乗り越えるべき障害ではありません。 [1]

支払い後はインボイスとウォレットの結果を保存します。決済の証拠には、支払い完了時に得られる秘密値であるpreimageも含まれます。ウォレットはこの値から照合用の値であるハッシュを計算し、インボイスの支払いハッシュと比較します。インボイスと組み合わせれば決済されたことを示せますが、それだけでは誰が支払ったかは分かりません。アプリが切断したり応答を失ったりしたら、再試行前に前の支払い状況を調べます。新しいインボイスは別の支払いにつながる可能性があります。定期払いの宣伝にも同じ注意が必要です。BOLT 12対応は、すべての拡張機能への対応や自動引き落としの許可を意味しません。オファーを使った受取、他人のオファーへの支払い、接続したアプリに与えた権限をそれぞれ確認します。 [1] [3]

インボイスの要求と送金では、ネットワークを使う目的が違います。offer_pathsは要求メッセージの経路、invoice_pathsは支払いの経路です。BOLT 12はblinded pathsという、受取側への接続情報の一部を隠す経路を使います。ネットワーク構造を公開しすぎないことはプライバシーに役立ちますが、完全な匿名性を約束しません。隠した経路でも、相手の稼働や流動性、つまりチャネルの必要な側に十分な資金があることは保証されません。技術上、現在のinvoiceにはこの経路と対応するinvoice_blindedpayの支払い条件が必要で、相手へ直接つながる経路でも同じです。インボイス要求に従来型のHTTPS決済サーバーは必要ありません。 [1] [2]

店が返金するときは、やり取りの方向が逆になります。これから払う側は、先行するofferなしでinvoice_requestを公開できます。受取人になるお客さんが自分のinvoiceを返し、店がそれを支払います。元の支払いを消したり取り消したりするのではなく、逆方向の新しい支払いです。店は、インボイスが意図した受取人のものか確認する必要があり、プロトコル外の連絡が必要な場合もあります。要求をスキャンしただけでは返金の権利を証明せず、送金も承認しません。技術的な流れは連絡を助けますが、誰に返すべきかを決めてはくれません。 [1]

BOLT 12はデータをTLVで格納します。各フィールドが型、長さ、値を示す形式です。テキストのオファーはlno、要求はlnrで始まります。文字集合はBech32に似ていますが、末尾のチェックサムはありません。それだけで誰に払ってよいかは決まりません。offer自体は未署名です。BIP340 Schnorr署名で検証するのは、インボイスと、オファーに応じて送る通常の要求です。返金時などに、先行するオファーなしで単独で公開する要求には署名がありません。署名はMerkle構造の根、つまり関連フィールドをまとめて計算した照合用の値に結び付いています。そのため、常に詳細をすべて公開せずに、選んだフィールドを証明できます。署名済み条件を書き換えてよいわけでも、店主の法的な身元が証明されるわけでもありません。 [1]

ウォレットは、正しく署名された何らかのインボイスではなく、自分の要求への回答を受け取ったと確認する必要があります。invoice_requestからinvoiceへ引き継いだフィールド、ネットワーク、金額、署名を照合します。公開鍵invoice_node_idはoffer_issuer_idに一致する必要があります。その識別子なしで該当する隠れた経路を使うオファーなら、経路終端のblinded_node_idを確認します。伝票の印が本物かだけでなく、自分のテーブルの会計か調べるようなものです。Merkle構造が選択的な証明を可能にしても、支払いに必要な条件全体を確認する責任は残ります。他人の有効なインボイスが、署名検査に通るだけで正しい請求書になることはありません。 [1]