Soft Fork

让我们用 V(old) 标记升级前规则接受的所有块。仅当 V(new) 位于 V(old) 内部时，该更改才是软分叉：新节点将拒绝下一类区块，但符合新规则的区块也将通过旧检查。这个名称代表了有效性规则的兼容性，而不是变更的规模、安全性或社会兼容性。增加旧节点可见的限制或允许以前无效的支出会扩大资金池，通常需要硬分叉。 【比特币开发者指南——共识规则变更】【比特币Optech——软分叉激活】

旧的完整节点可以继续遵循这条链，因为更新的矿工会定期创建它识别的区块。但它不检查添加的条件。如果工作较多的分支违反了新规则，旧节点可以接受它，而更新后的节点会拒绝它。需要新保修的人必须更新自己的验证软件；钱包接受支付的能力、格式兼容性和完全共识验证是不同的事情。 [比特币开发者指南 — 共识规则变更] [BIP 341 — Taproot 部署]

比特币使用多种技术创建了子集。 BIP66 禁止旧规则接受的非严格 DER 签名。 BIP65 和 BIP112 向 NOP 操作码添加了旧解释器认为成功的无所事事的条件。 SegWit 和 Taproot 为见证程序的保留版本赋予了意义，旧节点将其视为任何人都可以使用。同时，设计必须防止规避新控制；因此，SegWit 通过 coinbase 提交见证数据并保留旧的基本区块规则。 [BIP 66 — 严格 DER 签名] [BIP 65 — CHECKLOCKTIMEVERIFY] [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 141 — 隔离见证] [BIP 341 — Taproot 部署]

代码可能早在主网上生效之前就包含不活动的规则。 BIP 和检查的实现不是部署，部署参数不是锁定，锁定只是计划未来的执行，并且只有 ACTIVE 状态才意味着检查给定的块。每个节点根据其自己分支的祖先计算状态。边界处的重组可能会重新计算它，并且具有不同参数的软件可能会开始执行不兼容的规则。 [BIP 9 — 具有超时和延迟的版本位] [比特币核心 — versionbits.cpp]

BIP9 为部署分配名称、位版本、开始时间和超时。原始主网变体评估 2,016 个区块后的周期：在至少 1,916 个信号块（即 95%）之后，它从 STARTED 变为 LOCKED_IN，等待一个周期，然后变为 ACTIVE；否则可能会失败。完整的序列为 DEFINED、STARTED、LOCKED_IN、ACTIVE 和 FAILED。块的状态取决于它的祖先，而不是它自己的nVersion，并且锁定后的信号不再改变结果。 [BIP 9 — 具有超时和延迟的版本位]

版本位指示矿工准备情况并协调过渡；他们不授予矿工对共识的永久所有权。 BIP8 使用高度并通过 lockinontimeout 可以强制在最后一个窗口发送信号。另一方面，BIP148 命令参与节点拒绝非 SegWit 信令块； BIP91 降低了挖矿门槛以应对这种压力。如果节点、算力和经济采用存在差异，强制激活可能会导致链条分裂，因此即使是激活方法也是一种安全妥协。 [BIP 8 — 按高度锁定的版本位] [BIP 148 — 强制激活 SegWit] [BIP 91 — 降低阈值 SegWit MASF] [Bitcoin Optech — 软分叉激活]

BIP16 下的 P2SH 于 2012 年通过 coinbase 信号和时间限制激活。 BIP34 在 coinbase 中使用了区块版本和强制高度阈值。相同的整数过程在 BIP66 中运行严格的 DER，在 BIP65 中运行 CHECKLOCKTIMEVERIFY，但消耗了版本值并且无法进行并发部署。因此，BIP9 引入了独立位。然后，BIP68、BIP112 和 BIP113 在 2016 年以相对锁定时间和 CSV 的形式在高度 419,328 处一起激活。 [BIP 16 — 支付脚本哈希] [BIP 34 — 区块 v2，coinbase 高度] [BIP 65 — CHECKLOCKTIMEVERIFY] [BIP 66 — 严格 DER 签名] [BIP 112 —检查序列验证]

SegWit 于 2017 年 8 月在 481,824 激活。旧节点看到没有见证数据的交易，并认为见证 v0 是任何人都可以花费的；更新了验证见证、新的签名摘要和反延展性规则。 Merkle 承诺在 coinbase 输出中见证数据，防止矿工在不被发现的情况下更改或遗漏数据。重量计费增加了有效容量，而旧节点可见的底层块不超过一兆字节的旧限制。 [BIP 141 — 隔离证人]

BIP341 和 BIP342 通过 Schnorr 签名和 Tapscript 见证程序版本 1 密钥路径和脚本路径支出。旧节点再次将保留的程序视为任何人都可以使用：子集被保留，完整的验证则不然。主网使用了修改后的 BIP9 Speedy Trial，阈值为 2,016 个区块中的 1,815 个区块，即 90%，最低激活高度为 709,632。 Taproot于2021年11月14日在其中激活； Taproot 的规则以及如何激活它们是两个独立的审计问题。 [BIP 341 — Taproot 部署] [BIP 342 — Tapscript] [Bitcoin Core 0.21.1 发行说明 — Taproot 部署]

当 BIP66 于 2015 年 7 月激活时，一些矿工发出了新版本的信号，但没有充分验证他们正在挖掘的父区块。他们扩展了无效区块，并于 7 月 4 日创建了一个包含 6 个区块的无效分支；第二天又发生了一次较短的事件。更新的验证节点拒绝了两个分支。版本号或位是矿工的声明，而不是他本人验证模板、父母和交易的证据。 [BIP 66 — 严格 DER 签名] [Bitcoin.org — 2015 年 7 月 BIP66 链分叉警报]

在 ACTIVE 状态下，无论哈希率份额如何，更新的节点都会拒绝违规块；是否产生永久性的划分取决于分支机构的工作及其经济用途。简单地删除限制将重新启用当前的无效块，因此是一个硬分叉；参数或代码可以在激活前替换为协调发布。运营商验证自己的版本、getdeploymentinfo 或 getblockchaininfo、确切的参数、激活高度和日志。信号图和浏览器标签都无法取代本地验证。 [比特币开发者指南 — 共识规则变更] [比特币核心 — versionbits.cpp] [比特币核心 0.21.1 发行说明 — Taproot 部署]