Bech32 / Bech32m 解码与校验

本页做什么

bech32 地址就是一串带 BCH 校验和的 base32 字符串，解码后只得到两个事实：witness 版本与 witness 程序。这两个事实就是地址的全部 —— scriptPubKey 字面上就是 OP_n 加上那个程序：

把任意 bc1…、tb1…、v0 或 v1 地址粘进来即可。本页会展示解码的每一个阶段，告诉你 匹配的是哪个校验和常量（因此适用于 BIP173 还是 BIP350），遇到非法输入则原样打印解码器给出的原因，而不是 自己猜。

1. bech32 字符串的构成

分隔符的作用是让 hrp 不必转义就能写出，而它选数字 1 而不是某个符号，是因为符号在复制粘贴时 很容易出问题。用 1 是安全的，因为它被刻意排除在数据字符集之外，hrp 到哪里结束永远没有歧义。

2. 5 位字符集，以及为什么是 5 位

数据部分是以这个字母表、这个顺序构成的 base32 字符串：

恰好 32 个字符，所以每个字符恰好 5 位 —— 「5 位」这个数字就是这么来的。注意少了哪些字符： 1（它是分隔符）、b、i、o（视觉歧义），这也意味着不会 有两个形近字形同时参与编码。该字母表还经过挑选，使「看起来相似却相差不止 1 个比特」的字符对尽可能少， 因为校验和的优化目标正是检测少量的比特错误。

代价是长度 —— base32 比 base256 大约多出 15% 的字符；收益是没有大小写可弄错、可以毫无歧义地念出来， 并且能使用二维码的字母数字模式（比字节模式紧凑 45%）。

3. 8 位到 5 位的转换与补零规则

witness 程序是字节串，数据部分是 5 位值的串。转换按最高位在前进行：取出程序的比特，每 5 位切一组， 最后一组不足时用 0 补齐。

因为补零最多只有 4 位，多一个或少一个 base32 字符都会明显不对。所以这条规则很严格，也是解码器必须 强制执行的规则：

忽略这条规则的解码器，会让同一个程序对应多个不同的字符串，这对地址完整性不利，而且会让补零比特成为 错字藏身之处。BIP173 与 BIP350 都为这一点准备了测试向量： bc1zw508d6qejxtdg4y5r3zarvaryvqyzf3du 属于「补零超过 4 位」， tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3pjxtptv 属于「非零补零」。 本页解码器用 Invalid padding: invalid padding 拒绝了这两个 —— 具体检查是：最后一个完整字节 之后剩余的比特数必须小于 5，且移位后的累加器必须为零。

4. BCH 校验和

校验和不是哈希。它是定义在 GF(32) 上的 BCH 码 —— 一种线性纠错码，其代数结构能对「哪些错误一定被 抓到」给出保证：

GEN = [0x3b6a57b2, 0x26508e6d, 0x1ea119fa, 0x3d4233dd, 0x2a1462b3]

def polymod(values):
    chk = 1
    for v in values:
        b = chk >> 25
        chk = (chk & 0x1ffffff) << 5 ^ v
        for i in range(5):
            chk ^= GEN[i] if ((b >> i) & 1) else 0
    return chk

# hrp 以 [每个字符的高 3 位] + [0] + [每个字符的低 5 位] 的形式参与
验证：  polymod(hrp_expand(hrp) + data) == 1          # bech32
验证：  polymod(hrp_expand(hrp) + data) == 0x2bc830a3 # bech32m

hrp 也参与校验和，而且按「高位在前」折叠进去：[ord(c) >> 5 for c in hrp] + [0] + [ord(c) & 31 for c in hrp]。这个顺序意味着：只在 hrp 字符低 5 位内部翻比特的错误（比如把 b 变成 c）依然落在该码设计的保护范围内。这也正是为什么 M1VUXWEZ 无效 —— 它的校验和 是按大写 hrp 算的；而 BC1QW508D6QEJXTDG4Y5R3ZARVARY0C5XW7KV8F3T4（校验和按小写取值算） 是有效的。

BIP173 还测量了错误字符超过 4 个时的表现。下表单位是「每十亿次中的失败次数」，而随机的 30 位校验和 基线是每十亿次 0.931：

