从”验证所有权”到”验证控制力”
在交易所提币页面粘贴一个地址，或在论坛签名里贴一串字符，这些动作背后隐含的声明只是”我会用这把私钥”。验证身份这件事后来分化成两条路线：一条把签名结果放进链上交易，用脚本规则证明私钥在某个时刻活着；另一条不碰链，把地址和消息签成一个可独立校验的字符串。前者昂贵、时间戳强；后者免费、即发即用，弱点是链下时间戳弱。
老格式为什么麻烦
2010 年代通行的签名消息格式（比特币核心 signmessage/verifymessage 那一套）要证明”地址持有者签了这句话”，因为老地址只是公钥的哈希、链上未必暴露过公钥，签名包就得把恢复用的公钥塞进去，还要处理压缩格式与地址回填的边角。格式里还有一个以比特币主网消息开头做前缀、带变长长度编码的消息包装。能用，但校验实现各写各的，跨工具兼容靠运气——这是 BIP-322（Generic Signed Message Format）出现的原因。BIP-322 的状态是 Complete：它规定三种格式——legacy（与核心旧命令兼容的编码）、simple（针对单公钥类地址的小消息方案）和 full（把”消息哈希写进一次性输出、再构造一笔只花它的小交易”作为签名载体的完整方案，P2TR 也覆盖）。full 格式在校验时强制要求所有签名使用 SIGHASH_ALL（对支持 SIGHASH_DEFAULT 的输出类型可替换使用），并禁用 CODESEPARATOR、要求低 S 值与最小数据等清洁性规则。校验端只要拿到地址或脚本、消息和签名字节，就能在无链访问的情况下本地复算。
签名证明的是哪一层
无论哪种格式，被签的都不是”一句自由发挥的话”，而是按规范把消息装进一个一次性脚本/摘要容器后的哈希。这一层设计的意义是把”身份声明”限制在无法被改头换面的消息边界内：换掉消息里一个字节，签名即废；把这段签名搬去另一条消息，同样失效。反过来它也保护不了你——签名证明控制力，不证明动机。一个被钓鱼站点骗签的消息，和你自愿签的公告，在字节层面完全同权。这条边界对所有”登录式签名""链下授权签名”同样适用。
链上锚定那条线
另一条路线不签发字符串，而是让地址在某个区块里花一笔极小的交易：输出脚本可以锁成”只有这把密钥在区块高度 X 之后动过”，任何看到这条链上动作的人都能把声明钉到区块时间上。缺点是花钱、等确认，而且暴露地址的活动性。实践中常见的折中是混合方案：先在链下签 BIP-322 消息公布承诺，再在下一笔正常花费里顺带把承诺哈希写进 OP_RETURN——这条路线要单独确认你的钱包不会因此被聚类。
使用清单
给需要”证明这个地址归我”的读者：优先选支持 BIP-322 的钱包或工具，签名时把消息原文逐字核对，绝不对”看不懂的编码”签字；对方校验时要求对方同时给出版式（legacy、simple、full）与所用哈希规则，跨工具校验失败先比对这两项，再怀疑密钥。给搭建登录/认证系统的开发读者：签名里要带会话一次性随机数与有效期，防止一段签名被无限重放；服务器把签名字节当”验证过的凭证”存档时要意识到它和私钥不在同一威胁面，泄了签名字节不会泄露私钥，但会泄露登录能力。所有样例地址不指向真实资产。本文只做机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。