BOLT12オファー

オファーは、支払われた後も有効なまま残る支払いの要求であるため、一度印刷したコードがすべての顧客に使えます。オファーには署名もチェックサムもなく、そのフィールドはTLVの種類2から22を占めており、低価格帯のスマートフォンのカメラで読み取れるよう意図的に短くされています。ビットコインを受け取る立場なら、これは一度印刷するコードと、そのコードが発行するインボイス（7200秒後に失効します）との違いです。

仕組み

BOLT12のオファーは、人間が読める接頭辞のlno、区切り文字の1、続いてそのレコードを順番に運ぶbech32形式の文字列で書かれた、type-length-valueレコードの連なりです。

末尾に6文字のチェックサムはありません。仕様はこれを省いています。QRコード自体がチェックサムを持っており、壊れたオファーは支払いが失われるのではなく解析できない文字列になる、という理由です。長いオファーはプラス記号（任意でその後に空白）で分割でき、文字数制限のあるテキスト欄に貼り付けても保持されます。読み取る側はデコードの前にプラス記号と空白を取り除かなければなりません。書き込む側はすべて小文字かすべて大文字を使わなければならず、QRコードには大文字を選ぶべきです。

フィールド自体には番号が振られています。offer_chainsは2、offer_metadataは4、offer_currencyは6、offer_amountは8、offer_descriptionは10、offer_featuresは12、offer_absolute_expiryは14、offer_pathsは16、offer_issuerは18、offer_quantity_maxは20、offer_issuer_idは22です。書き込む側は種類1から79の範囲に収めなければならず、実験用として1000000000から1999999999の第2の範囲が別に用意されています。この一覧に署名はなく、それは意図的です。署名すると利点がないまま文字列が長くなるだけです。署名以外のすべてのフィールドは後続のリクエストにコピーされるため、改ざんされたオファーは単に請求書を生成しないからです。

支払いにはさらに2つのメッセージが必要です。ウォレットはオニオンメッセージでinvoice_requestを接頭辞lnr付きで送信し、理解できないものを含むオファーの全フィールドをコピーし、その結果にMerkleルートに対するBIP340署名を付けます。発行者は署名済みの請求書で応答します。Merkleの構成は各フィールドのリーフをnonceのリーフと対にするもので、これにより支払者は後から、係争中の請求書の1つのフィールドだけを隣接するフィールドを明かさずに公開できます。文字列全体に対するBOLT11署名にはできないことです。

この3つのメッセージのうち2つは、返金やATMでは逆向きに流れます。加盟店が送りたい金額を指定したinvoice_requestを公開し、利用者が請求書で応答し、加盟店が支払い前にinvoice_node_idを確認します。

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

オファーは支払いを受ける手段の公開方法を変えるものであり、支払いを受けるコストについては何も変えません。

当サイトのPhoenixのレビューを例に取ります。ACINQは利用者に発見させるのではなく手数料表を公開しています。ライトニングネットワークでの送金は0.4%に加えて4サトシ、受取は受信流動性がすでにあれば無料、ウォレットが場所を空けるためにオンチェーンに移行しなければならない場合の受取は1%にマイニング手数料を加えた額で、新しいチャネルは1,000サトシです。請求書の代わりにオファーを渡しても、これらの数字はどれも変わりません。なくなるのは支払者ごとに新しいコードを発行する手間であり、誰かが流動性の対価を支払う手順ではありません。

プライバシーの利点は現実のものですが限定的です。ライトニングアドレスは請求書の要求をすべて誰かのドメイン上のWebサーバー経由で転送するため、その運営者は金額とタイミングを見ます。オファーは要求をオニオンメッセージとしてライトニングネットワーク経由で転送し、offer_pathsにより、チャネルがすべて非公開のノードでもノードIDを一切公開せずに到達可能なままにできます。それが与えないのは、自分のプロバイダーに対するプライバシーです。当サイトのPhoenixのレビューは、ACINQのFAQが支払いの最終的な宛先と金額を知っていると明言している箇所を引用しています。

