比特币密钥与地址浏览器
探索比特币的密码学基础。直观展示私钥、公钥与地址派生过程的教育工具，适合学习比特币密钥层级结构。
探索比特币的密码学基础。
直观地了解私钥、公钥与地址之间的关系。
这个教育工具展示了比特币密钥和地址类型的结构与格式。生成随机示例值，观察派生链中的每一步如何转换数据——从原始熵到您日常使用的地址。
仅供教育用途
切勿将任何网站上显示的密钥用于真实资金。本工具演示比特币密钥和地址的结构与格式，而非实际的密码学派生过程。此处生成的值是随机示例，旨在说明正确的前缀、长度和编码格式。真正的密钥派生需要安全的离线软件。
密钥与地址浏览器
点击下方按钮生成一组新的随机示例值。每次生成使用 Web Crypto API 获取随机字节，然后将其格式化以匹配比特币真实的密钥和地址结构。
私钥（原始）
随机 256 位数（32 字节）
--
64 个十六进制字符 = 256 位熵，通过 crypto.getRandomValues() 生成
钱包导入格式（WIF）
Base58Check 编码的私钥
--
结构：版本字节（0x80）+ 私钥字节 + 压缩标志（0x01）+ 4 字节校验和。校验和是 SHA-256(SHA-256(payload)) 的前 4 字节，结果再进行 Base58 编码。压缩 WIF 密钥以 K 或 L 开头；未压缩的以 5 开头。
注意 上方示例显示正确的格式结构。实际 WIF 转换需要使用 SHA-256 双重哈希进行 Base58Check 编码。
压缩公钥
通过 secp256k1 椭圆曲线乘法得到 33 字节
--
派生：公钥计算为 P = k * G，其中 k 是私钥，G 是 secp256k1 生成点。压缩格式使用前缀 02（y 为偶数）或 03（y 为奇数），后跟 32 字节 x 坐标。这是单向函数——无法从公钥反推私钥。
地址格式
公钥哈希的不同编码方式
--
以 1 开头 | ~25-34 字符 | Base58Check(0x00 + RIPEMD160(SHA256(pubkey)) + checksum)
--
以 3 开头 | ~25-34 字符 | Base58Check(0x05 + RIPEMD160(SHA256(script)) + checksum)
--
以 bc1q 开头 | ~42 字符 | Bech32(hrp + witness version 0 + 20-byte keyhash)
--
以 bc1p 开头 | ~62 字符 | Bech32m(hrp + witness version 1 + 32-byte tweaked pubkey)
派生流程图
下图展示了从随机熵到比特币地址的完整链路。每次转换都是单向密码学运算——只能向前，永远无法逆转。
随机 256 位数
私钥（十六进制）
WIF 格式
Base58Check 编码
版本 + 密钥 + 标志 + 校验和
公钥
secp256k1 (k * G)
RIPEMD160(SHA256(pubkey))
20 字节哈希
P2PKH
1...
P2SH
3...
SegWit
bc1q...
Taproot
bc1p...
理解椭圆曲线密码学
比特币使用 secp256k1 椭圆曲线，定义为有限域上的方程 y² = x³ + 7。选择这条特定曲线是因为其高效性以及没有已知后门——与一些在密码学界引发担忧的 NIST 曲线不同。
点乘法
私钥 k 与生成点 G 相乘，得到公钥 P = k * G。此运算使用椭圆曲线上的反复点加法。该操作在一个方向上计算简单，但反向推导实际上不可行——这就是椭圆曲线离散对数问题（ECDLP）。
密钥空间大小
secp256k1 曲线的阶约为 2256——大约 1.16 x 1077 个可能的私钥。作为参考，可观测宇宙中原子数量估计约为 1080。以当前或可预见的技术，暴力破解私钥在计算上是不可能的。
压缩与非压缩
椭圆曲线上的点同时有 x 和 y 坐标（未压缩 64 字节）。由于 y 可以通过曲线方程从 x 推导出来，压缩密钥只存储 x 加上一个表示 y 奇偶性的前缀字节——将大小从 65 字节减少到 33 字节。现代比特币专用压缩公钥。
Schnorr 签名（Taproot）
Taproot 引入了 Schnorr 签名（BIP 340），相比 ECDSA 有多项优势：可证明安全、支持高效的多重签名聚合，并使复杂的花费条件在链上与简单支付无法区分——显著提升隐私性并降低手续费。
私钥格式详解
比特币私钥本质上只是一个 256 位数，但可以用多种格式表示。每种格式有不同用途——从原始计算到人类可读的导入/导出。
| 格式 | 前缀 | 长度 | 描述 |
|---|---|---|---|
| 原始十六进制 | — | 64 字符 | 纯十六进制，32 字节 |
| WIF（非压缩） | 5 | 51 字符 | Base58Check，无压缩标志 |
| WIF（压缩） 推荐 | K 或 L | 52 字符 | Base58Check，含 0x01 压缩标志 |
| 迷你私钥 | S | 30 字符 | 紧凑格式，用于实体硬币 |
地址编码：Base58Check 与 Bech32
比特币对地址使用两种根本不同的编码方案。理解其区别可以解释为什么地址格式看起来差异如此之大，以及为什么较新的格式被认为更优越。
- 使用 Base58 字母表：1-9、A-Z、a-z，排除 0、O、I、l 以避免视觉混淆
- 4 字节校验和来自双重 SHA-256 哈希并附加到负载
- 区分大小写（混合大小写），使二维码效率较低
- 版本字节决定前缀：0x00 = "1..."，0x05 = "3..."
- 可以检测错误，但无法定位哪个字符有误
- 使用 32 字符小写字母表：a-z 排除 b、i、o + 数字 0-9 排除 1
- BCH 纠错码最多可检测 4 个字符错误并定位它们
- 全部小写——二维码更高效（字母数字模式）
- 人类可读部分（bc）+ 分隔符（1）+ 数据 + 6 字符校验和
- Bech32m（BIP 350）修复了原始 Bech32 中的长度扩展可变性问题
为什么存在不同的地址类型？
比特币地址格式的演进反映了多年的协议改进，每次都在解决特定限制的同时保持与整个网络的向后兼容性。
P2PKH — 原始形式
随比特币本身一同引入。Pay-to-Public-Key-Hash 通过在地址中使用公钥哈希增加了一层安全性。如果 ECDSA 遭到破解，P2PKH 地址中尚未暴露公钥的资金仍受哈希函数保护。
P2SH — 可编程脚本
BIP 16 引入了 Pay-to-Script-Hash，允许复杂的花费条件（多重签名、时间锁）同时保持地址简洁。发送方无需了解脚本——只需发送到 "3..." 地址。后来成为 SegWit 兼容性的封装层。
Bech32 — 隔离见证
SegWit 升级（BIP 141/173）将签名数据与交易数据分离，修复了交易延展性问题并启用了闪电网络。原生 SegWit 地址使用 Bech32 编码，交易重量降低约 30-40%，手续费相应降低。
Bech32m — Taproot
Taproot 升级（BIP 340/341/342）引入了 Schnorr 签名、MAST（梅克尔化替代脚本树）和改进的隐私性。复杂的多重签名交易在链上与简单支付无法区分。使用 Bech32m 编码（BIP 350）修复了原始 Bech32 中细微的校验和问题。