LNURL

设想安娜先扫描一个二维码支持创作者，再扫描另一个兑换代金券，最后扫描第三个登录网站。她操作手机的动作差不多，批准的事情却各不相同。LNURL 用 payRequest 表示付款，用 withdrawRequest 表示提现，用 login 表示登录。各项流程写在称为 LUD 的文档中。这些是应用之间可选择采用的协作约定，并不是对 Bitcoin 规则的修改。钱包支持其中一项，并不意味着其他项目也都支持。 [1] [7]

在 payRequest 流程中，服务会返回说明和允许的金额范围。安娜先核对域名，也就是服务的网址，阅读说明，再选择支持金额。接受条件后，钱包才索取一张具体的 BOLT 11 Lightning 发票，并在付款前核对金额是否与选择一致。背后使用的是 callback 地址、minSendable 和 maxSendable 限额，以及 metadata 说明；选定金额以 amount 传递，发票在 pr 字段中返回。金额单位是 msat，即 satoshi 的千分之一：1000 msat = 1 sat。其他人也可以使用同一个公开二维码，但扫码不等于付款成功。 [3]

在 withdrawRequest 中，资金方向正好相反。安娜想从服务提取余额，而不是向它付款。因此，她的钱包生成一张收款发票，由服务来支付。服务提供 k1 标识、callback 地址，以及以 msat 表示的 minWithdrawable 和 maxWithdrawable 限额；用户同意后，钱包通过 pr 提交发票。OK 只表示服务接受了请求，不表示安娜已经收到钱，钱包仍需等待实际入账。提现码可能像一张谁持有谁能兑换的凭券，因此不要像普通收款联系方式那样公开它。 [4]

在另一个网站上，安娜选择 LNURL-auth。钱包显示域名，以及带有 tag login 的请求用途。经她同意，钱包用该域名专属的私钥 linkingPrivKey 对一次性验证请求 k1 签名。它向服务发送签名和对应的公钥 linkingKey，服务可用公钥验证签名，但拿不到私钥。服务由此能够识别再次访问的密钥持有人，仅凭这项验证却不能确定其现实身份。钱包不会把 seed（用于派生密钥的初始秘密值）或 Seed Phrase（恢复词）发送给服务。技术上使用的是 secp256k1 曲线上的 ECDSA 签名。action 字段可能表示注册、登录、关联账户或其他授权，所以应当读完确认内容。签署这个挑战本身不是一笔 Bitcoin 付款。 [5]

请求、服务回复和资金实际转移，是不同的步骤。如果安娜断网，她应该先在钱包中查看原来的付款。使用新发票再次尝试，可能造成又一笔付款。可选的 LUD-21 提供 verify 地址，用来查询特定发票：settled true 表示服务报告已经结算，settled false 表示尚未结算。只有 OK 并不够。回复还可能包含 preimage，即与付款关联的原始秘密值。钱包根据它计算哈希，也就是用于核对的校验值，再与正确发票中的支付哈希比较。因此，收到任意一个秘密值并不够：它必须对应这笔付款。查询结果也无法保证服务可用，或保证入站流动性——让资金能够经路由进入收款钱包的容量。 [6] [3] [4]

HTTPS 保护钱包与服务之间的传输，但不会向服务本身隐藏请求。服务可能观察请求、发生时间及重复使用情况。登录还取决于完整域名：更换子域名可能生成不同的 linkingKey，让网站把同一个人当成另一个用户。换用其他钱包，也未必能恢复相同的登录身份，因为不同应用的密钥派生方法可能不同。因此，在重要变更之前，应先确认如何恢复那个具体账户的访问权限。LNURL 本身不规定由谁持有 bitcoin 的密钥；这取决于钱包和服务。 [2] [5]

基础 LUD-01 使用 Bech32 表示一个 HTTPS 或 onion URL。这是编码，不是把地址加密，也不是一张 BOLT 11 发票。钱包可以直接从链接读取 tag；否则先发送 GET 网络请求获取数据，再从 JSON 回复中判断操作类型。JSON 为数据提供名称与结构，方便应用读取。因此，二维码图片本身不能确认收款人的身份。真正需要关注的是链接内容，以及随后显示的域名、操作和条件。 [2]

在付款流程中，metadata 是一个包含 JSON 数组的文本字符串。其中必须有 text/plain 说明，其他类型则是可选的。钱包应将说明、域名和金额一起展示，让用户知道自己同意的内容。基础 LNURL 解读的是回复中的 JSON 正文，而不只是 HTTP 状态码。因此，服务器能响应不代表请求成功：回复里可能写着 ERROR。同样，在 pr 中收到发票，也不代表已经付清。应用不应把这些不同的信息都简化成一个绿色对勾。 [2] [3]