LNURLとは？QRコードとLightning Addressでビットコイン支払いができる仕組みを解説

本記事ではLNURLやLightning Addressが使われるようになった理由や、送金・受金においてどのように内部処理が行われているかの詳細な仕組みについてを解説します。

普段Lightning Network(LN)送金を利用している方にとって、LNURL-payのQRコードやLightning Addressの@が付いた文字列で構成される送金先情報を目にしたことがある方は多いと思います。

例えば、LN送金に対応したウォレットアプリであるWallet of SatoshiではLNURLの仕様に則った送金・受金が可能です。

これは私のWallet of SatoshiウォレットのQRコードですが、QRコードにエンコードされているのがLNURLという文字列で、その下に表示されている「wokashi@walletofsatoshi.com」はLightning Addressです。

LNURLやLightning Addressがなぜ必要となったのかの経緯や、送金ごとにインボイス作成が必要なLNにおいてどのような仕組みで固定の文字列やQRコードで支払いが可能になっているかの詳細を整理します。

LN送金・受信のサービス提供や実装を検討している事業者やエンジニアの方は必読です。

また、普段Wallet of Satoshiなどのウォレットを使用して、表示されるQRコードの正体が気になる方も読んで仕組みを理解した上で使うことをお勧めします。

LNURLとは？

LNURLとは、LN上での支払い・引き出し・認証など各種操作を、URLを使って実現するための仕様（プロトコル群）です。

ユーザーはQRコードや文字列としてLNURLを受け取り、ウォレットがそのURLにアクセスしてサーバーと通信することで、支払いや引き出しが可能になります。支払い用インボイスの取得や条件確認などを自動で行えるようになり、Lightning決済のUXを向上する手段として広く使われています。

LNURLはプロトコル群であり、後述するLNURL-payやLightning Addressを包含しています。

プロトコル仕様はLNURL Documents(luds)にまとまっています。

LNURLの4つの機能

LNURLが定義する機能は、大きく4つに分けると理解しやすいです。

LNURL-pay: 受取側が提示したLNURLを読み取り、送金者が金額指定してインボイスを受け取って支払う仕組み。本記事で解説します。
LNURL-withdraw: 受取側がLNURLを読み取り「引き出し（受け取り）」用インボイスを作って支払いを受ける仕組み。
Lightning Address: LNURL-payエンドポイントをuser@domain 形式に変換する仕様。
LNURL-auth: LN公開鍵で署名して、パスワードなしにサービスへログインする仕組み。

本記事では、送金に関するLNURL-pay の仕様にフォーカスして解説します。そのため、類似したフローである出金用のLNURL-withdrawや、LNチャネル管理に関するLNURL-Channelという仕様については扱いません。

ビットコイン研究所でも、LNURLやLightning Address関連の記事はすでにいくつかあります。

✏️

本記事では LNURLとLNURL-pay、Lightning Addressについて中心に解説します。この3つの関係に混乱するかもしれないため、序盤で用語を整理します。
・LNURL-pay: 支払い時のQRコードの生成方法やLNURLサーバー挙動の仕様
・Lightning Address: LNURLサーバーのURLの表記方法について仕様
・LNURL: LNURL-payやLightning Addressなどの含む全体の仕様の総称

LNURLを使わない送金方法（オンチェーン/LN）の問題点

LNURLの解説に入る前に、ビットコインの送金 / 受金のイメージがつかない方向けにLNURLを使わないオンチェーン送金 / LN送金の方法からおさらいします。

オンチェーン送金

オンチェーン送金で資金を受け取る場合、受け取り手は自身のビットコインアドレスの文字列、またはQRコードを貼り付けるだけです。一つのアドレスに対して何度でも送金ができるので、送金者側も一つのアドレスに対して何度でも支払い可能です。

デメリットとしては、手数料が高くなる傾向があり、また着金完了までの待ち時間が発生します。そのため、投げ銭のような少額な寄付（いわゆるZap）に高い手数料を支払う場合にはオンチェーン送金は相性が悪いです。

LN送金

LN送金で資金を受け取る場合、受け取り手がインボイス（請求書）を作成し、それを送金者に渡すことで送金者は送金処理が可能になります。ただ、インボイスは使い切りなので一度支払いに使うとそれ以降は使えません。そのため、送金者は送金のたびにインボイスの作成を依頼する必要があります。

手数料が低いという点では少額の寄付には向いているものの、記事や動画に寄付先の情報としてインボイスを貼り付けたところで一度しか送金できないので、不特定多数からの寄付を受け取る場合ではLN送金単体では相性が悪いです。

LNURL-payを用いた送金の概要

なぜLNURLが必要になるか、さらにLNURLを使うことでどのように支払いを実現するかを、LNを使った投げ銭を試みる例で解説します。

LNURL-pay(投げ銭の例)

読者がブロガーに投げ銭のような寄付をユースケースとして考えます。

まず、ブロガーがLNURLに対応した受金方法を提示していると仮定します。本来やりたいことは上の図のような読者からブロガーに対する送金です。

しかし、上述した通り、LN送金では受け取り手によるインボイスの作成・提示が必要になるため、ブロガーの協力、応答なしでのLN送金は実現できません。読者はブロガーへ送金するのではなく、インボイス作成を依頼する必要があります。

ブロガーは、読者からのインボイス作成依頼に都度対応するのは面倒で、かつ読者にとっても都度コミュニケーションを求められるのは面倒です**。**

