Taproot是一项提议的协议升级，它将改善比特币的隐私和灵活性，目前尚处于开发的后期阶段。比特币核心贡献者同意升级将使比特币受益，到目前为止，它似乎也普遍受到更广泛的比特币生态系统的欢迎。因此，Taproot可能会进入比特币核心版本，其他比特币实现也可能随之而来.

但是仍然存在一个问题：比特币网络本身应该如何升级？ Taproot是共识协议的更改，这意味着比特币节点必须以某种方式从旧规则切换到新规则，而又不将网络分成执行不同规则的派系。由于各种原因，在过去有时证明这是一个挑战.

现在正在考虑采用改进的策略来激活协议升级.

以前的软叉和BIP 9

好消息是Taproot将是一个软叉。这种类型的升级会增加或收紧规则，而不是像硬叉那样删除或放松规则。添加或加强规则的好处是，升级节点认为有效的任何内容，未升级节点认为有效的任何东西。 （如果旧节点同时接受事务类型A和B，但新规则仅允许事务类型A，则旧节点将在执行新规则的网络上保持兼容。）

比特币最早的软叉是在卖旗日激活的。开发人员（特别是中本聪）在新的比特币软件客户端版本的代码中嵌入了将来的日期，并指定了升级节点将执行新规则的时间点。鼓励矿工和用户在该日期之前进行升级，以避免网络分裂。 （顺便说一句，在那些日子里，矿工和用户比今天更像是同一个人。）

由于未升级的节点仍与新规则兼容，因此，软分叉的一个方便好处是，如果大多数散列功能强制执行升级，则整个比特币网络都将在其区块链版本上达成共识。这也意味着在实施新协议规则时，迫切需要立即升级所有节点，从而为用户提供了一定的灵活性。 （尽管仍然鼓励用户进行升级；他们最终是通过拒绝交易和破坏交易规则的块来强制执行新规则的用户。）

自2012年左右以来，软叉已越来越多地利用散列功能作为协调机制以协调向新规则的转换。通过在他们的块中嵌入一些数据，矿工可以向其他矿工和网络的其余部分发出信号，告知他们他们已升级软件，从而可以执行新规则。一旦有足够的散列功率信号支持，就会触发所有升级的节点以强制执行新规则.

经过几次升级，该策略演变为比特币改进提案9（BIP 9）。例如，BIP 9是用于激活比特币上次软叉升级的机制，即隔离见证（SegWit）。矿工需要一年的时间来激活升级，要求在任何难度间隔内的95％的区块都包含准备就绪信号位。如果一年后仍未发生，则激活期将到期，升级将失败。 （然后当然可以再次尝试。）

但是，对于SegWit而言，BIP 9的运行并不顺利。与以前的某些升级一样，一些矿工可能由于冷漠而无法进行升级：通常没有很大的动力促使矿工快速升级。但是一个更大的问题是，一些矿工已经将信号处理过程理解为对升级的一种投票，他们会（或不会）发出信号表示对升级的支持，而不是表示已准备就绪。更糟糕的是，一些矿工最终使用此“投票”来阻止升级，以试图在比特币开发过程中获得政治影响力，和/或他们“投票”反对升级，以暗中受益于比特币的怪癖。升级将修复的协议.

经过长时间的激烈争吵，SegWit最终确实激活了，但是只有在替代的比特币客户包括了新的激活方案之后。一些用户运行的BIP 148客户端中包含的BIP 148被编程为仅接受标志日开始支持协议升级的块。同时，BTC 91（包含在btc1客户端中）由矿工在BIP 148卖旗日之前运行，有效地将哈希功率要求从95％降低到75％。面对潜在的分裂网络和可能的收入损失，受阻矿工承认。但是对于大多数比特币核心开发人员来说，BIP 9证明自己是次优的解决方案，他们开始考虑替代方案.

BIP 8

BIP 8 是BIP 9的早期替代方案，由BIP 148作者Shaolinfry and Bitcoin Knots和Bitcoin Core贡献者Luke-jr提出。它最初类似于BIP 9，但是有一个关键的区别：不是在一年没有足够的散列功率支持后升级失败，而是这样做了，并在那个时间点激活了软分叉。类似于卖旗日，所有升级后的节点将从那时起开始执行新规则。仍未能升级的矿工可能会冒险挖掘已升级的矿工和用户拒绝的挖矿区块.

