一、握手第一句话就是能力清单
两个闪电节点建立 TCP 连接后，发的第一条消息不是问余额，也不是申请通道，而是 init 消息。它的核心内容是一份能力清单：一串按位编号的功能标志，也就是 BOLT9 定义的特性位。规则很朴素——编号从 0 开始，成对分配，每一对里奇数位表示我可选支持这个功能，偶数位表示我强制要求对方也支持。收到清单的一方按自己的实现表逐位核对：认识的可选位就记下，以后可以一起用；不认识又不带强制标记的位直接忽略；一旦出现自己完全不认识的强制位，就必须断开连接，因为对方的某条通道行为可能依赖你无法正确执行的新协议。这套办法让闪电网络在没有全网统一升级日期的前提下，把两条链上代码的兼容性问题压缩成了一次按位与运算。
二、读表：几个值得眼熟的位置
BOLT9 的分配表可以当字典查，这里挑几个常见的解释。位对 0 和 1 是数据丢失保护，它后来被标记为 ASSUMED——意思是被所有实现普遍支持，新实现可以直接假设有，不必再在协商里较真。12 和 13 对应静态远程密钥，通道状态更新时对方的惩罚输出脚本可以固定不动，简化备份。22 和 23 是锚定输出承诺格式，决定了单方面关闭时手续费怎么补付。28 和 29 是双出资通道，开通道交易允许双方一起拼资金。34 和 35 对应 stfu 静默消息，用于通道维护窗口。44 和 45 是通道类型协商，46 和 47 是短通道编号别名，50 和 51 是零确认通道，62 和 63 是拼接操作。看到不认识的位不必慌：表本身随规范版本演进，新位先以可选身份出现，用的人多了才可能升级成强制位。
三、位不只出现在连接握手时
同一套位在不同上下文里有不同含义，读错上下文就会得出错误结论。init 里的位说的是两条连接上能做什么；节点公告里的位是向全网路由软件广播你公开具备哪些能力；发票里出现的位（比如支付密钥和基础多部分支付）约束的是这笔收款必须走什么协议；通道类型则是在开通道那一刻，从双方的 init 能力交集里为这条通道单独锁定一组功能位。也就是说，同一个节点完全可能有一条开了锚定输出的老通道和一条没开的新通道并存——能力是逐通道锁定的，不是全局一刀切。排查问题时先分清你看的是连接层、图谱层还是通道层的能力表，很多说不通的失败其实来自把节点公告的位当成通道实际协商结果。
四、依赖关系与实用判断
功能位之间有显式依赖：比如基础多部分支付依赖支付密钥，零确认通道依赖别名功能，规范要求必须同时设置传递依赖，只声明上层功能是违规的。对普通用户，这套机制的体感是三件事。第一，开通道被拒时，日志里常是某对特性位没谈拢，而不是钱的问题，先对照 BOLT9 表看双方版本是否代差太大。第二，别把对方公告里出现某个位理解成这笔付款一定成功——公告可以过时，实际路由还要经过通道类型和发票层的再确认。第三，想确认自己节点的姿态，看实现提供的 getinfo 或数据库里的通道类型字段，比翻源码里的常量表更可靠。最后一句保守话：特性位描述的是协议兼容性，不代表资金安全等级，功能谈得拢和惩罚机制对不对是两回事。
本文内容仅供信息与教育参考，不构成投资建议、法律或税务意见，也不构成对任何产品或服务的推荐。比特币与闪电网络操作不可逆，涉及资产操作前请自行核实关键参数并评估风险。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。