Lightning Address

アンナは自分のポッドキャストへの支援を受け取りたいと考えています。リスナーごとに新しい長いインボイスを送る代わりに、Lightning Address を公開します。例として挙げる anna@example.com は覚えやすく、@ の前はサービス内の受取人、後ろはウォレットに応答するドメインを示します。メールに似せた形ですが、お金をメールで送るわけではありません。既存のメールアドレスが自動的に Lightning Address になることも、名前だけで持ち主の身元が分かることもありません。支援したい本人が公開したアドレスか確認しましょう。 [1] [6]

リスナーが対応ウォレットに名前を入力すると、ウォレットはサービスから支払いの説明と許容金額の範囲を取得します。利用者がドメイン、説明、選んだ金額を確認した後、具体的な BOLT 11 インボイスを要求し、その金額を確認してから支払います。インボイスの取得は支払い完了ではありません。この流れを LNURL-pay と呼びます。サービスはインボイス要求先の callback、説明を含む metadata、下限の minSendable と上限の maxSendable を返します。amount は satoshi の千分の一に当たる msat 単位です。1000 msat = 1 sat となり、インボイスは pr フィールドに入って返されます。 [2] [3]

アンナはウォレットを管理してくれるサービスを使うことも、自分の支払いを処理するソフトウェアである Lightning ノードに名前を接続することもできます。アドレスの見た目では区別できません。サーバーがウォレットに応答する場所を web endpoint といい、橋渡しをするサーバー経由でノードにインボイスを要求する場合もあります。仲介者が資金を預かるとは限らず、構成や与えた権限によります。ただし応答を差し替えられる人は、支払う人に別のインボイスを提示できます。自分のドメインを持つだけでは、鍵を自分で管理する self-custody は保証されません。 [3] [4]

ウォレットは Lightning Address への送金に対応していても、利用者に受取用の名前を提供するとは限りません。受け取りには、利用可能なウェブサービス、インボイスの発行、Lightning Network で実際に支払いを受ける条件が必要です。支払いはチャネルを通って届きます。チャネルとは参加者どうしの接続で、支払いによって両側の資金配分が変わります。その一つが Inbound Liquidity で、チャネルの相手側にあり、支払い時に受取人へ移せる資金を指します。覚えやすい名前がこの受取余力を生むわけではありません。アドレスは読み込めても支払えないとき、原因は名前とは限りません。ウェブの応答、インボイスの取得、実際の着金を分けて考えましょう。 [3] [5]

自分のドメインなら、リスナーに知らせた名前を保ったまま、支払いを処理するサーバーを変更できます。BTCPay の文書には HTTP 301 で endpoint を転送する例があります。ウェブの要求先が変わるだけで、コインは移動しません。他者のドメイン上の名前では、この管理権限がない場合があります。Seed Phrase はウォレットの復元用の単語ですが、それだけでサービスのアカウントへのアクセスを復元できるとは限りません。ドメインの管理権限や、接続先を決める DNS の設定を保存するものでもありません。変更後は、アドレスが開くだけでなく、正しいインボイスと試験的な支払いの着金も確認します。以前の連絡相手に新しい名前が自動で伝わることもありません。 [5] [3]

LUD-16 は名前を GET というデータ取得用のウェブ要求に変換する手順を定めます。ウォレットはドメインの /.well-known/lnurlp/username にアクセスし、username をユーザー名に置き換えます。通常のウェブでは HTTPS、onion ドメインでは HTTP を使い、payRequest 応答を受けた後は LUD-06 に従います。HTTPS は通信途中の改ざんを防ぎますが、サービス自体の誠実さを証明するものではありません。サービスは問い合わせを処理し、誰のためにインボイスを発行するか把握します。読みやすい名前だけで匿名性が加わるわけではありません。 [1] [2]

LUD-16 がユーザー名に認めるのは小文字 a-z、数字 0-9、記号 -_. です。通常のメールアドレスはこれより広い文字を使えます。任意機能の省略形 @domain は、パス /.well-known/lnurlp/_ にある既定の受取人 _@domain を表しますが、ウォレットやサービスは対応していなくても構いません。+tag の追加も共通機能ではありません。対応サービスは寄付の用途などを区別し、text/tag に含められます。新しい秘密鍵でも、プライバシーの保証でもありません。普段は受取人が公開した正確な名前を使うのが確実です。 [1]

メタデータは、ウォレットとサービスが構造化形式 JSON でやり取りする補足情報です。LNURL-pay では、短い支払い説明の text/plain が含まれます。LUD-16 は名前との対応を示す text/identifier を加え、その名前が実際のメールアドレスなら text/email を使います。ウォレットはこれを使って支払いの対象を表示できます。ただしサービスが提供する情報であり、アンナの実社会での本人確認を独立して行うものではありません。最初に入手したアドレス、ドメイン、金額を確認することは引き続き大切です。 [1] [2]