BOLT 12

受取人が offer を公開し、支払人が invoice_request を送って新しい invoice を受け取ります。その後に支払えます。複数人や繰り返しの支払いに同じオファーを使えます。fetchinvoice などで請求書を取得しても支払いにはならず、公開 QR は継続的な引き落とし許可ではありません。 [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice] [BOLT 12 — Project overview]

BOLT 12 はフィールドを TLV として格納します。テキストのオファーは lno、要求は lnr を接頭辞とし、文字集合は Bech32 に似ていますが末尾チェックサムはありません。Offer 自体は署名されません。要求と請求書の BIP340 Schnorr 署名はフィールドの Merkle ルートを検証し、販売者の身元は検証しません。 [BOLT 12 — Negotiation protocol]

ウォレットは invoice_request から invoice にコピーされたフィールド、金額、チェーン、署名を比較します。invoice_node_id は offer_issuer_id または対応する終端 blinded_node_id と一致する必要があります。無関係な有効署名では不十分です。Merkle 構造はフィールドの選択的証明を可能にしますが、署名済み条件の自由な変更は認めません。 [BOLT 12 — Negotiation protocol]

Bitcoin の invoice_amount は msat 単位で、1000 msat は1 satoshi です。offer_currency は ISO 4217 の別通貨を指定でき、例えば USD はセント単位です。数量や請求書発行時の換算が価格に影響します。invreq_amount があれば金額は一致する必要があり、なければ許可された範囲を確認します。 [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice]

offer_paths は要求メッセージ、invoice_paths は支払いを運びます。現在の invoice は、受取人への直接経路でも blinded paths と対応する invoice_blindedpay を含む必要があります。経路の盲化は構成の公開を抑えますが、完全な匿名性、可用性、流動性は保証しません。請求書の要求に通常の HTTPS 決済サーバーは不要です。 [BOLT 12 — Negotiation protocol] [BOLT 4 — Route blinding]

offer_absolute_expiry はオファーの利用を制限します。invoice_created_at と invoice_relative_expiry は個別請求書を制限し、後者の省略時は7200秒です。再利用可能なオファーでも請求書は永久に有効ではありません。未知の偶数の必須機能ビットは拒否し、未知の奇数ビットは無視します。 [BOLT 12 — Negotiation protocol]

返金では、送金する側が offer のない invoice_request を公開できます。お金を受け取る側が自分の invoice を返し、支払人は必要に応じてプロトコル外で意図した受取人を確認します。これは元の決済の取り消しではなく新しい支払いです。要求を読み取るだけでは受給資格や支払い承認を証明しません。 [BOLT 12 — Negotiation protocol]

Invoice、支払い状態、対応する preimage を保存します。Preimage は請求書の決済を示しますが、それだけで支払った人物は分かりません。応答を失ったら再度払う前に状態を確認します。オファー対応は全拡張や自動定期払いへの対応を意味しません。受取、送金、アプリの権限を個別に確認します。 [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice]