bip的素材是什么，bip的压缩包是什么

软分叉激活是指比特币节点开始添加一个或多个共识规则的时刻。 这种转换会在节点之间产生协调风险。 因此，多年来，开发人员花费了大量精力创建和升级软分叉激活机制，以最大限度地减少出错的可能性。

软分叉使整个网络能够切换到使用新的共识规则，即使不是每个节点都接受它们。 然而，每当不同的节点使用不同的共识规则时，存在一个块被一些节点接受而被其他节点拒绝的风险（它违反了非一致性规则），导致共识错误（链分裂），最终可能导致资金的多次支付和比特币系统安全信誉的损失。 这是激活机制试图缓解的主要问题。

历史

新的软分叉激活提案经常被提出来避免以前软分叉遇到的问题，因此本节试图总结以前众所周知的软分叉激活尝试。

2009 硬编码高度：启用共识层 nLockTime

已知最早的软分叉是在比特币软件 0.1.6 版（2009 年 11 月发布）中实现的。 它被硬编码为在区块高度为 31,000 时被激活，实际发生时间是 2009 年 11 月 22 日。这种硬编码激活高度的方法在完成大部分开发工作时至少被用于另一个早期的软分叉中本聪。

2011 硬编码时间和人工干预：BIP12OP_EVAL 失败

中本聪离开比特币后，第一个融入比特币的软分叉代码是 BIP12 OP_EVAL。 最初的计划是在支持更改的可用计算能力不足 50% 时使用硬编码时间和人工干预。 引用自 BIP12：

2012 年 2 月 1 日之前，新客户和矿工会将 OP_EVAL 解释为空操作。 在此之前，支持的矿工可以在自己的生产区块中写上“OP_EVAL”字样，这样我们就可以计算出支持的算力比例。 如果到 2012 年 1 月 15 日没有超过 50% 的算力支持更改，将延迟激活，直到超过 50% 的算力支持 OP_EVAL（如果很明显大多数算力不会激活此升级，升级将被取消）。

可能需要人工干预，因为OP_EVAL在合并激活码后上线前被发现存在严重漏洞。 虽然错误已修复，但一些开发人员担心这个强大的新操作码可能存在其他问题，因此人们放弃了软分叉。

2012 硬编码时间和人工干预的另一种尝试：BIP16 P2SH

已经提出了许多简化建议来取代 EVAL 可选协议（参见 BIP13/16、17、18 和 19，以及其他想法）。 大多数开发人员都支持 BIP13/16 Pay to Script Hash (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。 这个错误本身只会导致试图利用它的用户资金遭到破坏，但它也可能与比特币 Merkle 树构造中的一些奇怪行为相结合，从而破坏节点之间的共识（参见 CVE-2012-2459）。 修复该错误的第一个软分支是 BIP30，如果较早的交易仍有未花费的输出，它只是将使用相同 txid 的后续交易标记为无效交易。 这个修复在开发团队中没有争议，所以它在比特币 0.6.0 中用硬编码时间激活，其中包括 P2SH 激活参数。

2012 IsSuperMajority (ISM)：BIP34 coinbase 前缀

虽然 BIP30 解决了由 txid 重叠引起的短期问题，但比特币开发人员知道这是权宜之计。 软件没有理由在每次收到新交易时都搜索所有具有未花费输出的交易的索引。 因此提出了第二个解决方案，旨在消除使 txid 复制成为实际攻击媒介的弱点。 这是 BIP34。 在本次更新中，开发者使用了类似BIP16 P2SH的矿工投票方式，不过这次要做好支持的准备。

持有 EIP34 的矿工需要提高其区块的 nVersion 值。 更重要的是2012购买比特币，开发人员在比特币代码中自动执行新规则，因此他们可以在等待矿工升级的同时发布支持软分叉的软件。 BIP34 的这条规则是通过一个名为 IsSUperMajority() 的函数实现的。 起初，它包含一个单一的激活阈值，当它达到时，BIP34的新共识规则开始实施：

75%规则：如果最新的1000个区块中有75%是vision2或更大，则开始拒绝无效vision 2个区块

在此功能的开发过程中，决定添加第二个激活阈值，该阈值决定性地解决了 BIP34 旨在解决的问题：

95%规则：如果最近的1000个区块中有950个是vision2或更高，则拒绝所有vision 1的区块

拒绝旧版本区块的规则的一个已知问题是，除非所有矿工都已升级，否则每天可能会有几个无效区块（如果恰好有 95% 的矿工激活，则每个区块有 5% 的几率是无效的）。 已升级以执行 ISM 规则的节点将拒绝这些块，但较旧的节点和轻客户端不知道这些规则并将接受它们。 这使得网络比正常情况更依赖于矿工在无效区块后不再继续开采。

ISM 和无验证挖矿：BIP66 严格 DER 激活

2014 年 9 月，Pieter Wuille 发现 OpenSSL 在处理不同平台的 DER 编码签名时存在差异。 例如，这可能会被利用来创建一个块，该块将在 Linux 操作系统上通过验证但在 Windows 操作系统上会失败——攻击者会在该点创建链分裂。 Wuille 和其他几位开发人员秘密开发了这个补丁，并努力将其激活为软分叉，确保所有签名使用相同的格式。 BIP66 就是为此而创建的，被宣传为消除比特币对 OpenSSL 依赖的一步（一个真正的目标，终于在 2019 年实现）。 BIP66在获得用户和开发者的足够支持后（很多人甚至不知道安全漏洞的存在），它使用了与BIP34相同的ISM激活机制，将区块版本号递增到v3，并要求95%的门槛blocks with v2 and lower然后拒绝版本号。

2015 年 7 月 4 日达到 75% 的阈值，在区块高度 363725 达到 95% 的阈值。所有节点都运行 Bitcoin Core v0.10.0 或更高版本的软件（或兼容实现），并执行新规则。 然而，在区块高度 363731 处，未升级的矿工产生了一个不包含当前版本号的区块，根据新的 ISM 激活规则，该区块不是有效区块。 但是其他矿工在这个无效块之后继续生产，最终产生了一条有6个无效块的链。 这意味着未升级的节点和许多轻客户端会将第一个无效区块中的 96 笔交易视为已累积 6 个区块确认的交易，即使他们当时甚至还没有获得有效区块的确认。 确认。 最后，开发者只好联系矿池运营商，让他们手动重启软件，重新回到主链上。 这样的事件在第二天重演，导致一些交易出现了三个无效确认。 幸运的是，这六个和三个区块中的所有常规交易后来都被打包成有效区块，这意味着普通用户没有损失。

高度为 363731 的原始无效块是估计每天发生的大约 5% 的块之一，这些块仅仅因为使用了旧版本号而变得无效。 下一个区块被未升级的矿工挖出的概率也是5%，所以连续两个区块是版本号取消区块的概率是0.25%。 鉴于 95% 的矿工已经升级，连续 6 个区块是版本号无效的区块的概率为 0.000002%——但极度倒霉还不是罪魁祸首。 没有考虑的是，矿工可能会进行“无验证挖矿”，即矿工收到一个新区块后，不经验证继续生产，这样可以提高一点效率。 虽然无验证挖矿软件理论上可以轻松处理无效的区块版本号，但当时开采这五个区块的矿工使用的软件尚未实现此功能。 最终，足够多的矿工升级了他们的无证明挖矿软件，或者升级了他们的节点，与 BIP66 激活相关的意外链分裂消失了。

为了应对导致 2015 年 7 月分叉的这些问题，开发人员加倍努力以减少对无验证挖矿的需求，结果包括 BIP152 压缩块的中继和 FIBER 软件。 开发者也开始思考更好的激活机制，就是后面会提到的BIP9协议。

最后一个 ISM：BIP65OP_CHECKLOCKTIMEVERIFY 已激活

在BIP66严格的DER软分叉之前2012购买比特币，曾提出使用软分叉为比特币添加新的操作码OP_CHECKLOCKTIMEVERIFY(CLTV)，但由于OpenSSL漏洞的修复而被推迟。 这证明了使用增量版本号的 ISM 机制的另一个弱点——矿工发出信号支持最新提案（愿景 n）隐含地支持所有以前的提案（例如愿景 n-1）。 这限制了使用 ISM 同时协调多个升级的能力。

不过，尽管 BIP 66 的激活存在一些问题，但 ISM 再次被用于 BIP65 的延迟激活。 这次没有更多问题了。