铭文圈偶尔会出现这样的场景：有人声称某批早期铭文地址属于他，或者一个长期沉默的地址持有者想露面认领权益。此时常用的自证工具不是交易，而是一条签过名的消息：用那个地址的私钥对一段文本做签名，任何人不需要你的任何配合，就能验证“这段文本确实由该地址对应的密钥签署”。本文讲清它的数学机制、操作路径与不能越过的红线。
机制上，比特币的地址背后是一把椭圆曲线密钥对。signmessage 是钱包类 RPC 提供的接口（也内建在许多钱包的开发者工具里）：你指定一个自己的接收地址和一段任意文本，钱包用该地址对应的私钥生成一个签名串；对方（或你自己换一台机器）调用 verifymessage，输入地址、原文和签名串，验证程序会从签名反推签名公钥、再对照该地址的哈希。三个输入中任何一处被改过一个字符，验证就失败。整个流程没有交易、没有手续费、不上链——验证结果只取决于数学，不取决于任何平台。
为什么它适合“证明地址归我”这个场景？因为地址本身是公开的，任何人都能看出某个 UTXO 或某条铭文登记在哪个脚本之下，但公开地址不回答“谁控制它”。签名消息恰好补上这一问：只有私钥持有者能产出通过 verifymessage 的签名，而产出的又只是签名而非私钥本身。正确使用时它不会泄露私钥，也不构成任何付款授权——签的是文本，不是交易结构，这一区别下面还会强调。
常见的使用姿势与对应的安全注意，按场景列一遍。项目方登记老资产持有者：公告一个随机挑战文本（比如“CLAIM-2026-项目名-当日日期”），要求申请者在工单里附上地址与该地址对该文本的签名，由任何人可复核的方式归档。这里的要点是文本必须随机且一次性：拿一段早已存在的公开文本签名等于没签，任何人都能用旧签名冒充。核对方的要点是不接受“截图为证”，坚持用 verifymessage 在本地重验一遍——验证成本几乎为零，代验等于零成本钓鱼。第二种场景：个人存档，给自己的核心地址签一条带时间戳的声明（“此地址自 202X 年由本人持有”），日后被盗或纠纷时，早于事件时间的签名链是有力凭据；前提是签名文件自己保管得住，且别把签名发布到与地址无关的公开处，避免被复用到别的语境。第三种场景：市场或社区的客服核验，遇到要求你签消息“以确认身份”的私信，先看清文本内容——只包含身份声明与挑战值的才与场景匹配，文本里出现金额、地址列表、任何像“授权”“approve”字样的，一律当钓鱼处理。
与相似工具的边界要说清。签消息与 EIP-712 那种结构化签名不同：比特币的 signmessage 不绑定任何交易语义，签完不会产生“花费授权”——这正是它安全的原因，也是它无能在链上做任何事的原因。另一些链上有“消息签名上链验证”的需求，那是另一套机制（把签名写进交易供合约验证），与这里的链下自证不同源。还有：压缩格式、旧版地址类型在不同工具间的验签兼容性有历史坑，给跨工具场景的建议是同一套输入用两个独立实现各验一次，两票都过才采信。
一句话收束：签消息是“最低成本的身份回声”——不动资产、不花手续费、不留链上痕迹，却能给出数学级别的归属回答。用它自证时保证文本新鲜，用它核验时保证亲自验，红线则永远只有一条：任何试图让你把签名和资金操作混在同一次授权里的流程，直接拒绝。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。