Lightning Address

LUD-16 使用 username 和域名，但将名称限制为小写 a-z、数字 0-9 和 -_.；只有服务支持标签时才允许加号。普通电子邮件的语法更宽泛。因此，有邮箱不保证有 Lightning Address，同名也不证明收款人的真实身份。 [Lightning Address — LUD-16] [Lightning Address — Project overview]

钱包通过 GET 请求该域名的 /.well-known/lnurlp/username 路径，使用 HTTPS，onion 服务则可用 HTTP。响应是 LUD-06 定义的 payRequest。关键是实际域名及其服务；@ 前面的部分不是节点公钥。 [Lightning Address — LUD-16]

响应提供 callback、metadata 和 minSendable/maxSendable 限额。付款人以 msat 选择 amount；1000 msat 等于一个聪。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]