私钥 → P2PKH 压缩地址

本页计算了什么

输入一个 256 位私钥，输出一个经典的 1… 地址。地址并不是第二把密钥，也不是私钥的哈希 —— 它是 对压缩公钥的 20 字节承诺值做 Base58Check 编码的结果：

结果面板会把每一个中间值都列出来，因为本页存在的意义就是让每一步都看得见，而不是藏在黑盒里。

1. 「P2PKH」到底是什么意思

比特币的一笔输出不是一个带余额的账户，而是一个金额加一小段程序，这段程序叫锁定脚本 （scriptPubKey）。要花掉它，下一笔交易必须提供一个解锁脚本（或 witness），让这段 程序执行完在栈上留下一个 TRUE。P2PKH 是 pay to public key hash （支付给公钥哈希）的缩写，它的锁定脚本是：

OP_DUP  OP_HASH160  <20 字节公钥哈希>  OP_EQUALVERIFY  OP_CHECKSIG

顺序很关键：脚本先对花费者提供的公钥重新求哈希，与脚本里承诺的哈希比对，只有比对通过才去验证签名。 「先哈希」正是地址能够这么短、并且公钥在币移动之前不必上链的原因。

那种 Unix 风格的简写 <公钥哈希> OP_CHECKSIG 描述的是更早的 P2PK （pay to public key，直接支付给公钥）形式：它的锁定脚本里压入的是整把公钥，而不是公钥的哈希。中本聪最早的交易 用的就是它，代价是输出更大：

脚本执行的每一步

花费者的解锁脚本是 <签名> <公钥>。下面用演示私钥的真实取值，逐步展示解释器的动作：

可见哈希不是「顺手做的优化」，它就是身份校验本身。若花费者给出的公钥哈希不匹配， OP_EQUALVERIFY 会直接失败，根本轮不到签名运算。

2. 逐字节看构造过程

Base58Check 的输入恰好是 25 字节，此外什么都没有 —— 没有 chain code、没有密钥序号、更没有私钥的什么 校验值：

25 字节 = 200 位。由于 Base58 每个字符携带 log₂(58) ≈ 5.858 位信息，编码后的长度是 33 或 34 个字符 （200 / 5.858 ≈ 34.1）。演示地址正好 34 个字符。

为什么地址一定以「1」开头

Base58 本质上是「以 58 为进制的整数转换」，而纯粹的整数转换会把前导零字节抹掉。于是编码规则里额外加了 一条：输入中每一个前导的 0x00 字节，在输出开头对应一个字面字符 1。主网 P2PKH 的版本字节正好就是 0x00，所以第一个字符永远是 1。改掉版本字节，首字符随之改变 —— 这一个字节就是 1…、3…、 m… 长得不一样的全部原因。

3. 为什么是 hash160 = RIPEMD160(SHA256(x))

两个不同的哈希函数串联使用，理由是纵深防御。仅攻破 SHA-256 的碰撞性对攻击者 毫无用处，因为 32 字节摘要还要喂给第二个结构完全不同的函数：想造出两把 hash160 相同的公钥， 必须在复合函数上找到碰撞，也就是两个设计都得破。同时，哈希两次也把结果压缩到 20 字节，让每个地址、 脚本和输出都更小。

针对某个具体地址的现实威胁是「第二原像」，而不是随便找一个碰撞：攻击者必须找到一把公钥，它的 哈希等于你那 160 位的值，代价约 2¹⁶⁰。2⁸⁰ 的碰撞界只影响攻击者自己挑选的两把 密钥，因此用 20 字节换取更小的脚本被认为是划算的取舍 —— 而且直到今天它依然没有被攻破。

4. 那 4 个字节的校验和究竟防住了什么

校验和是 SHA256(SHA256(payload))[0..3]，即 32 位，编码前附在载荷后面。它的全部职责是捕获 无意的抄写错误：抄错一个字符后解码出的整数就变了，而随机损坏仍然能碰巧匹配这 32 位的概率是 2^-32 ≈ 1 / 42.9 亿。这就是为什么地址少抄一个字符时，几乎所有钱包都会大声报错。

5. 主网 vs 测试网：一个字节决定一切