実務上の注意は貼り付けに関するものです。取引所の出金欄はライトニングネットワークの請求書を求めますが、lno1で始まる文字列は請求書ではありません。当サイトの63件の取引所レコードの1つであるStrikeはライトニングネットワークにネイティブで、100か国を超える送金に独自の手数料を加えません。まさに2つの形式が混同されやすい流れです。当サイトの41件のウォレットレビューと63件の取引所レコードはいずれも、現時点でオファー対応を機能として記載していません。そのため、当然のものとせず、ご自身のウォレットのリリースノートで確認すべき事項として扱ってください。

帽子店のオファーと、それがなる請求書

25ドルで帽子を売る店が、offer_currencyをUSD、offer_amountを2500に設定したオファーを書きます。

これがビットコイン以外の通貨に関する仕様の規則です。3文字のISO 4217コードを使い、金額はISO 4217の指数で調整した通貨単位で表します。ドルの場合はセントになります。offer_amountを設定すると、offer_descriptionが必須になります。特定の品物に対して請求される支払者は、それが何だったのかを知る必要があるからです。帽子が3つ残っていればoffer_quantity_maxは3、店に固定の上限がなければ0です。1という値は、見た目は奇妙でも明示的に認められているため、在庫システムが最後の1点のために特別な処理を必要とすることはありません。offer_issuerはhats@example.com Hat Stallのようになります。仕様は最初にドメイン、スペースの後に任意の親しみやすいテキストを求めるからです。

ウォレットはこれを読み取り、25ドルを提示し、帽子2つ分のinvreq_quantityを2、invreq_payer_id、任意でinvreq_payer_noteを含むinvoice_requestを送信します。返ってくるのは、支払いハッシュ、作成タイムスタンプ、少なくとも1つのブラインド経路、経路ごとの手数料見積もり（基本手数料、比例手数料、CLTVデルタ、運ぶHTLCの最小額と最大額）を含む請求書です。ここでは2つの規則が利用者を守ります。ウォレットは、0から159の範囲のいずれかのフィールドが送信内容と一致しなければ請求書を拒否しなければならず、ミリサトシ単位の金額がオファーのドル見積もりと大きく異なる場合は警告しなければなりません。発行者がinvoice_relative_expiryを設定しない限り、請求書は作成から7200秒後に拒否しなければなりません。

BOLT12オファーvs BOLT11インボイス

BOLT12オファーは支払い要求の要求であり、BOLT11インボイスは支払い要求です。

BOLT12の文書は、前身に対する8つの不満から始まります。支払者が実感するのは次の4つです。BOLT11請求書は全体として署名されるため、1つのフィールドを証明するにはすべてを開示する必要があります。人間が読める金額は、仕様の判断では問題が多かったとされ、p乗数はしばしば誤って扱われ、pico-bitcoinはサトシよりも数えにくいものでした。payment_secretは、請求書が支払者と受取人の間で非公開のままである間しか探査を止められず、公開された請求書はそうではありません。そして仕様自身の言葉によれば、請求書はユーザーごとに与えなければならず、同一ユーザーに対して2回の支払い試行が行われると積極的に危険です。オファーは、そもそも請求書ではないことでこれら4つすべてに応えます。

BOLT12オファーvsライトニングアドレス

BOLT12オファーは自己完結した文字列であり、ライトニングアドレスは誰かのサーバーが利用者のために解決する名前です。

どちらも再利用可能であるため混同されます。アドレスはドメイン、証明書、サービスを稼働させ続ける運営者に依存し、そのいずれかが失われた日に機能しなくなります。オファーは両方のノードがオニオンメッセージを扱えることにのみ依存し、障害の範囲はより小さくなりますが、これは当然のものとせず、ご自身のウォレットが対応していることを確認する必要があります。アドレスは口に出して言える点で優れています。長いlno1文字列はQRコードであり、マイクに向かって読み上げるものではありません。