BOLT 11

アンナが電子書籍を買うとします。店は銀行口座の代わりにLightningインボイスを表示し、ウォレットが支払い情報を読み取ります。アンナは長い文字列を理解する必要はなく、承認前に金額、用途、手数料を確認します。任意の寄付などでは金額が未指定のこともあります。その場合は支払う人が入力します。未指定でも、支払額がゼロという意味ではありません。少し詳しく見ると、先頭のlnbcはメインネット、lntbはtestnet、lntbsはsignet、lnbcrtはregtestを表し、後者はテスト環境です。記録された金額はsatoshiではなくBTC単位で、必要に応じて倍率m、u、n、pが付きます。pの場合は整数のmillisatoshiになるよう末尾を0にする必要があります。1000 msat = 1 satです。 [1]

説明文は、技術的な要求をアンナの本の代金といった具体的な用途につなぎます。インボイスにはdフィールドの本文か、hフィールドのデジタル指紋のどちらかが入ります。この指紋はSHA256で計算されます。文章から計算して得られる、この短い照合用の値をハッシュと呼びます。ウォレットは、別途受け取った説明文から同じ指紋が得られることを確認しなければなりません。指紋だけを見ても注文内容は読めません。有効な署名は説明文を受取側の鍵と結び付けますが、店が本を届けることまでは保証しません。アプリの開発者にも注意点があります。説明文は外部から来たテキストなので、安全にデータとして表示し、コードとして実行してはいけません。 [1]

アンナが注文画面を開いたままにして、後から戻ると、期限切れと表示されるかもしれません。その場合は新しいインボイスを求めます。有効期限は作成時刻timestampと期間xから計算します。xがなければ標準は3600秒、つまり一時間です。期限切れになっても、完了した支払いが取り消されるわけではありません。cフィールド、正式にはmin_final_cltv_expiry_deltaは別の時間を定めます。経路の最後にある条件付き支払いHTLCの時間的な余裕です。HTLCは、期限内に正しい秘密値を示すことを決済の条件にします。この余裕は秒ではなくブロック数で測り、cがなければ支払側は少なくとも18ブロックを使います。インボイスの有効期限と混同してはいけません。 [1]

Lightningの支払いは決済チャネルを通ります。チャネル内では、二者が資金の配分を更新し、通常の支払いのたびにBitcoinのメインブロックチェーンへ記録する必要はありません。成功には使える経路と、各チャネルの適切な側に十分な資金、つまり流動性が必要です。rフィールドには最後の区間の手掛かりであるrouting hintsを含められます。受取側を見つける助けにはなりますが、現在使える容量を示す情報ではありません。ノードの公開鍵、チャネル識別子、手数料の条件を明かす場合もあるため、インボイス全体を非公開情報だと考えないでください。任意のfフィールドには、代替手段として通常のBitcoinアドレスを載せられます。その宛先への支払いはメインチェーンを使い、独自の手数料と承認待ちが生じます。同じ届け方でボタンだけが違うわけではありません。 [1] [2] [5]

QRを読み取ったことやインボイスを受け取ったことは、領収書にはなりません。送信後はウォレットの結果を確認します。保留中と完了は違います。決済の証拠には正しいpreimageも使われます。ウォレットはこの秘密値からハッシュを計算し、インボイスの支払いハッシュと一致することを確かめます。インボイスと一緒に支払いの証拠として保存できますが、商品の受け渡しまで保証するものではありません。接続が切れたり応答を失ったりしたら、まず元の支払い状況を調べます。すぐに新しいインボイスを求めたり代替アドレスへ払ったりすると、二重払いになりかねません。再試行を認識するウォレットもありますが、この形式だけでアプリや支払い経路をまたぐ万能な防止策が得られるわけではありません。 [2] [4]

長い文字列にはBech32という符号化方式を使います。チェックサムは転記ミスの検出を助けますが、暗号化ではなく、内容を隠しません。secp256k1上のECDSA電子署名には別の役目があります。支払い情報が受取側の鍵に対応し、後から変更されていないことを確かめます。鍵の持ち主の法的な身元や誠実さを証明するものではありません。BitcoinのBech32アドレスとは異なり、BOLT 11は90文字を超えても構いません。QRには大文字が適しますが、有効な文字列で大文字と小文字を混ぜてはいけません。人は通常スキャンやコピーをし、これらの確認はウォレットが行います。 [1]

payment hashは、秘密値payment preimageをSHA256に通して得られるデジタル指紋で、pフィールドに入ります。決済が成功すると支払側はpreimageを知り、指紋の一致を確認できます。一方、sフィールドはpayment_secretを含みます。支払側はこの値をインボイスから読み、経路の最後で受取側へ渡します。これは中継ノードによる探りから受取側を守る助けになります。Secretはpreimageでもウォレットのseedでもありません。QRから読めたとしても、支払いの証明やウォレット復元の権限にはなりません。現在のBOLT 11ではpとsの両方が必須です。似た名前でも、支払いの識別、必要な値の伝達、決済の証明という役割は異なります。 [1] [2]

ウォレットは要求された支払いを実行できるかも確認します。9フィールドには機能フラグが入ります。未知の偶数ビットは必須機能なので支払いを拒否し、未知の奇数ビットは任意なので無視できます。既知の機能間の依存関係も満たす必要があります。たとえばBasic MPPは一つの支払いを複数部分に分け、受取側でまとめる仕組みです。インボイスがbasic_mppを提示している場合にだけ利用できます。分割しても独立した複数の請求にはならず、各部分を再び払う理由にもなりません。初心者にとっての要点は、未対応機能の警告をインボイスの手修正で回避しないことです。まずウォレットの互換性を解決します。 [1] [3]