Bech32和Bech32m如何区分？

bc1开头只能说明地址采用Bech32家族的人类可读格式，不能单独判断它是SegWit v0、Taproot还是有效主网地址。BIP-350引入Bech32m后，解码器必须让见证版本与校验方式匹配。

两种格式只差校验常量吗

Bech32与Bech32m共享HRP、分隔符、字符集和多项式校验结构，关键变化是最终校验常量。这个变化修复了旧Bech32在特定条件下插入或删除字符仍可能保持有效的问题。对钱包而言，不能“任意选一种能通过的校验”，而要先解码见证版本，再要求对应格式。

见证版本	地址常见外观	必须使用
v0	bc1q…	Bech32
v1（Taproot）	bc1p…	Bech32m
v2–v16	仍在bc1家族	Bech32m

bc1q与bc1p是编码后常见首字符，不是独立安全规则。真正判断来自解码出的版本值。

验证一条地址的顺序

1. 检查整串没有混合大小写；全大写或全小写可按规范处理，但产品通常统一显示小写。
2. 找到最后一个分隔符1，前面是HRP。比特币主网应为bc，测试网络会使用其他HRP。
3. 把数据部分字符映射为5位值，验证字符集和总长度。
4. 计算校验和，判断结果属于Bech32还是Bech32m。
5. 取第一个数据值为见证版本，把余下5位组转换为8位见证程序。
6. 核对版本与校验类型，并检查见证程序长度；v0还要满足P2WPKH或P2WSH规定长度。

任何一步失败都应拒绝发送，不应通过删除字符、替换相似字符或切换网络来“修复”。

为什么旧钱包会拒绝bc1p

早期钱包只实现BIP-173，可能看得懂bc1前缀，却不知道v1必须用Bech32m，因而正确拒绝或错误提示。兼容性测试要覆盖接收、展示、二维码和硬件设备确认，而不是只在前端正则里允许bc1。

发送方升级支持不影响收款方控制Taproot输出的能力，但若交易构造库不认识新见证版本，可能产生错误脚本或拒绝估费。大额转账前应用小额测试，并在硬件钱包屏幕确认完整地址与网络。

地址格式不证明收款对象

校验通过只能发现输入错误，不能证明地址属于某个人或平台。攻击者可以生成完全有效的bc1地址。仍需从可信渠道取得地址、核对完整字符，并防止剪贴板替换。

不能只看地址是否以bc1开头

Bech32校验常数为1，Bech32m使用0x2bc830a3；见证版本0必须配Bech32，版本1至16必须配Bech32m。解码器如果接受错误组合，可能把有校验但规则不合法的字符串继续交给转账流程。编码时还要检查HRP：主网是bc，测试网络常见tb，regtest为bcrt。

见证程序长度也受版本规则约束。P2WPKH的v0程序为20字节，P2WSH为32字节，Taproot的v1程序为32字节。钱包应先完整解码、验证大小写不能混用和校验类型，再根据目标网络与见证版本构造scriptPubKey。

Taproot脚本与密钥路径见Taproot两种花费路径，HD钱包的派生隔离见BIP32硬化派生，签署最终交易前可结合PSBT核对清单。