协议演进 / BIP/比特币改进提案 / BIP-178
BIP-178
扩展钱包导入格式 WIF 的尾缀字节，让导出的私钥自带它对应的地址类型，导入时不必再逐一试探。本 BIP 目前处于草案状态。
一、档案卡
| 编号 | BIP-178 |
|---|---|
| 标题 | Version Extended WIF |
| 作者 | Karl-Johan Alm <[email protected]> |
| 指定日期 | 2018-04-04 |
| 层级 | Applications（应用） |
| 类型 | Specification（规范类） |
| 状态 | Draft（草案） |
| 阅读版 | https://bips.dev/178 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0178.mediawiki |
二、放在哪一族
私钥导入导出与地址类型族。WIF（Wallet Import Format）是把单个私钥写成可复制字符串、在钱包之间搬运的传统格式；本篇不改 WIF 主体，只动它末尾的标志字节，目标是让私钥与“它该用哪种地址”一起旅行。
它与地址格式的演进直接挂钩：同一把私钥能对应 P2PKH、嵌套 SegWit 与原生 SegWit 等不同地址，其中原生 SegWit 的 Bech32 格式见 BIP-173，嵌套方式涉及 BIP-16 的 P2SH。地址类型越多，WIF 不标类型的代价就越大——这正是本篇的出发点。本篇基于 Thomas Voegtlin 在 bitcoin-dev 邮件列表的初始提议与 Electrum 3.0 的实现，原文致谢一节有明确交代。
三、它要解决什么
同一把私钥可以关联多种地址：传统的 P2PKH（1…）、把 SegWit 公钥嵌进 P2SH 的 P2SH-P2WPKH（3…）、原生 SegWit 的 P2WPKH（Bech32）等等。
现行 WIF 只有一个 1 字节尾缀，用来表示对应公钥是压缩（尾缀 0x01）还是未压缩（无尾缀），没有办法说明这把私钥当初关联的是哪一种地址。后果是：导入私钥时，钱包只能假设所有类型都有可能，并逐一追踪每种可能的地址，既费资源，也容易让用户困惑——钱明明在其中一种地址里，钱包却要把几种都查一遍。
把这个尾缀扩展一下，让它顺带说清地址类型，导入就能一步到位。
四、规则本身
4.1 尾缀编码表
私钥数据仍是 uint256，其后的可选 uint8 标志被扩展为下表（扩展类型一律为压缩公钥）：
| 尾缀值 | 类型 | 含义 |
|---|---|---|
| 无尾缀 | P2PKH_UNCOMPRESSED | 未压缩传统公钥，公钥格式未知 |
0x01 |
P2PKH_COMPRESSED | 压缩传统公钥，公钥格式未知 |
0x10 |
P2PKH | 压缩公钥，只对应传统 P2PKH（1…） |
0x11 |
P2WPKH | 压缩公钥，只对应 Bech32 原生 SegWit |
0x12 |
P2WPKH_P2SH | 压缩公钥，只对应嵌套在 BIP-16 P2SH 里的 SegWit（3…） |
4.2 导入时的两种结果
- 私钥用的是旧类型（无尾缀或
0x01）：钱包仍须按老办法，把各种地址类型都纳入追踪； - 私钥用的是扩展类型（
0x10／0x11／0x12）：钱包只需追踪那一种对应地址。
原文特别区分 0x01 与 0x10：前者可以对应上表任何类型，后者只对应传统 P2PKH，二者不可混为一谈。
4.3 兼容性（原文的如实交代）
本提案在旧软件方向上不向后兼容：不认识新尾缀的软件会无法理解这个“压缩标志”。原文指出，要改成兼容并非难事——例如把“压缩”改为“尾缀不为 0”而非死认数值 1——但本篇文本本身没有这样改。
反方向兼容成立：新钱包永远能读旧 WIF，只是对旧格式仍须假设各种地址都可能、并全部追踪，与今天无异。
原文还给了一个参考实现链接：一份只加入这些类型定义、但尚未实际使用它们的 Bitcoin Core 拉取请求（PR 12869）。
五、谁必须动
普通持币人：只有在导出／导入单把私钥时才可能碰到它。用扩展格式导出的私钥，拿到不支持的旧钱包里可能导入失败，跨钱包搬运前要先确认对方支持。
钱包开发者：若实现本篇，需在导出时按地址类型写入新尾缀，在导入时按尾缀只追踪对应地址；同时保留对旧 WIF 的完整读取能力。
全节点与矿工、共识层：无关。WIF 是钱包之间的私钥搬运格式，不上链、不进协议。
六、现在算不算数，以及一个常见误读
状态为 Draft（草案）。档案里它的 Comments-Summary 还记着 “Discouraged for implementation (one person)”——即曾有一人明确不鼓励实现。加上原文自承对旧软件不兼容、参考实现也只是“加入类型但未使用”，本篇应被当作一份待议的设计稿来读，而不是今天导入私钥时可假定钱包都支持的现行标准；具体钱包是否支持扩展尾缀，应查该钱包自身说明。
常见误读：
“扩展 WIF 改变了私钥本身或让私钥更安全。”
不对。私钥的 256 位数据没有任何变化，变的只是一个尾缀字节所携带的“地址类型标签”。它不增加也不减少私钥的安全性；标签写错或被旧软件误读，后果是导入失败或追踪错地址类型，不是币被盗，也不是币凭空消失——币始终在对应地址上。
七、延伸
- 阅读版：https://bips.dev/178
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0178.mediawiki
- 相关：BIP-173 Bech32 地址、BIP-16 P2SH
- 仓库总目录：https://github.com/bitcoin/bips