BOLT 11

安娜想买一本电子书。商店没有显示银行账户，而是提供 Lightning 发票，钱包从中读取付款信息。安娜不需要看懂整串字符，只要在确认前核对金额、用途和手续费。有些发票不规定金额，例如自愿捐助时，由付款人自行填写。没有金额并不表示支付零。想进一步了解的话，开头的 lnbc 表示主网，lntb 表示 testnet，lntbs 表示 signet，lnbcrt 表示 regtest，后三者都是测试环境。编码里的金额单位是 BTC，可带 m、u、n 或 p 倍率，并非直接使用 satoshi。使用 p 时，数字必须以 0 结尾，才能表示整数个 millisatoshi：1000 msat = 1 sat。 [1]

描述把技术请求与具体用途联系起来，例如安娜的电子书。发票要么在 d 字段中包含文本，要么在 h 中包含文本的数字指纹。这个指纹由 SHA256 计算；钱包必须核验，另行提供的描述是否能得到同一个结果。这个从文本计算得到的简短校验值，称为哈希。仅凭指纹无法读出订单内容。有效签名把描述与收款方的密钥绑定，却不保证商家真的交付电子书。对应用开发者来说，还有一条规则：描述是来自外部的文本，应当作为数据安全显示，绝不能当作代码执行。 [1]

安娜把订单留在页面上，过了一会儿才回来。钱包可能提示发票已过期，此时应重新索取一张。过期时间由创建时间 timestamp 加上有效时长 x 得出。没有 x 时，默认是 3600 秒，也就是一小时。过期不会撤销已经完成的付款。c 字段，也叫 min_final_cltv_expiry_delta，解决的是另一件事：为路径上最后一笔条件支付 HTLC 留出时间余量。HTLC 要求在期限内提供正确的秘密值，才能完成结算。这段余量按区块计，不是发票有效期的秒数；没有 c 时，付款方至少采用 18 个区块。两种时间条件不能混为一谈。 [1]

Lightning 付款通过支付通道传递。在通道内，双方不断更新资金的分配，不必把每笔普通付款都写入 Bitcoin 主区块链。成功需要可用的路径，以及通道相应一侧有足够资金，也就是流动性。r 字段可以提供 routing hints，即最后一段路径的提示。它们帮助找到收款方，却不是可用容量的实时报告，还可能暴露节点公钥、通道标识和手续费参数。因此，不要把整张发票视为私密文件。可选的 f 字段还能提供普通 Bitcoin 地址作为备用方式。向该地址付款走的是主链，有另外的手续费和确认过程，而不是同一种支付方式换了一个按钮。 [1] [2] [5]

扫描二维码或收到发票都不等于拿到了收据。发送后，应查看钱包中的结果：等待中与已完成不是同一状态。成功结算还可以用正确的 preimage 作证明，这个秘密值的哈希必须与发票中的支付哈希一致。发票和该值可以保存为付款证据，但不能保证商品已交付。如果应用断线或丢失了回复，先查原付款的状态。马上索取新发票或改付备用地址，可能导致再次付款。有些钱包会识别重复尝试，但该格式本身并没有跨应用、跨支付方式的通用防重复保护。 [2] [4]

长字符串使用 Bech32 编码。校验和帮助发现抄写错误，但它不是加密，不会隐藏内容。基于 secp256k1 的 ECDSA 数字签名负责另一件事：核验付款数据与收款方密钥的对应关系，以及数据有没有被事后修改。它不验证密钥持有人的法定身份或诚信。与 Bitcoin 的 Bech32 地址不同，BOLT 11 可以超过 90 个字符。二维码适合使用大写字母，但有效字符串不能混用大小写。人通常负责扫描或复制，这些技术检查由钱包完成。 [1]

payment hash 是秘密值 payment preimage 的数字指纹，由 SHA256 计算并存入 p 字段。成功结算时，付款方会得到 preimage，并核验指纹是否匹配。s 字段则包含 payment_secret。付款方在发票中就能读到它，并在路由付款的最后一段交给收款方，以帮助防范中间转发节点的探测。Secret 既不是 preimage，也不是钱包的 seed。因此，从二维码中读到它，既不能证明付款，也不能恢复钱包。当前 BOLT 11 要求同时具备 p 和 s。名称相似，职责却不同：识别付款、提供所需数据，以及证明结算。 [1] [2]

钱包还需要知道自己能否执行这笔付款。9 字段携带功能标志。未知的偶数位代表必需功能，遇到它必须拒绝付款；未知的奇数位是可选功能，可以忽略。已知功能之间的依赖关系也必须满足。例如 Basic MPP 会把一笔付款分成多部分，在收款方合并，只有发票提供 basic_mpp 时才能使用。分拆并不会产生多张独立发票，也不意味着每一部分都要重新支付。对新手来说，实际要点很简单：不要手动修改发票来绕过“不支持此功能”的提示，应先解决钱包兼容问题。 [1] [3]