Rusty Russell

大型项目往往从不起眼的尝试开始。Blockstream 在 2026 年6月9日的回顾中提到 Russell 于 2015 年5月26日留下的首个 commit：一个用于构造通道开启消息的小工具。commit 是代码历史中记录的一次修改。早期尝试逐步发展为 Core Lightning，Russell 参与了程序、测试以及对其他开发者的指导。文章也描述了他在十一年后的离开。这并不是宣布他以后不再作出任何开源贡献，更不意味着过去的领导角色赋予他对整个网络的永久权力。 [1]

设想一家咖啡馆和一位顾客使用不同程序。付款不应该要求双方选择同一个软件供应商，他们需要共同约定消息的形式和含义。BOLT 规范就是描述 Lightning 通信的文档。Russell 主持了规范的协作制定过程，并支持互操作性，也就是不同实现能够协同工作。公开的代码仓库接受提案和意见。即使是重要贡献者，也不能独自强迫所有节点采用变更；共同规则必须落实到实际软件及其使用中。 [1] [2]

两个程序可能对同一段话作出不同理解。Russell 创建的 lnprototest 提供用 Python 编写的辅助工具，让开发者设置场景，测试程序对协议消息的反应。项目入门文档 README 区分模拟执行器与针对真实实现的运行。模拟有助于准备测试，但模拟成功不能单独证明真实节点会怎样运行。应当弄清实际运行了什么、覆盖了哪些情形。即使一组场景全部通过，也不是对所有可能缺陷的完整审计。 [3]

在 BOLT 12 中，咖啡馆可以公布可重复使用的报价，例如 QR 码。顾客的钱包据此发送 invoice_request，并取得一份专用于该笔付款的 invoice，即包含支付信息的付款请求，之后才付款。报价可以反复使用，而顾客分别取得各自的请求。这不等于把已经使用过的同一份 invoice 当成每次购买的新请求。区分报价、请求过程和最终付款请求，既方便支付，也避免混淆不同交易。 [4]

Core Lightning 清楚地区分了这两步。fetchinvoice 命令联系报价发布者并取得 invoice。changes 字段可能指出它与报价的差异，例如金额或描述发生变化。成功返回结果并不会发送资金。这就像在咖啡馆拿到账单：先确认付什么、付多少。钱包需要处理返回的条件，再单独发起支付。取得请求的步骤完成，不能当作付款本身已经完成。 [5]

pay 接口文档区分 complete、pending 和 failed，分别表示完成、等待中和失败。等待中不是付款成功。amount_msat 表示接收方收到的金额，amount_sent_msat 则是包括手续费在内的总发送金额。msat 指 millisatoshi，即 satoshi 的千分之一。因此，顾客的支出可能比咖啡馆收到的金额多一笔手续费。文档已将 pay 标为弃用接口，并说明向 xpay 过渡。这里解释的是状态和金额，而不是要求安装特定版本；应按实际使用的软件理解结果。 [6]

咖啡馆退款时，并不会倒转原来的支付。BOLT 12 也描述了反向流程：商家说明想发送的金额，顾客提供 invoice，商家检查 invoice_node_id，也就是准备付款给的节点标识，然后向顾客发起一笔新支付。这既不取消原转账，也不会自动产生退款权利。协议提供执行方式，退款原因及条件仍需参与者另外商定。 [4]

发生争议时，需要知道证明究竟能说明什么。BOLT 12 解释，preimage 是与付款请求中哈希值对应的秘密值，它可以证明一份 invoice 已经支付。但公开之后，别人也能展示这个值；仅凭它无法认定是谁付款。请求中包含的密钥可以用于证明谁申请了该 invoice，却不会自动验证这个人在现实世界中的身份。已付款的请求、对密钥的控制与顾客身份，是彼此不同的信息。 [4]