协议演进 / BIP/比特币改进提案 / BIP-149
BIP-149
若 BIP9 的 segwit 部署到期未激活，则以保证锁定的用户激活软分叉再部署一次隔离见证。本 BIP 目前处于已关闭状态。
一、档案卡
| 编号 | BIP-149 |
|---|---|
| 标题 | Segregated Witness (second deployment) |
| 作者 | Shaolin Fry <[email protected]> |
| 指定日期 | 2017-04-14 |
| 层级 | Consensus (soft fork)（共识（软分叉）） |
| 类型 | Specification（规范类） |
| 状态 | Closed（已关闭） |
| 阅读版 | https://bips.dev/149 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki |
二、放在哪一族
激活机制族里的“备选方案”：它与 BIP-148 出自同一作者、指向同一个目标（让隔离见证落地），但处理的是不同的失败情形。
分工是这样划的：
BIP-148：在既有 BIP9 部署到期之前发力，以强制信号促成它在原窗口内锁定
BIP-149（本篇）：假设既有部署最终到期失败，则在其结束之后，再开一次全新的部署
被部署的内容本身没有任何变化，仍是那一包规则：
BIP-141：隔离见证（共识层）
BIP-143：v0 见证程序的签名验证
BIP-147：哑栈元素可锻性（NULLDUMMY）
本篇的正式定性是 UASF——用户激活软分叉（user activated soft fork）。
三、它要解决什么
原文的动机写得很坦白：尽管生态中很大一部分人希望激活这项软分叉，矿工却迟迟不愿为 BIP9 的 segwit 部署信号。若矿工信号这条路走不通，按原框架，部署会在 2017 年 11 月 15 日到期作废，此前数年的工作要从头再来。
本篇的回答是把主动权换到用户一侧：设计一个用户激活的软分叉，用带“保证锁定”（guaranteed lock-in）的版本位机制再部署一次 segwit——即便矿工信号不足，到超时点也会锁定。
这样安排的两个目的，原文都写明了：
- 给用户留出充足的准备时间，不再要求矿工绝对多数（supermajority）配合；
- 同时仍保留矿工提前激活（MASF）的可能：矿工若在新部署期间主动信号达标，可以走更快的老路。
参考实现还自带一道保险：原文写明，它在 2017 年 11 月 7 日之前拒绝在主网运行，在此之前只能用于测试网与 regtest。
四、规则本身
4.1 触发条件：只在失败之后
这是一次有前提的部署，原文给了两条硬约束：
- 只有当 BIP9-segwit 未能在 2017 年 11 月 15 日超时之前锁定或激活时，才应部署本篇；
- 本篇不得在 2017 年 11 月 15 日之前部署。
换句话说，它从设计上就排在既有部署之后，不与它抢跑。原文的理由部分也说明，开始时间特意设在 BIP9-segwit 超时之后，就是为了避开与旧节点之间的兼容问题。
4.2 部署参数：改用 BIP8
本篇通过 BIP-8 部署，部署名仍为 “segwit”，使用位 1（bit 1）——复用同一个名字，是为了与现有挖矿软件在 getblocktemplate 一侧保持兼容。
主网参数：
- 开始时间：2017 年 11 月 16 日午夜 UTC（时间戳 1510790400）；
- 超时时间：2018 年 7 月 4 日 UTC（时间戳 1530662400）。
测试网不设部署，因为原文写明测试网上 segwit 已经激活。与 BIP-9 的关键区别在超时语义：BIP8 的这套安排带有到时保证锁定的意味，这正是摘要里 “versionbits with guaranteed lock-in” 的含义。
4.3 服务位：NODE_UAWITNESS
本次部署将设置一个新的服务位：
NODE_UAWITNESS = (1 << 5)
以便网络上能识别哪些节点在为这次用户激活部署提供见证服务。
4.4 不兼容声明
原文明确提醒：本部署与 BIP9-segwit 部署不兼容，不应与它同时运行。这也是 4.1 中“先后而非并行”的另一面——两套部署共用位 1 与同名标识，混跑会造成判定混乱。
五、谁必须动
普通持币人：本篇的立足点就是“用户激活”：真正需要动的是愿意执行这套新部署规则的节点运营者。是否运行，只影响自己节点的验证立场，不改变钱包的日常收付。
钱包开发者：不涉及钱包功能改造。它要部署的仍是 BIP-141 一系的既有规则，钱包对 SegWit 的支持方式不因部署换代而改变。
全节点与矿工：节点若采纳本篇，需在 2017 年 11 月 15 日之后切换到 BIP8 的新部署窗口，并设置 NODE_UAWITNESS 服务位；矿工仍可通过信号走 MASF 的提前激活路径，但不再握有“拖到到期即作废”的否决权。同时必须注意：不得与 BIP9-segwit 部署同时运行。
共识层：本篇拟议的是一次新的软分叉部署，其内容规则与第一次完全相同，新的只是激活机制（BIP8 + 保证锁定）与时间表。
六、现在算不算数，以及一个常见误读
状态为 Closed（已关闭）。它是一份写好、备用的方案：触发条件（BIP9-segwit 到期失败）与它的部署窗口是连在一起设计的，状态关闭意味着它没有作为一次独立部署被推进执行。它与 BIP-148 的差别正可对照来看：148 在原窗口内发力、状态为 Deployed；149 是原窗口失效之后的第二套时间表，最终停留在纸面。
常见误读：
“BIP-149 给隔离见证加了新功能，所以才需要第二次部署。”
不对。原文摘要第一句就锁定了范围：被部署的就是 BIP-141、BIP-143、BIP-147 这三份，一字未改。第二次部署换的只是激活办法——从矿工信号主导的 BIP9，换成带保证锁定的 BIP8 用户激活路径。
七、延伸
- 阅读版：https://bips.dev/149
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki
- 相关：BIP-148 Segwit 部署的强制激活、BIP-8 按高度锁定的版本位、BIP-9 版本位、BIP-141 隔离见证（共识层）
- 仓库总目录：https://github.com/bitcoin/bips