Lightning Address

LUD-16 は username とドメインを使いますが、名前は小文字 a-z、数字 0-9、-_. に制限されます。プラス記号はサービスがタグに対応する場合だけ使えます。通常のメール構文はこれより広範です。メールボックスがあっても Lightning Address があるとは限らず、同じ名前でも受取人本人の認証にはなりません。 [Lightning Address — LUD-16] [Lightning Address — Project overview]

ウォレットはドメイン上の /.well-known/lnurlp/username を GET で取得します。HTTPS を使用し、onion サービスでは HTTP を使用できます。応答は LUD-06 の payRequest です。実際のドメインとそのサービスが重要であり、アットマークの前の文字列はノードの公開鍵ではありません。 [Lightning Address — LUD-16]

応答には callback、metadata、minSendable/maxSendable の範囲が含まれます。支払人は msat 単位で amount を選び、1000 msat は 1 satoshi です。callback が pr に請求書を返し、ウォレットは支払い前に金額の一致を確認します。アドレスの照会も請求書の受信も決済完了ではありません。 [LNURL — LUD-06 payRequest] [Lightning Address — Implementation guide]

新しい LUD-16 では、_@ドメインを表す @ドメインという省略形と、/_ で終わるパスが任意で認められます。サービスもウォレットも対応は必須ではありません。対応する +tag はパスで送られ、サービスは text/tag のメタデータとして利用できます。タグは新しい Bitcoin 鍵でも自動的なプライバシー保護でもありません。 [Lightning Address — LUD-16]

LUD-16 は metadata 内に text/identifier または text/email を要求します。text/email は実際のメールアドレス用です。LNURL-pay の text/plain も引き続き必須です。表示された名前と説明をドメインおよび意図する受取人と照合してください。サービスの主張は人の身元を独立して検証するものではありません。 [Lightning Address — LUD-16] [LNURL — LUD-06 payRequest]

サービスは自らのウォレットの請求書を発行したり、ノードにつながるブリッジサーバーを利用したりできます。したがって形式だけでは第三者管理か自己管理かは決まりません。ブリッジに必要なのは機能に応じた権限であり、自動的にウォレットの無制限な操作権限が必要になるわけではありません。endpoint の管理者は支払人が受け取る請求書に影響を与えられます。 [Lightning Address — Implementation guide] [Lightning Address — Bridge server]

ウォレットはユーザー自身のアドレスを提供しなくても Lightning Address に支払えます。受取には動作するウェブサービス、請求書の発行、支払いを受け入れる能力が必要です。読みやすい名前だけでは入金側の流動性は生まれません。繰り返す照会によって受取先や時刻が提供者に伝わることがあります。 [Lightning Address — Implementation guide]

自分のドメインなら endpoint を別のサーバーへ転送できます。BTCPay は例として HTTP 301 を説明しています。他者のドメインで名前を維持できるかは提供者に依存します。シードは DNS の管理権限、証明書、アカウントの対応付けを復元しません。サービス変更後は照会、宛先の請求書、受取を改めて確認し、古い連絡先が自動更新されると考えないでください。 [BTCPay Server — Address redirection] [Lightning Address — Implementation guide]