【比特币】BIP-0009 软叉标准bip-0009

switch (GetStateForBlock(GetAncestorAtHeight(block, block.height - 2016))) {

“`

实现应该注意的是，状态是沿着块链分支来维护的，但是当重组发生时可能需要重新计算。

鉴于特定块/部署组合的状态在当前重定目标周期之前完全由其祖先确定（即，直到并包括其高度为block.height - 1 - （block.height％2016）的祖先），这是可能的 通过缓存由父节点索引的每个2016年的每个块的结果状态，来有效和安全地实现上述机制。

为了支持升级警告，使用“隐式位”mask =（block.nVersion＆〜expectedVersion）！= 0来跟踪额外的“未知升级”。只要在nVersion中设置了一个意外的位，掩码将不为零。 当检测到未知升级的LOCKED_IN时，软件应该大声警告即将到来的软叉。 在下一个重新定位期间（当未知升级处于ACTIVE状态）时，应该更加警惕。

模板请求对象扩展为包含一个新项目：

| Key | 必须 | 类型 | 描述 |

| ——– | —–: | :—-: | :—-: |

| rules | No | Array of Strings | 按名称列出受支持的软件配置 |

模板对象也被扩展：

| rules | Yes | Array of Strings | 按名称列出受支持的软件配置 |

| vbavailable | Yes | Object |一组待处理，支持的软件部署; 每个使用软匙名称作为关键字，软匙位作为其值|

| vbrequired | No | Number | 软件包部署版本位的位掩码服务器需要在提交中启用 |

模板的“版本”键被保留，用于指示服务器对部署的偏好。 如果使用版本比特，“version”必须在[0x20000000 … 0x3FFFFFFF]的版本范围内。 矿工可以清除或设置块版本中的位，不带任何特殊的“可变”键，只要它们列在模板的“vbavailable”中，并且（当需要清除时）不包括在“vbrequired”中。

“规则”中列出的软键盘部署名称或“vbavailable”中的键可能会以“！”为前缀 字符。 没有这个前缀，GBT客户端可以假定规则不会影响模板的使用; 典型的例子是先前有效的交易将不再有效，例如BIP 16,65,66,68,112和113.如果客户端不了解没有前缀的规则，则它可以未修改地用于挖掘。 另一方面，当使用该前缀时，它表示对块结构或生成事务的更微妙的改变; 这样做的例子是BIP 34（因为它修改了硬币基础结构）和141（因为它修改了txid哈希，并增加了对代的交易的承诺）。 不明白以’！’为前缀的规则的客户端 不得尝试处理模板，也不得尝试将其用于未修改的挖掘。

上述机制是非常通用的，并且对于未来的软叉可以进行变化。 以下是可以考虑的一些想法。

修改的门槛 1916年的门槛（基于BIP 34的95％）不需要维护永久，但更改应该对警告系统有影响。 特别地，具有与用于警告系统的锁定阈值不相容的锁定阈值可能具有长期影响，因为警告系统不再依赖于永久可检测的状态。

冲击软叉 在某些时候，可以提出两个相互排斥的软叉。 处理这种情况的天真的方法是永远不会创建实现两者的软件，但这是打赌，至少有一方保证失去。 更好的是编码“软叉X不能被锁定”作为冲突的软叉的一致规则 - 允许支持两者但不能触发冲突变化的软件。

多级软叉 现在的软叉通常被视为布尔：它们从一个非活动状态到一个活动状态。 也许在某些时候，需要一个具有更多阶段的变化，附加的验证规则逐个启用。 上述机制可以通过将位的组合解释为整数而不是隔离位来适应这一点。 警告系统与此兼容，因为（nVersion＆〜nExpectedVersion）将始终为非零以增加整数。

故障超时允许最终重用位，即使软叉从未被激活，因此很明显，该位的新用法指的是新的BIP。 考虑到合理的开发和部署延迟，故意非常细分。 不太可能有足够的失败的建议造成短缺。

在软叉尝试结束时的休闲时间允许检测到错误的客户端，并允许为成功的软叉提供警告和软件升级的时间。

这里可以找到有关部署建议的生活清单。

本文档位于公共领域。