节点身份签名：lncli signmessage 的 zbase32 与验证规则

闪电网络里证明”这条消息确实出自某个节点”的命令是 lncli signmessage 和 lncli verifymessage，它们用的不是比特币地址那套签名体系，而是节点身份密钥加 zbase32 编码的组合。很多运维第一次用这对命令都会困惑：明明签名格式合法，为什么验证结果说无效？答案藏在验证规则里。

一、签的是节点身份，不是资金地址 LND 节点启动时持有节点身份密钥（与通道公告、BOLT 通道签名同一把根），signmessage 就是用它对待签消息做可恢复签名。命令只接受一个消息参数，返回一个签名字符串——没有任何地址、没有任何 utxo 参与，纯粹是”我是这个节点”的声明。这与 signmessage 在比特币核心里的同名命令（对钱包地址归属签名）完全是两回事，两者格式互不兼容。

二、zbase32 是什么编码 返回的签名用 zbase32 编码——一种为口头转述设计的 Base32 变体：字母表剔除了容易混淆的字符（没有 1、i、l、o，也没有数字 0），全部小写，适合人类抄写和口耳核对。它不是新的密码学内容，只是把原本的签名字节换了一副更抗转录错误的拼写外衣。REST 接口调用时同一字段要走 base64，编码层差异在集成时要留意。

三、验证规则为什么苛刻 verifymessage 的判定不是”签名能否从消息恢复出某个公钥”这么简单。LND v0.19.0-beta 的接口说明写明：签名只有在恢复出的公钥对应公开闪电网络中的一个节点身份键时才算有效，且该节点必须存在于本机通道图的活跃节点集合里。也就是说，验证方需要先在你的图数据库里认识签名者的节点公告，才可能判真。两个常见误判由此而来：签名者是一条纯私有通道网络的节点（公告没进公开图），或者验证节点自己的图太旧、把对方标成了僵尸。签名有效但 valid 为假，先查图同步，别怀疑签名机制。

四、返回字段怎么用 验证响应有两个字段：valid 布尔值给出判定，pubkey 是从签名中恢复出的公钥十六进制串。工程上建议把两者都记录：valid=false 但 pubkey 有值时，说明密码学上签名成立、只是身份不在你的可见图里——这时可以拿这个 pubkey 去图谱查询或区块浏览器侧交叉确认，而不是直接判对方伪造。反之 pubkey 为空则多半是签名串本身损坏或编码层用错。

五、典型使用场景与边界 场景一：服务对账。托管方与交易所之间用节点签名对账单摘要做身份确认，比邮件指纹部署更轻。场景二：升级公告。节点运营者对自己发布的维护公告签名，客户端可以程序化核对来源。场景三：调试图可见性。给一条自己确信公开的通道对端节点签名并验证失败，本身就是”我的图不完整”的诊断信号。边界也要说清：节点身份密钥同时是通道网络的寻址身份，签名消息不会消耗或暴露资金密钥，但”某节点签了这句话”不等于”该节点控制某笔资金”——把节点签名当资金所有权证明是类别错误，证明资金归属应该走 BIP322 一类的地址签名规范。

六、操作细节与例外 REST 场景下消息字段要 base64 编码；签名对消息内容逐字节敏感，两端规范化换行符不一致会导致验假。多网络部署注意档案与网络参数：在 testnet 节点上验证 mainnet 公告出来的签名，图集合不同必然失败。命令本身不需要钱包解锁——它是身份层操作而非花费层操作，这也是它能在钱包锁定期间提供身份服务的原因。若节点曾轮换过身份密钥（重新安装并从种子恢复一般保持不变），旧消息的验证会锚定当前密钥，跨密钥轮次的历史签名要有单独的归档说明。

风险提示：本文所述验证规则以 LND v0.19.0-beta 源码与官方接口定义核对为准，版本迭代可能调整判定逻辑。身份签名不构成资金所有权的证明，任何把节点签名当托管凭证的商业安排都应另行约定核验规范，本文不构成任何投资建议。