ライトニングでは原則的に送金を受け取る側が先に一度限りしか使えないインボイスを発行して送金者に送る必要があり、これがユーザー体験を複雑にしていると言われがちです。そこでLNURL-payという仕組みができ、ウェブサーバーを立ち上げて特定のパスへのアクセスをさばくことで「オンデマンドでインボイスを発行できる」ようになりました。

LNURL自体も人間には読めない長い文字列であったため、LNURLへと「変換」できるLightning Addressというものが生まれました。メールアドレスのようにuser@domain.comという形式のLightning Addressに対して支払いたいユーザーのウォレットは、domain.com/.well-known/lnurlp/userというURLにインボイスを取得しに行きます。

詳細は下記の記事からどうぞ。

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

Lightning Address / LNURLの最大のネックはサーバーを立てる必要があること、そして自分のライトニングノードが必要なこととされてきました。このあたりを解決すべく登場したいくつかのプロダクトも本稿で取り上げています：

独自ドメインでLightning Addressを設定する方法、どれがいい？
最近ツイッター(X)に対して思うところがあり、将来的なことを見据えてNostrに力を入れることにしました。というわけで、週に１回つぶやく程度だったアカウントをちゃんと整備して、クライアントもちゃんと選んで、１日数回見ています。 きっかけは以下のポッドキャストにおけるMatt Odell氏の「XはKYCを半強制してくる」という予想でした。広告モデルとしてもユーザーデータが多いことに越したことはありませんし、スパムやボット対策にもなりますから全然ありえる話だと思います。 イーロン・マスクがトルコ政府の圧力に負けて選挙期間中に野党候補のアカウントを凍結したこと、Twitter Blue認証やスパム対策・ボット対策、そして広告ビジネスとデータ収集の相性を考えたときに、１．ツイッターがユーザーのKYCを進めるインセンティブがあること、２．そのKYC情報を元に不利益な扱いを受ける可能性が決して小さくないこと、というOdell氏の見立てが印象的でした。 さて、TwitterになくてNostrにある神機能の１つが“Zap”です。過去にも何回か触れているように、ZapとはLNURL規格を応用した投
ビットコイン研究所加藤 規新

前置きが長くなりましたが、最近BOLT12が使えるウォレットが増えてきました。例えばPhoenix Wallet、Core Lightningなどが対応しており、Lndが年末～来年にかけて対応すれば来年にも一般的な技術となるかもしれません。今日は、BOLT12の導入によってLightning Addressと同じようなことを、サーバーを立てる必要なしに実現するための方法BIP-353を解説します。

BOLT12についてはこちらをご覧ください：

BOLT12の新しいインボイス形式がライトニングをよりEコマース向けに進化
エンドユーザーでもライトニングネットワークの利用時に必ず目にするインボイス。現行の形式のかゆいところに手が届く、新しいインボイスの仕様が提案されています。今日はライトニングの新しいインボイスの仕様として提案されているBOLT12について見ていきます。 BOLTとは Basis of Lightning Technology (BOLT)とは、ライトニングネットワークの仕様を定めた仕様集です。現時点ではBOLT0～5と7～11が定められています。(6番は7番に置き換えられて欠番です)現在のインボイスの形式を定めたBOLT11の欠点を改善するものとして、今回紹介するBOLT12が提案されています。 現在のインボイスの不自由な点 BOLT11に定められている現在のインボイス形式は、送金を受け取りたい方がインボイスを発行して、送金する側がそのインボイスに従って送金し、送金が完了するとインボイスの作成に使用されたプリイメージというデータを受け取って確認できるというものです。本コラムでもおなじみですね。まず、このインボイスの形式には使っているうちにわかってきた不自由な点がいくつかあります。
ビットコイン研究所加藤 規新

・DNSの設定+サーバーの立ち上げからDNSのみへ

・プライバシーを重視するには追加の工夫が必要

・普及への障害はDNS設定の馴染みの薄さとノード運用の負担か