闪电网络发票字段有哪些？BOLT11 的付款哈希与路由提示逐个看

收到一张以 lnbc 开头的闪电网络发票，很多人只看金额和二维码，实际上这串字符内部是一份结构化的合同：付款哈希、路由提示、过期时间、链上兜底地址各管一段安全语义。BOLT11 是闪电网络规范里定义发票格式的文档，这篇按它的字段清单逐个讲清“谁防什么”，并说明哪些字段缺失时会落到什么默认值。

发票字符串的骨架

按 BOLT11 的定义，一张发票依次包含：ln 前缀、网络标识（主网为空，测试网有对应字母）、可选的金额段（用倍率字符表达，单位为毫比特币）、31 位时间戳、一串带标签字段，最后是一段签名。签名不写死收款节点身份，而是让付款方从签名中反推收款方节点公钥——这样节点公钥轮换后旧签名仍可验证，发票不会因为密钥轮换而作废。金额可以省略，规范建议此时向付款方明确提示“金额未指定”，由付款方自己填数。

标签字段清单：每个防什么

规范当前定义的字段里，p 是 256 位付款哈希，其原像（preimage）就是付款凭证本身，全链路最后一跳交出原像才拿得到钱，这是闪电网络“以秘密换支付”的核心；s 是 256 位 payment_secret，它的作用是让中转节点难以探测谁是真正的收款方，没有这个秘密，中间人更难拼凑网络拓扑，规范同时要求发票必须包含恰好一个 p 与一个 s。d 字段是一段 UTF-8 短描述，例如一杯咖啡；如果描述内容超过单个字段上限，规范改用 h 字段存放描述的 SHA256 承诺，完整文本走发票之外的传输通道，这样隐私敏感的描述不会全部暴露在链下字符串里。

时间与锁定参数：x 与 c

x 字段是发票有效期（秒），缺省时规范取 3600，即一小时后这张发票不再接受支付；c 字段是最后一跳要求的最小 CLTV 锁定增量，缺省值为 18。两者共同决定付款方构造路径时的时限参数：过期太短的发票对网络延迟和重试极不友好，锁定增量太小时最后一跳的争议窗口不足。路由场景参数 cltv_expiry_delta 与它相关但作用层级不同，前者是全网逐跳累计，后者只约束发票终点这一段。

r 路由提示与 f 链上兜底

r 字段是给私道路由用的提示，一条 r 里打包了节点公钥、短通道 ID、基础费、百万分比费和 CLTV 增量五个值，可以出现多条，帮付款方在收款方通道不公开时也能找到路。f 字段是链上兜底地址：若闪电支付始终走不通，付款方可退化为普通比特币链上支付。规范同时提醒，兜底地址可能把收款身份与链上地址关联起来，隐私敏感的收款方应当谨慎使用。每个标签字段的数据长度有上限（单个字段最多 639 字节），过长的元数据会挤占路由载荷空间、缩短可达路径长度。

时间戳与金额倍率：字符串里还藏着两件事

发票骨架里的 31 位时间戳是自 Unix 纪元起的秒数，配合 x 字段构成完整的时效判断：钱包解析时要实时比较，过期发票直接拒付最稳妥。金额段的倍率字符（如毫、微）也容易被读错——同一个数字换个倍率就是三个数量级的差距，扫描后核对金额与币种单位应当成为付款前的肌肉记忆。金额缺省的发票把定价权交给付款方，规范建议收款方在展示时明确写出这一点，避免双方对“默认值”各有想象。

核对清单与风险提示

付款前值得核对四点：金额与倍率字符是否与预期一致；x 是否已过期；p 哈希是否与你拿到的付款凭证承诺匹配；f 地址如果存在，格式是否落在你预期的地址类型里。需要澄清的边界是：发票字段只保证“付给谁、以什么条件付”，通道自身的余额管理与对手方信誉不在发票语义内。闪电节点与通道资金涉及私钥保管与软件缺陷风险，任何支付失败都不应与资产交易收益混为一谈；本文只做协议机制说明，不构成投资建议。