BIP350 对新常量重做了这套分析，并给出了专门针对 bc1 地址形态的数字。对于用 bech32m 解码器 校验的 bech32m 字符串：24.34% 的单错误模式被确定检出，75.66% 以概率 1 − 2⁻³⁰ 检出；对落在 28 字符窗口内的至多两个错误是 16.85% / 83.15%；对任意位置的至多两个错误是 15.72% / 84.23%，另有 0.039% 落在 2⁻²⁵。同样这些字符串若交给 bech32 解码器，表现明显更差 —— 这正是「干净 切割」的意义。

5. bech32 与 bech32m —— 逼出 BIP350 的插入弱点

这是本页最关键的部分，因为它解释了为什么同一种地址会存在两套几乎相同的编码。

2020 年人们发现 bech32 的校验和有个洞。引用 BIP350 的原话：

我们用本页自己的解码器复现了它。取一个合法、末字符为 p 的 bech32 v0 地址，在那个末尾 p 之前紧邻插入 q：

BIP350 的修法刻意做到最小：其他一切不变，只把异或进校验和的那个常量从 1 改成 0x2bc830a3。对 bech32m 字符串做同样的插入，校验和就不再能通过（polymod 返回 920205498 而不是 734539939），于是这次改动是被校验和自己抓到的，而不是靠运气。

还有两点补全整个图景。第一，已有的 v0 地址从未处于危险之中：BIP350 指出该弱点「由于限制在两种特定长度， 不影响 witness v0 的 BIP173 地址现有用法」。插入字符会改变字数，于是程序要么长度变了、要么破坏了补零规则 —— 在我们上面的复现里，被改动的字符串其实是被本页的 Invalid padding 检查拒绝的；而 v1+ 的插入 则由 bech32m 常量拦下。第二，BIP173 自己在 2024 年补充了一条披露：该方案「对少于 5 个连续字符的插入与删除 并不总是稳健」，这也是 BIP173 现在只适用于 v0 输出的原因。

6. 本页执行的合法性规则

由此地址长度被严格约束：14 到 74 个字符，且长度对 8 取余不可能是 0、3、5；v0 地址永远是 42 或 62 个 字符。

7. 实例演算：示例 P2WPKH 地址

注意这个 witness 程序就等于同一把密钥在 hash160 → 地址 里打印的那个 hash160； 而测试网地址携带同样的程序、却是另外 6 个校验和字符：hrp 参与校验和计算，所以「主网/测试网搞混」这种情况 不可能蒙混过关。

8. 实例演算：示例 P2TR 地址

最后一行就是两个示例地址在一句话里的区别：P2WPKH 的程序是公钥的哈希，而 P2TR 的程序本身 就是一把公钥（调整后的那把）。其余一切 —— 编码、分隔符、5 位字、6 字符校验和 —— 完全相同；不同的 只有版本字与校验和常量。

9. 本页展示的失败路径

下面的非法字符串在每一次运行中都会被现场测试，和你粘贴的内容一起：

还有一条会让人意外的边界说明：BIP350 自己的测试向量里包含一些合法的 bech32m 字符串（例如 A1LQFN3A），它们根本不是 segwit 地址（数据部分只有校验和）。segwit 地址解码器会在其上再套一层 地址规则，因此会拒绝它们 —— 这是正确的，会给出理由，也不会崩。

10. 安全须知与常见错误

• 绝不要让软件「修好」一个地址。 BIP173 说得很明确：实现不应纠错，最多只能提示错误可能 位于何处，因为被纠正出来的地址未必是原意，币就发去了别处。只检测，不纠正。
• 小写才是传输格式。 编码器必须输出小写；大写用于展示与二维码（字母数字模式）；一个 字符串绝不能大小写混用。
• bc1q… 与 bc1p… 只差一个字母和一个常量。 正是校验和常量 让它们不可能互相误读。
• 合法地址不一定花得掉。 一个 witness v2–v16 地址，或者一个你不知道脚本的 v0 程序， 都能完美解码，却可能没有任何现有软件能花掉它。往那里打币就是把币烧掉。

11. 速查表