Bech32m

这个缺陷范围很窄，但确实存在。只要一个 bech32 字符串以字符 "p" 结尾，在这最后一个字母之前插入或删除任意数量的 "q" 字符，校验和仍然有效，因此一个被损坏的地址也可能通过校验。BIP-350堵上了这个漏洞：bech32 在校验和中合并的值是1，而该提案改为合并0x2bc830a3。

运作方式

Bech32m 就是改了一个数字的 bech32。编码器先展开人类可读前缀，附上数据，对结果运行同一个 BCH 多项式，只在最后一步有所不同：输出与0x2bc830a3 合并，而不是与1合并。读者能看到的一切都保持不变：同样的32个字符的字母表，同样的 "1" 分隔符，同样的六个校验和字符，同样的90个字符的长度上限。

改变这个常量不是副作用，而是机制本身。由于两种方案互不一致，bech32m 字符串无法通过 bech32 校验和测试，bech32 字符串也无法通过 bech32m 的测试，因此旧软件会直接拒绝新地址，而不是只理解一半。BIP-350将其描述为有意为之的兼容性中断，其取舍是不在原处悄悄修补 bech32。

分界线是见证版本。见证版本0，即用于单个密钥和脚本的 bc1q 地址，继续使用 bech32。见证版本1至16使用 bech32m。目前只定义了版本1，即 Taproot，因此实际上 bech32m 就意味着 bc1p。这条规则是为涵盖尚不存在的版本而写的，所以正确的钱包检查的是版本号，而不是地址前缀。

在哪里会遇到它

bc1p 收款地址采用 bech32m 编码，长度为62个字符，编码的是一个32字节的密钥。在测试网络上，同样的输出显示为 tb1p。Taproot 输出在2021年11月14日的区块709,632起可以花费，bech32m 地址从这一刻起在主网上开始承载真实价值。

Bitcoin Core 在22.0版本中实现了 BIP-350，自该版本起，每一个接受地址的远程过程调用，对于见证版本1及以上都要求使用 bech32m。23.0版本更进一步：新创建的描述符钱包会自动获得 tr() 描述符，因此无需指定，就会给出 bc1p 地址。

实际的不便出现在提币界面。一些平台仍然拒绝 bc1p 目标地址，因为其地址验证器只认识 bech32，不认识较新的常量。这种情况下您的钱包没有任何问题，由同一助记词生成的 bc1q 地址会把币存入同一个钱包。

Bech32m vs P2TR

Bech32m 是一种编码，P2TR 是一种输出类型，两者目前对应，只是因为时间上的巧合。Bech32m 规定如何把任何版本1或更高的见证程序写成文本。P2TR 规定版本1的程序意味着什么：一个32字节的调整后公钥，可以用 Schnorr 签名花费，也可以通过披露脚本花费。目前流通的每一个 bech32m 地址编码的都是 P2TR 输出，但一旦见证版本2被分配给任何用途，这一点就不再成立，因为那些地址同样是 bech32m，却不是 Taproot。