验证比特币消息签名，需要同时核对三项内容：地址、原始消息、签名文本。只要其中任何一项出现偏差，验证就会失败。最容易被忽略的是签名格式——不同钱包生成的签名可能采用不同的编码标准，而验证工具通常只支持其中一种。
先看清签名格式：65 字节还是 DER
比特币消息签名最常见的格式是 65 字节紧凑签名，这是 Bitcoin Core 的 verifymessage 命令所要求的格式。它由三部分组成：1 字节头部（header）、32 字节的 r 值、32 字节的 s 值，整体经过 Base64 编码后呈现为一串字符。
另一种格式是 DER 编码签名，长度通常为 70–72 字节，以十六进制字符串形式出现。这种格式在交易签名中很常见，但不能直接用于 Bitcoin Core 的消息验证。如果用 DER 签名去调用 verifymessage，命令会返回失败，原因不是签名无效，而是格式不匹配。
签名头部字节决定了地址类型。根据 Bitcoin Wiki 的定义：27–30 对应未压缩的 P2PKH 地址，31–34 对应压缩的 P2PKH 地址，35–38 对应 P2WPKH-P2SH（兼容 SegWit）地址，39–42 对应原生 P2WPKH 地址，43–46 对应 Taproot（P2TR）地址。
如果你拿到的签名 Base64 解码后不是 65 字节，或者头部字节不在上述范围内，它很可能不是标准的 Bitcoin Core 兼容格式。
验证的三种路径
路径一：用 Bitcoin Core 命令行
这是最权威的验证方式。verifymessage 命令接受三个参数：地址、签名、消息。
bitcoin-cli verifymessage "你的地址" "Base64签名" "原始消息"
返回 true 表示验证通过，false 表示不通过。需要注意的是，verifymessage 对消息的处理是逐字节精确匹配的。消息中的空格、换行、标点符号、大小写，必须与签名时完全一致。一个多余的空格就会导致验证失败。
路径二：用在线验证工具
有一些零依赖的浏览器端验证工具可用，比如 verify-bitcoin-message 这个 npm 包提供了网页版本，可以直接在浏览器中离线运行验证。这类工具的好处是不需要安装节点，适合快速核对。
使用时的关键是准确填写三要素。以 Bitpie 钱包的验证流程为例：地址栏填写当初用于签名的那个地址，原消息栏填写签名时的完整原文，签名栏粘贴 Base64 签名文本。点击验证后，工具会显示"验证通过"或失败提示。
路径三：用钱包自带的验证功能
Trezor Suite、Electrum 等桌面钱包内置了消息签名和验证功能。在 Trezor Suite 中，选择对应账户后找到"签名和验证"选项，输入消息和地址即可完成验证，硬件设备会显示消息开头供你核对。这种方式适合你本来就是用同一钱包签名的场景，工具链一致，出错概率更低。
验证失败的常见原因
消息文本不匹配。 这是最常见的问题。签名时如果消息包含换行，验证时也必须保留换行。如果消息是从聊天记录或网页复制来的，可能夹带了不可见字符（如零宽空格）。建议直接使用签名时保存的原始文本，不要重新输入。
地址类型与签名头部不匹配。 比如你用的是原生 SegWit 地址（bc1q 开头），但签名头字节对应的是 Legacy 地址类型，验证就会失败。这种情况通常发生在钱包软件对地址类型的判断有误，或者你手动修改了地址格式。
签名经过了二次编码或截断。 Base64 签名中如果包含换行符，某些工具可能无法正确解析。确保签名文本是完整的一行，没有额外的空格或换行。
用了 BIP-322 格式的签名去 Legacy 工具验证。 BIP-322 是较新的签名标准，支持更复杂的地址类型（包括多签和 Taproot），但它生成的签名格式与传统的 65 字节紧凑签名不同。如果你用 BIP-322 兼容的钱包签名，需要用支持该标准的工具来验证。
一个实际案例：Genesis 区块签名的格式问题
有一个经常被引用的案例可以说明格式问题有多关键。有人提供了一段据称是中本聪对 Genesis 区块消息的签名，Base64 字符串看起来很正常。但解码后发现，它是 70 字节的 DER 签名，而不是 65 字节的紧凑签名。用 bitcoin-cli verifymessage 去验证，命令会直接拒绝，因为该命令只接受 65 字节格式。
这个案例的教训是：签名"看起来对"不等于格式正确。在验证之前，先确认签名长度。Base64 解码后是 65 字节，才适合用 Bitcoin Core 的标准命令验证。
证明的边界：消息签名能证明什么，不能证明什么
消息签名能证明的是：签名者控制着某个地址对应的私钥。验证通过意味着，持有该地址私钥的人确实对那段消息内容做了签名。
它不能证明的包括：签名者"拥有"地址中的资产（他可能只是曾经控制过，或者私钥已经泄露给他人）；消息内容本身是真实的（签名只证明"谁说了这句话"，不证明"这句话是否属实"）；签名时间（除非消息文本中包含了时间信息，且该时间被签名覆盖）。
一个常见的误解是"签名消息可以证明资金所有权"。实际上，证明资金所有权需要另一套机制（比如 BIP-322 的 Proof of Funds 扩展，或者链上交易）。单纯的消息签名只完成一件事：将一段文本与一个地址的私钥控制权绑定。
参考资料
- Zenodo·BLACK PAPER 2048 SATOSHI DEFEATS RSA BEDFORD NAKAMOTO MURRAY RSA RETROFUNCTION，页面未标明更新日期；核查日期：2026-10-08。
- Zenodo·CLAUDE BLACK PAPER 2048 SATOSHI DEFEATS RSA BEDFORD NAKAMOTO MURRAY RSA RETROFUNCTION，页面未标明更新日期；核查日期：2026-10-08。
- Bitcoin Wiki·Message signing，页面发布或更新日期：2022-08-05；核查日期：2026-10-08。
- Bitcoin Developer Documentation·verifymessage，页面未标明更新日期；核查日期：2026-10-08。
- NPM·verify-bitcoin-message，页面发布或更新日期：2025-09-26；核查日期：2026-10-08。
- Bitpie·如何进行消息签名，页面发布或更新日期：2025-04-23；核查日期：2026-10-08。
- Kraken·在私人加密钱包上签署消息，页面发布或更新日期：2025-03-31；核查日期：2026-10-08。
- GitHub·bitcoin-bips-book，页面未标明更新日期；核查日期：2026-10-08。
