ライトニングネットワークのインボイスは長い文字列で可読性が低く、有効期限もあるため、比較的扱いにくい形式のデータでした。それを解決すべく、LNURLそしてLN Addressという技術が生まれました。
Lightning Addressと乱立するインボイス請求方法
ライトニングネットワークを用いたペイメントにはインボイスという1回1回の支払いごとに異なる情報が用いられます。そのため、非推奨ながらも固定のアドレスを使い回せるオンチェーンの送金と異なり、ライトニングで送金を受け取るにはインボイスの発行という手順が最初に必要になります。 送金を送金者から開始したい場合に、宛先のノードにインボイスの発行を依頼する方法は前からいくつかありましたが、最近このあたりを考えている人が多いように感じます。今日は8/20にリリースされたLightning Addressを紹介し、他の方法との類似点や違いを見ていった後に、将来的にどうなるのか予想してみます。 https://lightningaddress.com/ 既存のインボイス請求方法 既存のインボイス請求方法で一番有名なのは圧倒的にLNURL-Payだと思われます。これはLNURLという仕様群の1つで、ノードの運営者がLNURLのリクエストを捌くサーバーを動かすことで、「インボイスをくれ」「はい、どうぞ」という流れなどを自動化することができます。 毎回異なるインボイスと違い、LNURLは変更せず使

今では多くのウォレットやサービスがLN Addressに対応しており、ユーザーはメールアドレスのような文字列を入力して送金できるようになっています。
また、可読性は犠牲になってしまいますが、LNURLサーバーを運用せずに同じような機能が実現できるBOLT12という機能が各ライトニングノード実装に徐々に導入されています。
BOLT12の登場がついにライトニングネットワークにサブスクをもたらすのか
ライトニング決済は数年前と比べ安定性も大幅に改善しており、普通の支払いや送金が失敗するなどのトラブルはかなり減ったように思います。ところがインターネット上での支払いの少なくない割合を占める「サブスクリプションの支払い」にライトニングを使う例は全くと良いほど出てきていません。ライトニングの仕組みとの親和性が低いためです。 これに対してBOLT12とセットで提案されたRecurring Paymentsという規格がライトニングにサブスクリプションをもたらす!と数年前に話題になりました。今日はBOLT12のLndへの導入が年末~来年頃に見込まれる中、ついにライトニングがサブスクリプションの支払いに使われるようになるのか?という疑問を掘り下げていきます。 ・ライトニングでサブスク決済が難しかった理由は「毎回手動で支払う必要があるから」 ・BOLT12には当初はRecurring Payments (繰り返しの支払い)という仕様が含まれていた。これはウォレットが定期的に特定の金額のインボイスを自動的に取得して支払うというものであった。 ・Recurring PaymentsはBOLT12
もはやオンチェーン送金よりもユーザーフレンドリーになったライトニング送金ですが、オンチェーン送金にもLN Addressのような可読性の高い送金先指定方法は実現できないのでしょうか?
以前紹介したBIP353というDNSを使った仕組みがありました。当時はBOLT12による送金を前提に考えていましたが、ビットコインアドレスやSilent Paymentsアドレスを設定することでオンチェーンの送金にも利用できます。
BOLT12でLightning Addressのような機能をよりシンプルに実現するための提案BIP-353
ライトニングでは原則的に送金を受け取る側が先に一度限りしか使えないインボイスを発行して送金者に送る必要があり、これがユーザー体験を複雑にしていると言われがちです。そこでLNURL-payという仕組みができ、ウェブサーバーを立ち上げて特定のパスへのアクセスをさばくことで「オンデマンドでインボイスを発行できる」ようになりました。 LNURL自体も人間には読めない長い文字列であったため、LNURLへと「変換」できるLightning Addressというものが生まれました。メールアドレスのようにuser@domain.comという形式のLightning Addressに対して支払いたいユーザーのウォレットは、domain.com/.well-known/lnurlp/userというURLにインボイスを取得しに行きます。 詳細は下記の記事からどうぞ。 Lightning Addressと乱立するインボイス請求方法ライトニングネットワークを用いたペイメントにはインボイスという1回1回の支払いごとに異なる情報が用いられます。そのため、非推奨ながらも固定のアドレスを使い回せるオンチェーンの送
今日はこの規格に再び興味が出てきたので、ハードウェアウォレットにおける対応などについて前回の話を発展させてみたいと思います。
・DNSSECを使ったBIP353の仕組みとHWW
・ハードウェアウォレットの対応には時間がかかりそう
・アドレス再利用がデファクトになってしまっている取引所宛の送金などに有効