ライトニングネットワークを用いたペイメントにはインボイスという１回１回の支払いごとに異なる情報が用いられます。そのため、非推奨ながらも固定のアドレスを使い回せるオンチェーンの送金と異なり、ライトニングで送金を受け取るにはインボイスの発行という手順が最初に必要になります。

送金を送金者から開始したい場合に、宛先のノードにインボイスの発行を依頼する方法は前からいくつかありましたが、最近このあたりを考えている人が多いように感じます。今日は8/20にリリースされたLightning Addressを紹介し、他の方法との類似点や違いを見ていった後に、将来的にどうなるのか予想してみます。

https://lightningaddress.com/

既存のインボイス請求方法

既存のインボイス請求方法で一番有名なのは圧倒的にLNURL-Payだと思われます。これはLNURLという仕様群の１つで、ノードの運営者がLNURLのリクエストを捌くサーバーを動かすことで、「インボイスをくれ」「はい、どうぞ」という流れなどを自動化することができます。

毎回異なるインボイスと違い、LNURLは変更せず使えるURLなため、印刷したり、動画にかぶせて使用することができます。インボイスの要求と返信はライトニングネットワーク上ではなく、ウェブや紙面など他の媒体を介して行われます。

店頭でPayPay払いに使用するQRコードがあるものと、POS端末でバーコードをスキャンしてもらうものがありますが、LNURL-PayはまさにQRコードとして置いておくだけで使えるものです。

Tippin.meやZebedee Gamertagのようなカストディアルなサービスもあります。このようなサービスは、ユーザー名のようなものに対して送金することができ、送金された資金を預かっています。ユーザー名とは異なるアプローチですが、電話番号宛に送金するSat2.ioのようなプロジェクトも同類とみなすことができるでしょう。(ただし先程確認しに行ったところ、サイトがエラーで落ちていました)

カストディアルなサービスは徐々に規制されていくと考えられますが、ユーザーエクスペリエンスが非常にシンプルなので人気であり続けると私は予想しています。

また、この機能をライトニングネットワークのプロトコル自体に追加するという動きがあり、Offersという仕様がライトニングネットワーク上のプロトコルにBOLT12として採択されました。Offersは事実上LNURL-Pay (インボイスの要求)とLNURL-Withdraw (送金提案に応じるインボイスの送信)の２つの機能を、ライトニングネットワーク上で完結するように実装したものです。

Offersはライトニングネットワーク上の話なので、カストディアルなサービスなどからユーザーが直感的に利用する方法は(まだ)ありません。

LIGHTNING ADDRESS

8月20日に発表されたLightning Addressは、ゲーム用ライトニングウォレットを開発するZebedeeのAndre Neves氏とLNURLの生みの親でもあるfiatjaf氏のプロジェクトです。見た目がメールアドレスのような「ライトニングアドレス」を使用できること、LNURL-Payの拡張であることが特徴です。

Lightning Address宛に送金するには、ウォレットがLightning Addressを決まったルールに従ってURLに変換し、そこから先はLNURL-Payと同様にインボイスをリクエストすることでできます。

例えばsatoshi@bitcoin.orgというLightning Addressに送金するには、ウォレットがhttps://bitcoin.org/.well-known/lnurlp/satoshi というアドレスに待ち構えているLNURL-Payサーバーに対してインボイスをリクエストすることになります。

逆にLightning Addressを使って送金を受け取るには、LNURL-Payで送金を受け取るのと同じく、簡単なHTTPサーバーが必要になります。サーバーは独自で運用することもできますし、独自ドメインでノンカストディアルにLightning Addressを利用することもできます(bridgeaddrというツールか、Sataddrというツールを利用)。

ただし、外部のサーバーを利用するにはDNSにInvoice Macaroonというノードにインボイスを発行させる権限を与える認証情報を載せるか、直接管理者に渡す必要があります。インボイスの発行のみを許可するよう設定したInvoice Macaroonを新規作成するのが一番安全です。

間違えて必要以上の権限のある認証情報や、送金権限を与える認証情報や、管理者権限を与える認証情報 (Admin Macaroon)を公開しないよう注意が必要です。少し面倒ですがセルフホストが一番安心ですね。

注意点として、ノードやサーバーがオフラインではインボイスを返すことができないので、それら両方のオンライン状態を維持する必要があります。この点はノード管理もやってくれるカストディアルなサービスと比較しての弱点といえます。

LIGHTNING ADDRESSは普及する？

インボイスを要求する新しい仕組みにとって共通の課題は、果たして多くのウォレットが対応するかどうかです。

すでにウォレットによっては「Offersが出るからLNURLは実装しない」のような選り好みをしているので、新規の方式はどれもアドプションに苦労しそうだなという印象があります。その点、Lightning Addressはすでに広く普及しているLNURL-Payのとても小さな拡張であり、実装がとても簡単な点において有利そうです。

LNURL自体の課題として、素のLNURLは可読性が低く、QRコードとして提示されることが多いですが、インボイスもまたQRコードとして表示されることが多いため、対応していないウォレットに遭遇したときにユーザーの混乱を招きます。

その点、Lightning Addressのユーザー名＠ドメインという見慣れたフォーマットは直感的であったり、QRコードにする必要が少なく、人間に判別しやすいところが意外と大きい長所なのではないでしょうか。(逆にメールも送られてきそうですが。笑)

BOLT12 Offersも優れていますが、どうしてもユーザーがノードを持っている前提があり、ノード公開鍵も可読性が低いものなので結局QRコードで表示することになります。プロトコルに組み込まれる以上、徐々にモバイルウォレットも対応すると考えられますが、人間側のUXの考慮はLightning Addressに軍配が上がるでしょう。

したがって、LNURL-Payがすでに広く普及しており、Lightning Addressのメールアドレスのような書式が直感的でわかりやすいことから、Lightning Addressはカストディアルウォレット・モバイルウォレットの間でまず普及し、設定が面倒・不安なことからセルフホストしているノードの間ではあまり流行らない、と今のところは予想しています。