BOLT 12

收款方发布 offer，付款方发送 invoice_request 并获得新的 invoice，然后才可支付。报价可供多人或多次付款使用。通过 fetchinvoice 等方式取得账单不代表已经付款；公开二维码也不是长期扣款授权。 [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice] [BOLT 12 — Project overview]

BOLT 12 用 TLV 存储字段。文本报价使用 lno 前缀，请求使用 lnr；字符集类似 Bech32，但没有末尾校验和。Offer 本身不带签名。请求和账单中的 BIP340 Schnorr 签名验证相应字段的 Merkle 根，而非商家的真实身份。 [BOLT 12 — Negotiation protocol]

钱包比对 invoice_request 复制到 invoice 的字段、金额、链及签名。invoice_node_id 必须匹配 offer_issuer_id 或相应的终点 blinded_node_id。无关密钥的有效签名并不足够。Merkle 结构允许选择性证明字段，并不允许任意修改签名条件。 [BOLT 12 — Negotiation protocol]

比特币 invoice_amount 以 msat 计，1000 msat 等于一个 satoshi。Offer 可通过 offer_currency 使用 ISO 4217 规定的其他货币，例如 USD 以美分计。数量和开票时的换算会影响价格。指定 invreq_amount 时账单必须一致，否则应核实金额在授权范围内。 [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice]

offer_paths 传递请求消息，invoice_paths 承载支付。当前 invoice 必须有 blinded paths 和对应的 invoice_blindedpay，即使路径直接通向收款方。盲化可减少拓扑暴露，但不保证完全匿名、可用性或流动性。请求账单不需要常规 HTTPS 支付服务器。 [BOLT 12 — Negotiation protocol] [BOLT 4 — Route blinding]

offer_absolute_expiry 限制报价的使用。invoice_created_at 与 invoice_relative_expiry 限制具体账单，省略后者时为 7200 秒。因此，可重复使用的报价并不使账单永久有效。未知的偶数必需功能位会被拒绝，未知奇数位则忽略。 [BOLT 12 — Negotiation protocol]

退款时，希望付款的一方可以发布不带 offer 的 invoice_request。收钱的一方返回自己的 invoice，付款方必须核实预期收款人，必要时在协议之外确认。这是一笔新支付，不是撤销原支付。仅扫描请求既不能证明收款权，也不等于批准付款。 [BOLT 12 — Negotiation protocol]

保存 invoice、支付状态及对应 preimage。Preimage 证明账单已结算，但本身不能确定是哪一个人付款。丢失回复后，先查状态再付款。支持报价不代表支持每种扩展或自动周期扣款；应分别核实收款、付款及应用授权。 [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice]