正文
手动干预可能是有必要的，因为
OP_EVAL
在激活代码合并之后、推出之前，被发现有一个
严重的漏洞
。虽然这个 bug 被
修复
了，一些开发者担心这个强大的新操作码可能会有其它问题，所以人们就放弃了这次软分叉。
[2012] 再次尝试硬编码时间以及手动干预：BIP16 P2SH
人们提出了多个替代
OP_EVAL
的简化提案（见 BIP
13
/
16
、
17
、
18
和
19
，还有
其它想法
）。而 BIP13/16 支付给脚本哈希值（P2SH）
获得了大部分开发者的支持
。P2SH
使用
了 跟 OP_EVAL 一样的激活机制。最初计划的激活时间是 2012 年 3 月 1 日，但到了 2 月 15 开票日，在最后 100 个区块中，只有不到 50% 的矿工表示他们会在 3 月之前执行 BIP16 规则。这
导致
了一个 “相当长的替代链”（链分裂），因为一些仍然在 3 月 1 日实行 BIP16 的 矿工拒绝了来自多数矿工（不实行新规则）的区块。第二次开票日是在几千个区块之后，3 月 15 日；这一次它获得了足够多的支持。所以开发者在 3 月 30 放出了
Bitcoin 0.6.0
，将激活时间设在了 4 月 1 日。
[2012] 硬编码时间：BIP30 拒绝复制 txid
P2SH 的激活完成后，人们发现可能出现多个交易共用同一个 txid 的情况。就其自身而言，这个 bug 只会导致尝试利用这个 bug 的用户的资金被销毁，但它也可以结合比特币的默克尔树构建中的一些奇怪的行为打破节点间的共识（见
CVE-2012-2459
）。第一个修复这个漏洞的软分叉是 BIP30，它简单将使用同一个 txid 的后发交易标记为无效交易，如果前发交易还有没花费的输出的话。这个修复在开发团队中没有争议，因此在包含 P2SH 激活参数的
Bitcoin 0.6.0
中以硬编码时间的方式
激活
。