对同一个 hash160，主网地址与测试网地址的唯一区别就是版本字节。同样的 20 字节，不同的首字节，完全不同的 字符串：

* 这几个测试网络共用上表里的 Base58 版本字节，只有 bech32 的可读部分不同（regtest 为 bcrt1）。对演示私钥的 hash160，主网地址是 146ZNjH7XTXnMd1ofe3z7CL2i8WM7N2UqT，测试网地址是 micWfnN6LUy38jVRPD2Mw7YMa873zjixGw —— 同一个 20 字节承诺，指向两条不同的链。

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

下面就是本页对 0824c314…171ca 实际算出的全部值，结果面板会实时重算它们：

读这段脚本：76 = OP_DUP，a9 = OP_HASH160， 14 = 「接下来压入 20 字节」，随后是哈希本身，88 = OP_EQUALVERIFY， ac = OP_CHECKSIG。五个操作码加一个常量 —— 25 个字节定义了谁有权花这笔钱。

7. 为什么地址不是公钥

• 它是单向承诺。 地址里并不存公钥，只存它的 160 位哈希。想从地址还原公钥，等于要逆转 SHA-256 与 RIPEMD-160，目前除暴力搜索外没有更好的办法。
• 只有地址无法验证签名。 ECDSA 验证必须拿到公钥，这就是花费者必须在解锁脚本里交出公钥的 原因。
• 地址不告诉你公钥是怎么序列化的。 压缩公钥和非压缩公钥生成的 1… 地址看起来 一模一样：版本字节相同、长度相同。你无法从地址判断币到底躺在压缩还是非压缩的那个变体上。
• 它当然也不是私钥。 公开地址不会泄漏任何足以花费的信息 —— 这正是它可以随手给人的原因。

8. 地址复用是隐私问题，不是共识问题

区块链是公开且永久保存的账本，所以地址不是一个能躲在其后的账户，而是一个永久标签。向同一地址的每一笔 付款，连同金额与时间，都会被任何人关联起来。有两个后果值得强调：

• 聚类分析。 把同一个地址用于发工资、交易所提现和捐款，观察者无需破解任何密码学，就能 画出你的收入、对手方与消费图谱。
• 密钥暴露。 一个地址第一次花费时，那笔输出的公钥就永久公开了。而使用新地址可以为所有 尚未移动的资金保留「原像」这一层保护。

标准解法是分层确定性钱包（BIP32／BIP44）：从同一个种子为每一笔收款派生新地址，找零也发往新地址。 复用地址既不多花手续费，在链上也完全合法 —— 这正是大量软件依然这么干的原因。

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

• 上游：私钥 → 压缩公钥 提供这里要哈希的那 33 字节。
• 同辈：用非压缩 65 字节公钥构建的同类型地址 —— 同一个秘密，另一个地址。
• 同辈：嵌套 SegWit 的 3… 地址 与 原生 SegWit 的 bc1q… 地址，它们复用完全相同的 hash160。
• 反方向：公钥 → hash160 → 各类地址，完全不需要私钥。

10. 安全须知

• 地址不泄漏密钥信息，可以放心公开；私钥和 WIF 不行。
• 请在签名设备上逐字符核对地址。4 字节校验和只能抓住笔误，抓不住蓄意替换。
• 面对新地址，先小额试转，等确认后再转剩余部分。

11. 常见错误

• 不小心哈希了非压缩公钥。 把 K…／L… WIF 导入一个按 65 字节 形式求哈希的钱包（或反过来），余额会显示为零，而币其实安然躺在另一个地址上。
• 以为地址可以被反推。 无论多少算力，都不可能把 146ZNjH7… 变回公钥或私钥； 那需要遍历哈希的全部原像，不现实。
• 把前缀当校验。 以 1 开头既不证明地址正确，也不证明网络正确，甚至不证明 它是 P2PKH —— 去解码。
• 手工「修正」被拒绝的地址。 钱包提示「校验和无效」就意味着地址是错的；靠猜去补正是 销毁币的经典方式。
• 主网和测试网混用。 两者看起来都像那么回事，决定币落在哪条链上的是版本字节。

12. 速查表