BIP 8背后的主要思想是-当然，假设用户进行了升级-矿工无法阻止软分叉，因此无法利用这一杠杆来谋取利益。他们可以加快激活速度并帮助协调平稳的协议升级，但是即使他们自己不激活升级，升级也最终会发生.

BIP 8的最新草案包括一些显着变化。例如，当信令周期即将到期时，BIP 8允许为节点配置两种不同的策略：如前两段所述，强制激活，或者像BIP 9一样不强制激活。升级本身时，节点（如果已配置）实际上会执行升级信号。然后，拒绝表示不支持升级的块，因此至少在升级后的节点上仍可以保证升级。这两个更改的组合具有一个有趣的特性，即如果所有比特币散列功能中的大多数被迫发出信号表示支持升级，那么即使未配置为强制执行信号发送的BIP 8节点也将随升级一起进行.

反对BIP 8（特别是其强制信号传递（或自动激活））的论点是，它可能具有风险，尤其是在较短的时间范围内。如果多数哈希算力和至少一些用户没有升级，则此方案可能会在升级和未升级节点之间划分网络。假设大多数用户支持升级，则最终可能会偏向于网络的升级部分。但是，未升级的用户在此期间可能会遭受资金损失的风险，而未升级的矿工则会浪费哈希功能，从而损害比特币的安全性.

通过提供足够的升级时间，可以最好地解决这种风险。不幸的是，并不是每个人都同意多少时间就足够了。一些人认为强制信号传输可能在一年内开始，其他人则认为这需要花费几年时间.

BIP 8的另一个复杂功能是为强制信令设置默认值。如果默认情况下关闭了强制信令，则用户可能会发现自己不协调，从而增加了网络分裂的风险。另一方面，如果在比特币核心版本中将强制信令选择为默认，则历史上广泛采用的比特币核心实际上保证了升级将会发生。一些人认为，这会使比特币核心开发人员对比特币的协议规则产生太大的影响。 BIP 8的合著者Luke-jr希望BIP 8仅通过特殊的客户端进行部署，类似于BIP 148客户端.

其他人则认为，Bitcoin Core开发人员始终会根据自己的最佳判断发布软件，同时牢记用户需求并避免有争议的升级。设置BIP 8的默认值也不例外。如果有人不同意比特币核心开发人员的最终选择，他们可以选择不升级到新版本，甚至可以分叉比特币核心代码来完全启动一个竞争客户。.

现代软叉激活

虽然比特币核心开发人员确实试图考虑用户需求并尝试避免有争议的升级，但并非所有人都相信这总是完全可能的。当在新版本中部署软件时，可能只对提议的升级表示担忧。此发行版之后可能会出现全新的问题。也许比特币核心开发人员只是错过了一些东西.

这就是为什么比特币核心贡献者马特·科拉洛（Matt Corallo）提出了一项被称为“现代软叉激活.”现代软叉激活包括三个步骤，从根本上实现了BIP 9（或：不带强制信令的BIP 8）和带标志日激活的BIP 8的组合（尽管也可以选择强制信令）.

第一步，BIP 9将允许矿工通过哈希功能激活软分叉。如果矿工在一年内（例如）未激活它，则第一个激活窗口将过期。然后，作为第二步，开发人员需要花一些时间来分析激活失败的原因，如果确实发现问题，请重新考虑该提议。但是，如果他们发现提案没有问题，那么第三步是重新部署软分支，这次使用带有激活标志日的BIP 8：矿工有另一个机会使用散列功能来激活提案，但是如果他们再次失败，当第二个信令周期结束时，软叉将激活。 （在第二个信令周期内，哈希功率激活阈值也可能会随着时间的推移逐渐降低，比特币核心贡献者AJ Towns 暗示.）

如果事实证明该提案没有错，则明确承诺重新部署BIP 8，Corallo认为该策略将为BIP 9带来好处，而不会带来不利影响。该代码在第一个信号通知期间发布，供大家考虑，如果他们选择，矿工可以协调平稳的升级，并且如果没有激活，开发人员就可以花点时间重新考虑提案（如果激活最初失败了）。同时，矿工将无缘无故地阻止升级，因为每个人都知道最终它将激活.

