Bech32

BIP-173于2017年引入 bech32，用以取代 SegWit 输出所用的 Base58Check。其字母表包含32个字符，并有意省去"1"、"b"、"i"和"o"，以免外形相近的字符被误换，且任何 bech32 字符串都不超过90个字符。当钱包在您刚粘贴完地址的瞬间就拒绝该地址时，发现错误的正是 bech32 校验和。

运作方式

bech32 字符串由三部分按固定顺序组成：人类可读前缀、分隔符"1"，以及以六个校验字符结尾的数据部分。主网使用前缀"bc"，测试网和 signet 使用"tb"，regtest 使用"bcrt"，因此钱包在解码其他内容之前，就能凭开头的字母识别网络。分隔符也是字母表中没有"1"的原因：这样它只会在分界处出现一次，解析器从右向左扫描即可找到分割点。

校验和是对整个字符串（包括前缀）计算的 BCH 码。BIP-173保证可检测出影响至多四个字符的任何错误，并将漏检更大错误的概率控制在10亿分之一以下。Base58Check 没有可与之相比的能力：其末尾四个字节是截断的双重 SHA-256哈希，只能让钱包知道出了问题，却无法进一步指出问题所在。

大小写没有含义。bech32 地址全部小写或全部大写均有效，混用则无效，钱包显示的是小写形式。BIP-173要求在二维码中使用大写，因为大写字母数字可启用二维码的字母数字模式：该模式将每个字符压缩为5.5位，而字节模式需要8位，生成的图案更粗疏，手机摄像头能更快锁定。

在哪里会遇到它

每个 bc1q 地址都是 bech32。42个字符的地址编码一个20字节的见证程序，支付给单个密钥；62个字符的地址编码一个32字节的程序，支付给脚本。两者都是见证版本0，而版本0是 bech32 现在唯一允许承载的版本。

这种编码也出现在地址之外。BOLT11 规范下的闪电网络发票借用了它，前缀如"lnbc"，并有意不受90个字符上限的约束，因为发票包含支付哈希、金额、描述和路由提示，而不是一个简短的程序。

问题出现在交易所的提币表单上。2017年之前编写的验证程序只识别 Base58 字符串，会对一个完全有效的 bc1q 地址提示"invalid address"。这是平台自身的限制，而非您钱包的问题，解决办法是提币到该平台接受的地址类型（由同一种子派生），而不是另寻其他软件。

Bech32 vs Bech32m

bech32 和 bech32m 只相差一个常量，其他完全相同。两者使用相同的字母表、相同的结构和相同的六个校验字符。bech32m 将合并进校验和的值从1改为0x2bc830a3，二者的划分由见证版本决定：版本0的输出沿用 bech32，版本1至16使用 bech32m。把两者视为可互换的软件会接受本应拒绝的字符串，而这正是 BIP-350所要防止的故障。

Bech32 vs Base58Check

bech32 和 Base58Check 是相互竞争的编码，而不是相互竞争的地址类型。Base58Check 将一个版本字节和一个20字节的哈希加上四字节校验和封装起来，生成区分大小写、以1和3开头的字符串。bech32 将见证版本与见证程序一并编码，生成不区分大小写、以 bc1 开头的字符串。两种编码都不决定币被锁定给什么。它们决定的是：人工复制字符串的可靠程度、二维码需要多大，以及字符缺失时软件报错的响亮程度。