私钥 → P2PKH 非压缩地址

本页计算了什么

输入与压缩版页面相同的私钥，但哈希的是 65 字节非压缩公钥 04 ‖ X ‖ Y。地址公式完全一样 —— 变的只是送入哈希的字节：

这两个地址外形相同、长度相同、版本字节相同，但绝不能互换。币只存在于某一个具体地址上， 只有用当初收款时那一串确切字节的哈希，才能认出它们。

1. 非压缩公钥：04 ‖ X ‖ Y

SEC1 标准定义了点在小曲线上的多种序列化方式。最早的那种把一切都写明白：一个 04 标志，然后 32 字节的 X 坐标，再然后 32 字节的 Y 坐标。没有任何压缩，也不需要重算 —— 验证方从数据里直接读出两个坐标。

两种形式描述的是同一条曲线上同一个点。压缩不是什么「另一把密钥」，不是另一条派生路径，更不是数学上 的「兼容模式」—— 它只是一种更短的写法，之所以可能，是因为 Y 可以从 X 加一个奇偶位完整恢复出来（推导见 压缩公钥页面）。

2. 哈希为什么不同 —— 地址为什么不同

hash160 是它所吃进的那串确切字节的函数，而不是它所代表的点的函数。65 字节输入与 33 字节输入的长度 不同、首字节不同，摘要自然完全不同。两个结果之间没有任何数学关系：它们是两个彼此独立的 160 位值。

两行都正确、都能花费、都属于同一个 256 位秘密。链上没有任何标记说明它们相关 —— 这正是它成为互操作陷阱而不是 冷知识的原因。

3. 历史时间线

非压缩不是「坏掉的遗留格式」，它是最初的格式。

4. 钱包恢复：为什么老地址上的币，新钱包看不到

这正是本页存在的理由。你恢复了助记词，或导入了私钥，钱包却显示余额为零 —— 而区块浏览器明明显示有一笔币 安安静静躺在一个 1… 地址上，你确信那属于你。问题同时出在三处：

1. 钱包只算一种序列化。 遵循 BIP44／BIP49／BIP84／BIP86 的现代钱包按约定派生压缩 公钥，哈希的是 33 字节形式，得到压缩的 hash160，然后去查 146ZNjH7…。而币在 16kR3eis… 上 —— 那个值钱包根本不会算，自然也不会向网络查询它。
2. 恢复了种子，不等于恢复了钱包。 种子确定性地产生私钥，但地址约定属于客户端软件， 不属于数学。同一个种子在 2009 年的客户端和 2024 年的客户端上，会得到两组完全不相交的地址。
3. 决定一切的是 WIF 标志，不是私钥。 当密钥以 5HssbguBnjbaUVZCsH9YuzUG7T4vYQf51iiodi4izdVy6aVNekU（前缀 5）导出时，钱包 应当按非压缩处理。如果你把它当成 K…／L… 导入，或把裸 hex 粘进一个默认压缩的 钱包，那么币会从视野中消失 —— 尽管它们一动没动。

5. 非压缩形式在链上还有效吗

有效。共识规则没有任何一条禁止它，由非压缩公钥建立的 P2PKH 输出今天依然可以花费：

• 锁定脚本只承诺一个 20 字节哈希。解释器并不关心解锁脚本里给出的公钥是 33 还是 65 字节 —— OP_HASH160 只是对它拿到的字节求哈希，OP_EQUALVERIFY 比较结果是否相等。
• 非压缩 P2PKH 的花费在中继策略下仍然是标准交易，因此会正常广播、正常被打包。
• 唯一的硬限制出现在 witness 程序内部：一个 v0 witness 花费若提交非压缩公钥，会触犯标准性 标志 SCRIPT_VERIFY_WITNESS_PUBKEYTYPE。这样的输出依然可以被构造出来（编码器会老老实实给你一个 bc1q… 或 3… 字符串），但它的花费无法通过正常中继广播 —— witness 类地址按策略 只能配压缩公钥。

6. 经济账：脚本更大，手续费更高

花掉一个非压缩 P2PKH 输出更贵，因为解锁脚本必须多带 32 个字节：完整的 Y 坐标。两个地址在收款方看来毫无 区别，差异只在币移动时才显现。

按 10 sat/vB 计算，每笔输入大约多付 320 聪；若一次清空 50 个老输入，这就是约 16 000 聪的纯开销，而且手续费 一涨，差距还会拉大。这确实是真金白银的成本，但它也是搬走那些币的唯一方式：这笔费用不是可选项、也无法 规避，因为多出来的字节正是让哈希对得上的东西。

7. 主网与测试网的版本字节

对同一个 hash160，两条链之间唯一不同的就是版本字节：上面那个非压缩 hash160 在主网得到 16kR3eiswUY6tmGnxZhwQmW6LAvTLGWG2G，在测试网得到 mmGNLhorkVyMfskQg8gKEgiRCAXAGnxeBv。版本字节也是主网地址以 1 开头的唯一原因 —— Base58 会把每个前导 0x00 写成字面字符 1。

8. 用演示私钥做的实例演算

表中每个值都由结果面板实时重算，你可以亲自确认那两个 hash160、进而两个地址，彼此毫无关系。

9. 这一步在推导链上的位置

• 姊妹页：压缩版 P2PKH 地址 —— 同一条流水线，把 65 字节换成 33 字节，也就是 现代钱包显示的地址。
• 上游：私钥 → 非压缩公钥 展示这 65 字节是怎么由点拼出来的。
• 导出格式：非压缩 WIF（5…）正是钱包为了去查这个地址、而不是压缩 地址，所需要的东西。
• 只有本页的地址与老资金有关：嵌套 SegWit 与 原生 SegWit 只支持压缩公钥，永远匹配不上老密钥的非压缩哈希。

10. 安全须知

• 两个地址都是公开信息；保密的只有私钥和两个 WIF。
• 签名之前先确认币到底在哪个地址上。不确定就先小额试转一笔。
• 不要把老私钥粘进任何「顺便帮你查余额」的网站 —— 那是最经典的钓鱼套路，而老密钥是极诱人的猎物。

11. 常见错误

• 以为一把私钥只对应一个地址。 一个标量至少给出五个可用地址（压缩 1…、非压缩 1…、3…、bc1q…、bc1p…），外加它们的测试网变体。
• 导入了错误的 WIF 形式。 5… 与 K…／L… 是同一个秘密 指向不同地址；搞混就会看到一个空钱包。
• 迷信钱包的「自动识别」。 有的客户端两种形式都扫，有的只扫一种，还有的会默默显示为零。 请拿派生出的地址去区块浏览器核对，而不是看余额。
• 以为压缩是「更新的数学」。 同一条曲线、同一个点，变的只是序列化。
• 用非压缩密钥的哈希去清空到 SegWit 地址。 收款地址应当由全新的压缩密钥构建；见上方的 危险提示。

12. 速查表