反对现代软叉激活的主要论点是，如果没有矿工的合作，该过程将花费相对较长的时间，有些人认为BIP 9步骤完全浪费时间。 Corallo最初的提议包括一年的BIP 9信令，然后是六个月的重新考虑，最后是两年的BIP 8信令，然后才自动激活：总共三年半。虽然这个时间表当然还没有定下来，但是缩短不同的步骤太多会减少重新考虑和/或升级的时间（增加网络分裂的风险）.

由于潜在的强迫激活需要很长时间，一些人还认为矿工毕竟可以尝试并获得一些政治影响力：他们可以将升级推迟数年.

BIP 8 + BIP 91

至少在精神上，最近最好的说法是通过比特币的技术渠道流传的另一条建议，可以说是BIP 8与Modern Soft Fork Activation的合并。这份未具名的提案将部署一个较长的BIP 8信令周期，可能要等到Modern Soft Fork Activation的三年半时间，之后才触发强制信令。但是，如果（说）一年后升级仍未激活，那么开发人员将需要一些时间来重新考虑该提案，就像使用Modern Soft Fork Activation一样。.

如果开发人员发现该提案没有问题，而是断定该提案只是由于矿工的冷漠或其他无效原因而没有激活，则他们可以选择部署SegWit期间使用的BIP 91风格的新软分叉。激活。这将有效地降低用于激活的哈希功率阈值，大概可以加快该过程.

另一方面，如果开发人员毕竟会发现该提案有问题，则他们可以部署一个新的软叉来解决该问题，甚至完全撤消原始的软叉（在本例中为Taproot）。假设Modern Soft Fork Activation的时间为三年半，直到被迫发出信号为止，应该有足够的时间来处理此问题.

反对该提议的主要论点可能是，如果需要，部署一个软叉来撤消另一个软叉并不是很好。更具体地说，它要求矿工和用户在截止日期之前升级到新版本，否则就有分裂网络的风险.

por

最后，作为一个离群的想法，比特币核心贡献者杰里米·鲁宾（Jeremy Rubin）提出，他发明了一个称为概率比特币软叉的概念，或“por,”可能比典型的散列功能强制性软叉更具激励兼容性.

鲁宾认为，BIP 9的问题的核心是，矿工可以不花钱就推迟升级。只是简单地拒绝表示已准备好进行升级是免费的，但它可能会为他们提供政治影响力.

使用Sporks，就绪信号不再从矿工开采的区块中包含的少量数据中获取，而是从区块头哈希值中得出：即他们通过投入时间和资源而随机生成的工作量证明。升级后的节点会同意，一小部分有效的块头哈希值（统计上每六个月左右才会发现一次）将触发升级.

根据哈希的随机性，矿工将无法控制他是生成常规块头哈希还是升级激活块头哈希。从统计上讲，他只是偶然地抛弃了后者之一。因此，如果他投入的资源恰巧产生了一个激活升级的块标题哈希，那么他将有两种选择。要么将其发布到比特币网络，获得块奖励，然后激活软分叉。或者，在我们的示例中，由于不发布而将软分叉平均延迟了大约六个月……但是这样做也放弃了块奖励。延迟升级将付出巨大的代价.

目前，Sporks的主要问题可能是这是一个相对较新的想法，尚未得到开发，更不用说在野外进行测试了。尽管有些人确实认为该概念很有趣，但到目前为止，它并不是激活Taproot的最有可能的竞争者.

作者注：关于软叉激活（特别是Taproot激活）的争论不断。这是对不同升级建议的详尽介绍，尤其是涉及具有替代参数和其他调整的建议的变体时，以及它们的所有优缺点.

更新

自从撰写本文以来（大多数情况下），已经吸引了一些注意力的另一个想法是，首先以相对较长的信令周期（例如两年）部署BIP 8，并且在此信令周期的末尾配置为不强制信令。就像过去几次，这使矿工可以相对正常地激活软叉。但是，如果一段时间（例如六个月）后软叉未激活，并且似乎没有延迟的充分理由，则可以释放新的客户端，将其BIP 8配置为强制向该客户端发送信号。现有信令周期的结束或更早。假设大多数矿工然后在此强制信令周期之前或期间激活软叉，则两组BIP 8节点（具有和不具有强制信令配置）都将在激活时强制执行软叉.