把收款条件挂在网上：BOLT 12 offer 的字段与 lno 编码

一、发票的过期困境

经典闪电发票（BOLT 11 的 lnbc 字符串）是一次性凭证：金额、时间戳、支付哈希都焊死在编码里，还默认挂着过期时间。想把收款码印在海报、网站或点餐屏上，要么不设过期、背上”这张码永远有效”的语义负担，要么定期换码、换物料、换掉所有已印出去的载体。BOLT 12 把职责拆开：收款方发布一个静态对象叫 offer，编码以 lno 前缀开头；付款方临付前，拿 offer 里的信息向收款节点在线索取一张一次性的 invoice，确认金额与附加说明后才发起支付。静态码与动态单据分离，收款二维码终于可以贴上墙。

二、offer 的字段表

offer 本质是一张 TLV 字段清单。必带的是收款方的身份公钥——可以是专设的收款密钥，不必暴露节点的网络身份；可选项包括固定金额 amount、币种、文字描述、整体过期时间 expiry、备注元数据，以及一组”介绍节点”信息：路由入口的地址或洋葱服务地址、对应密钥与跳过数量，供付款方在收款节点不便公开时仍能找到进门的路。不写金额，付款人临场自定；写了金额，这张码就是一张固定账单。字段全部公开可读——这正是无需在线协商就能展示 offer 的前提，也是隐私上要想清楚的点：贴出去的码会暴露收款方密钥标识与金额设定习惯，描述文本也会原样进任何扫描者的解析器。

三、编码的物理账与落地差异

lno 字符串沿用 bech32m 编码：每个字符只装五个比特，数据段翻着倍地变长，末尾再缀校验位。字段一多，字符串长度迅速膨胀——这是”一张 offer 能塞多少信息”的真实边界：描述文本、介绍节点、元数据都按字符计价。工程上的对策是把可变信息留在交互阶段（invoice 里谈），静态 offer 只放骨架；打印场景则表现为二维码从低密度一格变成需要更大尺寸的高密度版本，扫码距离与光照容差同步收紧。落地还要看实现：各家实现从”能解析”到”默认开启”的节奏不一，跨实现付款遇到 lno 串不被识别时，先核对对方软件版本，别怀疑码做错了。规范仍在演进，字段编号与推荐实践可能更新，动手前以当前版 BOLT 12 文本为准。

四、从 lnbc 到 lno 的收钱一步

对用户视角，流程差异其实只有一处：扫 lno 码之后，钱包软件先替你和收款节点打一轮协商——带上你想付的金额与截止时间发起请求，收款节点据此生成当次 invoice 回签，然后才进入熟悉的路由付款。中间多出的这一轮 HTTP 或 onion 消息交换，把旧发票”编码即承诺”的脆弱性换成了一次在线确认：金额可浮动可固定、描述可追加，收款方甚至可以对明显异常的请求直接拒绝。代价是纯离线展示场景不再万能——收款节点完全失联时，lno 码只能算一张名片。因此部署静态码时把可用性想在前面：介绍节点字段配好几个入口，别让唯一入口是你的家用宽带；同时收款密钥定期轮换，旧码的处置方式提前写进运维记录，免得三年后没人说得清那面墙上的码归谁。

本文内容仅供信息与教育参考，不构成投资建议、法律或税务意见，也不构成对任何产品或服务的推荐。比特币与闪电网络操作不可逆，涉及资产操作前请自行核实关键参数并评估风险。