协议演进 / BIP/比特币改进提案 / BIP-173
BIP-173
为原生隔离见证输出定义带校验和的 Base32 地址格式 Bech32，取代 Base58 地址在见证场景中的位置。本 BIP 目前处于已部署状态。
一、档案卡
| 编号 | BIP-173 |
|---|---|
| 标题 | Base32 address format for native v0-16 witness outputs |
| 作者 | Pieter Wuille <[email protected]>, Greg Maxwell <[email protected]> |
| 指定日期 | 2017-03-20 |
| 层级 | Applications（应用） |
| 类型 | Informational（信息类） |
| 状态 | Deployed（已部署） |
| 替代文档 | Replaces: BIP-142 |
| 接替文档 | Proposed-Replacement: BIP-350 |
| 阅读版 | https://bips.dev/173 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki |
二、放在哪一族
地址格式族，紧接隔离见证（SegWit）落地。它替代先前的 BIP-142（见证地址的早期方案），为 BIP-141 定义的见证程序（witness program）提供一套可直接使用的原生地址编码。
与它直接相关的文档包括：
BIP-141：隔离见证（共识层定义见证程序）
BIP-143：见证交易的签名校验，其中给出 P2WPKH 与 P2WSH
BIP-350：Bech32m，对本篇校验和的后续修正，被列为 Proposed-Replacement
BIP-13 与 BIP-16：Base58 时代 P2SH 地址的来路，本篇要改进的对象之一
今天以 bc1q… 开头的原生 SegWit 地址，编码规则就出自本篇；以 bc1p… 开头的 Taproot 地址则已改走 BIP-350 的 Bech32m。
三、它要解决什么
比特币长期使用 Base58 地址，校验和是截断的双重 SHA256。原文列出它的几处局限：
- Base58 不能使用二维码的 alphanumeric 模式，在二维码里占空间；
- 大小写混合，不便手抄、在移动键盘上输入或口头念出；
- 双重 SHA256 校验慢，且没有明确的检错保证；
- 58 不是素数的幂（prime power），多数纠错码研究不直接适用；
- Base58 解码本身也相对复杂、较慢。
SegWit 引入了一类新输出——见证程序。把见证程序嵌进 P2SH 也能用，但效率与安全性不是最优；直接使用原生见证输出，需要一套为它准备的新地址格式。BIP-173 提出带校验和的 Base32 格式 Bech32，并在此之上定义 v0–16 见证输出地址。
四、规则本身
4.1 Bech32 字符串结构
一条 Bech32 字符串最长 90 个字符，由三部分组成：
- 可读前缀（HRP）：1–83 个 US-ASCII 字符，表示数据类型等对读者有意义的信息；
- 分隔符：恒为
1；若 HRP 内部也含1，以最后一个1为分隔符； - 数据部分：至少 6 个字符，只用排除
1、b、i、o后的字母数字字符集，以减少视觉混淆。
数据部分最后 6 个字符是校验和，不承载信息。校验采用 BCH 码：保证能检出至多 4 个字符的错误，更多错误漏检概率低于十亿分之一。原文明确提醒：实现不应擅自做“纠错”把无效地址改成另一个有效地址，最多提示用户错误可能出现的位置，否则可能把币发到错误地址、不可挽回。
4.2 大小写规则
编码器必须输出全小写；如需展示或二维码用途，可在编码之外转成全大写。二维码内优先用大写，因为可走 alphanumeric 模式，比 byte 模式紧凑约 45%。解码器不得接受大小写混合的字符串。
4.3 SegWit 地址格式
SegWit 地址就是对以下内容做 Bech32 编码：
- HRP：主网为
bc，测试网为tb； - 数据部分第一个值：见证版本号，范围 0–16；
- 其余：2–40 字节见证程序先按位重排为 5 位一组、末尾补零，再映射为字符。
解码时必须校验 HRP 与版本号范围，并把 5 位分组还原为字节；末尾不完整分组须不超过 4 位且全为零并丢弃。版本 0 还有已知长度限制：见证程序须为 20 字节（P2WPKH）或 32 字节（P2WSH），原文以 BIP-141 的规则提醒解码器应执行这类限制。
地址总长度在 14–74 字符之间；版本 0 地址恒为 42 或 62 字符。把见证版本转成脚本时须注意：版本 0 编为 0x00，版本 1–16 编为 OP_1–OP_16（0x51–0x60），转错会得到不可花费或不安全的 scriptPubKey。
原文例子（公钥对应的 P2WPKH）：主网 bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4，测试网以 tb1q… 开头。
4.4 兼容性
只有新软件能生成和识别这类地址，且收款方也须支持 SegWit；其他情形仍可用 P2SH 或 P2PKH 地址。
五、谁必须动
普通持币人：收款时可向支持 SegWit 的付款方提供 bc1… 地址；对方钱包不支持时，改用对方能识别的地址类型，不要强发。
钱包开发者：需实现 Bech32 编解码、校验和验证、大小写规则、见证版本与长度校验，并正确完成地址与 scriptPubKey 的互转；不得实现自动纠错替换。
全节点与矿工：本篇是应用层地址格式，不改共识规则。节点验证的是见证程序对应的脚本，地址只是链下展示与传递形式。
共识层：无改动。见证程序的共识定义在 BIP-141，不在本篇。
六、现在算不算数，以及一个常见误读
状态为 Deployed（已部署）。本篇定义的 Bech32 与 v0 见证地址已是原生 SegWit 的标准写法。原文 2024 年补入的披露指出：Bech32 校验对少于 5 个连续字符的插入或删除并不总是稳健，因此 BIP-350 提议把本篇方案限定于原生 SegWit v0 输出，v1 及以后改用 Bech32m。档案卡中它被列为 Proposed-Replacement，应按“提议接替”理解，不等于本篇已被废止。
常见误读：
“Bech32 地址就是 SegWit 本身。”
不对。SegWit 的共识规则在 BIP-141；BIP-173 只规定原生见证输出在钱包之间怎么书写、传递和校验。同一笔见证输出可以嵌进 P2SH 传递，不用 Bech32 也能上链，只是失去原生形式的效率与安全优势。
七、延伸
- 阅读版：https://bips.dev/173
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki
- 相关：BIP-141 隔离见证、BIP-142 被替代的早期方案、BIP-350 Bech32m
- 仓库总目录：https://github.com/bitcoin/bips