LNURLが定義している仕様は、このインボイス作成依頼とインボイスの応答までのメッセージのフローやメッセージの項目などのプロトコルです。このプロトコルに準拠していることで、 LNURLのQRコードを読み取るだけで、ブロガー側はよしなにインボイス作成と送付、読者側はインボイスの受け取りと支払いができるようになります。

より詳細に図示すると、ブロガー側の最小・最大投げ銭可能料金などの設定情報やブロガーのメタデータを含むブロガー側の受金ポリシーの確認をした上でインボイスの作成依頼が可能になります。

上の図のように、ブロガーは受金ポリシーのレスポンス送信やインボイスの作成・送付を自動で行う必要があります。そのためブロガーは応答を行うサーバーとしての機能を運用する必要があります。

LNURLの構造：QRコードだけで送金できる理由

ではなぜQRコードを読み取ることで送金相手の情報が取得でき、インボイス作成を依頼できるのでしょうか？

QRコードにはLNURLの受金ユーザー（ブロガー）サーバーのURLが含まれており、そのURLに対してインボイス作成依頼をHTTPリクエストで投げることができるからです。具体的にはサーバーのURLを可逆的に変換可能なbech32でエンコードした文字列をQRコードに変換しています。

送金者はQRコードを読み取ると、 LNURLが取得でき、bech32デコードをすることで送金相手の送金先情報を持つサーバーのURLを取得できます。

Lightning Addressの仕組み

Lightning Addressは「wokashi@walletofsatoshi.com」のようにメールアドレスに似たURIを送金の宛先情報として用いることができる仕様です。

Lightning AddressはLNURL-pay仕様に則っているため、Lightning AddressをサーバーのURLに変換した後の処理はLNURL-payと全く同じになります。Lightning Addressが仕様で策定しているのは「受金者サーバーURL」の識別性と可読性を向上させるためのサーバーのURLを@で繋ぐ識別子に構成する手順の部分のみです。

サーバーのURLからLightning Addressへの変換方法 / 出典: Lightning Address by ZBD から部分的に引用

Lightning Addressは構成方法は「LNURLサーバーのドメイン」と「そのサーバーの/.well-known/lnurlp/~に続くパスに配置された設定ファイル名」を並び替えて@マークで繋ぐだけです。

支払い先の情報としてLightning Addressを受け取った送金者は、Lightning Addressを並び替えてURLを構成しなおすことで、その後の送金処理はLNURL-payと同様の手順で進めることができます。

LNURLサーバーの挙動: ドメイン解決から受金ポリシー応答まで

では、これまで説明してきたLNURLの仕組みの要素を整理し、読者がブロガーのLightning Addressに対して送金を行う処理の手順を解説します。

読者はブロガーのLightning Addressを確認し、Lightning AddressをURL形式に変換します。
読者はURLのドメインをDNSサーバーに問い合わせします。
DNSサーバーは問い合わせされたドメインを解決し、ドメインに設定されたブロガーのサーバーのIP:Port含む設定情報を読者に送ります。
読者はドメインから取得したIP:PortとLightning Addressの前半文字列をもとに、ブロガーサーバーのIP:Port/Pathに接続し、ブロガーの受金ポリシー情報を取得します。

Wallet of Satoshiのサーバーに設定された筆者の受金ポリシーであるhttps://walletofsatoshi.com/.well-known/lnurlp/wokashi を開いてみると、以下のようなJSON文字列が返ってきます。これが受金ポリシーの情報です。

受金ポリシーの情報をもとに、読者はcallback項目で指定されたURLにインボイスのリクエストを投げると、ブロガーのLNURLサーバーが自動でインボイスを作成し読者に返送します。これにより、読者はブロガーに対して投げ銭したい金額に応じたインボイスを受け取ることができ、送金が可能な状態になります。

上述した例ではWallet of Satoshiが運営するウォレットサービスのアドレスなため、受金用サーバーURLのドメインは「walletofsatoshi.com」になっています。

もちろん他のドメインも使用可能で、自身で取得したドメインをLightning Addressとして使用することも可能です。詳しい手順は以下の記事で加藤規新さんが解説しているので、そちらを参考にしてください。

まとめ：LNURLの相互運用性とトラストレス性の改善への期待

本記事では、オンチェーン・LN支払いにおけるUX面での問題点を説明した上で、LNURL / Lightning Addressが支払い体験を解決できる理由を解説しました。投げ銭を例に、LNURL / Lightning Addressの詳細な仕組みを解説し、受金者側のLNにおけるインボイス作成操作を省略した送金が可能になることという利点を整理しました。

LNURLと類似する提案として、BIP-21 / BIP-353やBOLT12が提案されています。

個人的には相互運用性が重要だと考えており、これらの仕様をユーザーが意識しなくても使える、もしくは失敗した場合でも適切に処理できるようなプロトコルにまとまることを期待しています。

LNURLはサーバーやDNSに依存している点ではトラストレスとは言えません。あくまでLN送金の利便性を高めるための仕様です。 LNURLはあくまでビットコインやLN開発、プロトコル仕様策定をしているコミュニティとは関係のない、独立した主体が提案するプロトコルであるため、そもそもトラストレス性を求めるのは筋違いにも思えます。

それでも「LNURLはトラストレスじゃないからイケてない」と感じたそこのあなた、研究ネタが見つかりましたね。より良いプロトコルを考えてOpenSatsのサポートを受けながらビットコインエコシステムの改善に取り組んで見てください。