- A+
由于软分叉允许未经修改的客户在协商一致的情况下继续运作，“激活”软分叉的机制是通过向矿工发出信号准备：大多数矿工必须同意他们准备并愿意执行新的共识规则。 为了协调他们的行动，有一个信号机制，使他们能够表达他们对共识规则改变的支持。 该机制是在2013年3月激活BIP-34并在2016年7月被BIP-9激活所取代。
BIP-34信号和激活
在BIP-34中的第一个实施使用块版本字段来允许矿工表示准备达成特定的共识规则更改。在BIP-34之前，按照惯例将块版本设定为“1”，而不是以共识方式执行。BIP-34定义了一个共识规则变更，要求将Coinbase交易的coinbase字段（输入）包含块高度。在BIP-34之前，Coinbase可以让矿工选择包含的任意数据。在BIP-34激活之后，有效块必须在Coinbase的开始处包含特定的块高度，并且使用大于或等于“2”的版本号进行标识。
为了标记BIP-34的更改和激活，矿工们将块版本设置为“2”而不是“1”。这没有立即使版本“1”块无效。一旦激活，版本“1”块将变得无效，并且将需要所有版本“2”块以包含Coinbase库中的块高度才能有效。
BIP-34基于1000个块的滚动窗口定义了两步启动机制。矿工将以“2”作为版本号来构建块，从而向BIP-34发出信号。严格来说，由于共识规则尚未被激活，这些区块还没有遵守新的共识规则，即将包含块高度在内的基础交易中纳入统一规则。
共识规则分为两个步骤激活：如果75％（最近1000个块中的750个）标有版本“2”，则版本“2”块必须包含coinbase交易中的块高度，否则被拒绝为无效。 版本“1”块仍然被网络接受，不需要包含块高度。 这个新时期的新旧共识规则共存。当95％（最近1000块中的950）是版本“2”时，版本“1”块不再被视为有效。 版本“2”块只有当它们包含coinbase中的块高度（根据先前阈值）时才有效。 此后，所有块必须符合新的一致性规则，所有有效块必须包含coinbase交易中的块高度。根据BIP-34规则成功发信号和激活后，该机制再次使用两次以激活软分叉：BIP-66标签的严格DER编码通过BIP-34信号通过块版本“3”激活，无效版本“2”块。BIP-65 CHECKLOCKTIMEVERIFY被块版本“4”的BIP-34信号激活，无效版本“3”块。BIP-65激活后，BIP-34的信号和激活机制退出，并用下面描述的BIP-9信号传导机制代替。这个标准在BIP-34 (Block v2, Height in Coinbase)中定义。
BIP-9信号和激活
BIP-34，BIP-66和BIP-65使用的机制成功地激活了三个软分叉。 然而，它又被替换了，因为它有几个限制：通过使用块版本的整数值，一次只能激活一个软分叉，因此需要软分叉提议之间的协调以及对其优先级和排序的协议。此外，由于块版本增加，所以机制并没有提供一种直接的方式来拒绝变更，而是提出一个不同的方法。 如果老客户仍然在运行，他们可能会错误地将信号转换为新的更改，作为以前拒绝的更改的信号。每个新的更改不可逆转地减少可用的供将来更改的块版本。提出BIP-9来克服这些挑战，提高实施未来变化的速度和便利性。BIP-9将块版本解释为bit字段而不是1个整数。因为块版本最初用作整数，因此版本1到4，只有29位可用作位字段。这留下29位，可以独立使用，同时在29个不同的提案上表示准备就绪。BIP-9还设置了信令和激活的最大时间。矿工们不需要永远发出信号。如果提案在TIMEOUT期间（在提案中定义）未激活，则该提案被视为被拒绝。该提议可以使用不同位的信令重新提交，更新激活周期。
此外，在TIMEOUT已经过去并且特征被激活或被拒绝之后，信令位可以被再次用于另一个特征而不会混淆。因此，多达29次更改可以并行发出信号，TIMEOUT后可将这些位“再循环”以提出新的更改。
注意虽然信令位可以重复使用或回收利用，但只要投票期间不重叠，BIP-9的作者就建议仅在必要时重复使用位; 主要是由于旧软件中的bug，可能会发生意外的行为。 总之，我们不应该期望在所有29位都被使用一次之前看到重用。
建议的更改由包含以下字段的数据结构标识：名称用于区分提案的简短描述。 通常，BIP将该提案描述为“bipN”，其中N是BIP编号。位0到28，矿工使用的块版本中的位用于表示此提案的批准。开始时间信号开始的时间（基于中值时间过去或MTP），之后该位的值被解释为提示的信令准备。时间结束该时间（基于MTP），如果尚未达到激活阈值，则认为该更改被拒绝。
与BIP-34不同，BIP-9根据2016块的难度改变目标（retarget）周期，在整个间隔中计数激活信号。 对于每个改变目标期间，如果提案的信号块的总和超过95％（2016中的1916），则该提案将在稍后的改变目标期间激活。BIP-9提供了一个提案状态图，以说明一个提案的各个阶段和转换，如图所示。
一旦它们的参数在比特币软件中被知道（定义），提案将在DEFINED状态下开始。 对于具有MTP的块在开始时间之后，提议状态转换到STARTED。 如果在改变目标期间超过了投票阈值，并且未超过超时，则提案状态转换为LOCKED_IN。 一个改变目标期后，该提案变为活动。
一旦达到这个状态，提案仍然处于活动状态。 如果在达到投票阈值之前超时时间，提案状态将更改为“已故”，表示已拒绝的提案。 REJECTED的建议永远在这个状态。BIP-9首次实施用于激活CHECKSEQUENCEVERIFY和相关BIP（68,112,113）。 名为“csv”的建议在2016年7月成功启动。标准定义在BIP-9 (Version bits with timeout and delay).
