エンドユーザーでもライトニングネットワークの利用時に必ず目にするインボイス。現行の形式のかゆいところに手が届く、新しいインボイスの仕様が提案されています。今日はライトニングの新しいインボイスの仕様として提案されているBOLT12について見ていきます。
BOLTとは
Basis of Lightning Technology (BOLT)とは、ライトニングネットワークの仕様を定めた仕様集です。現時点ではBOLT0～5と7～11が定められています。(6番は7番に置き換えられて欠番です)現在のインボイスの形式を定めたBOLT11の欠点を改善するものとして、今回紹介するBOLT12が提案されています。
現在のインボイスの不自由な点
BOLT11に定められている現在のインボイス形式は、送金を受け取りたい方がインボイスを発行して、送金する側がそのインボイスに従って送金し、送金が完了するとインボイスの作成に使用されたプリイメージというデータを受け取って確認できるというものです。本コラムでもおなじみですね。まず、このインボイスの形式には使っているうちにわかってきた不自由な点がいくつかあります。例えば、インボイス自体はQRコード表示などに便利なbech32という形式でエンコーディングされていますが、これに問題が発見されたり、LN自体で(後述の支払ってほしいインボイスを送りつける際など)bech32のデータをやり取りする際に厄介になっているので、変えようという意見があります。また、通常のインボイスは安全に使えるのは1度きりで、毎度発行する必要があり、使い回せません。今のところ実際の運用ではLNURLというウォレットの仕様群で解決するのが主流ですが、ライトニング自体の公式の仕様ではないため、ウォレットやウェブサイトなどが対応していないと利用できません。他にも、今年発覚したLNDの脆弱性の防止策としてプリイメージに加えてpayment_secretという識別情報を使う話がありましたが、これもインボイス自体が第三者の手に渡る場合は機能しません。インボイス自体の署名も、証明する際にインボイスの全体を開示する必要があります。不自由な点はそれ以外にも挙げられていますが、BOLT12は新しいインボイスの仕様を使ってそれらを改善する提案です。
BOLT12 "OFFERS"とは
ライトニング払いをしたい買い手を「ユーザー」、ユーザーに何かを売った売り手を「マーチャント」とします。「オファー」はBOLT12が指定する、インボイスの発行または支払いを要求するためのリクエストを送るためのデータです。