一个 BIP 的一生：从草稿文本到链上生效

两个容易混淆的“状态机”

谈比特币升级，常把“提案通过”当成链上生效，其实中间隔着两套彼此独立的状态机。第一套在 GitHub 上：一个 BIP 文档从草稿起步，经过评审进入 Deferred 或 Active 等状态——对共识类 BIP，Active 的含义仅仅是“规范文本已定稿可被实现”，与链上是否执行毫无关系。第二套在链上：软件实现合并进主流客户端后，规则还要经历基于区块头的部署流程。把这两套状态机分开，你就能给每一条“比特币升级新闻”找到它真实的坐标：是文档定稿、是客户端发版、信号开始，还是真的激活了？

部署机制：BIP9 版本比特

区块头的 version 字段长期预留若干未用比特，BIP9 把它们征用为投票通道：部署窗口内，矿工出块时可点亮某一位表示“我已准备就绪并准备执行新规则”。协议把窗口切成 2016 块的整数段，每个部署在每个段内处于四态之一：DEFINED（未开始）、STARTED（信号计数中）、LOCKED_IN（在某个窗口内信号达到阈值，进入固定准备期）、ACTIVE（自下一个窗口起全节点强制执行）。主网阈值历史上取窗口内 95% 的块信号，时间线以部署参数为准；窗口起始、超时与最短激活高度都是部署参数的一部分，读法见下文工具段。相对时间锁等早期升级正是沿这条路线推进的，可对照 OP_CHECKLOCKTIMEVERIFY 怎么用？比特币绝对时间锁的脚本与陷阱 理解“软分叉对老节点的降级保护”。

为什么软分叉不需要所有人同意

软分叉的兼容设计让“不同意”不等于“被抛弃”：新规则只收紧不放松，旧节点会用宽松规则验证新区块，只要诚实多数按新规则出块，链就安全前行——代价是旧节点把新规则下合法的输出当作 Anyone-can-spend 而依赖升级后的邻居，见 assumeUTXO同步安全吗？ 同期文档对节点版本的强调。这也解释了为什么信号阈值高、准备期长：协议在用时间换取“反对者的资金与算力不被强制没收”的可能性，与闪电的超时哲学异曲同工，见 闪电通道强制关闭全流程：从单方面落到链到惩罚窗口。

用节点亲自查阅升级进度

任何部署进度都不必听二手解读：getdeploymentinfo 会列出当前窗口里每个部署的名字、状态、信号计数、起止时间与超时高度，见 getdeploymentinfo如何看软分叉？；确认自己节点的执行版本则可看 getblockchaininfo 的软分叉节，背景见 getblockchaininfo怎样判断同步？。值得记住的常识是：信号来自矿工，但规则由节点执行——矿工能用算力选择做或不做，全节点用软件选择认或不认，升级争议的真实战场永远在节点端升级率上，这也是为什么各家发行说明与安全公告值得普通用户花时间读，见 Bitcoin Core版本说明怎么读？。

小结与风险提示

BIP 的一生是比特币治理的横截面：文档阶段靠评审与规范共识，部署阶段靠兼容性设计与时间换空间。“慢”不是缺陷，是这套状态机的设计目标本身——任何依赖未激活规则的集成，都应给每个状态机单独设里程碑。本文讨论协议流程，不构成投资建议。

一次部署的完整时间线模板

以历史上真实的软分叉节奏为参照，一次部署通常呈现这样的刻度：规范定稿与实现合并相隔数月；部署窗口开放后，信号以周为单位爬升，矿工通过升级出块软件间接完成“投票”；达到阈值的窗口结束后，全体节点无论是否升级都进入强制执行（对拒绝升级的老节点则是降级运行），规则在下一个窗口起点生效。这个节奏里藏着两个常被忽略的事实：其一，信号期足够长，意味着争议解决的主要工具是公开辩论而非链上仓促切换；其二，激活日期在参数公布时即可推算，交易所、钱包与服务商的兼容改造都有明确截止线，集成方应在 STARTED 阶段就排期测试网演练，用部署状态字段核对进度，见 getdeploymentinfo如何看软分叉？。把时间线读成里程碑，比读成立场站队更接近比特币升级的真实运作方式。