比特币软件升级理念（一)

比特币的设计理念是去中心化。因为去中心化，比特币的软件是开源的，任何人都可以使用

这里

下载最新版本的比特币软件，然后在庞大的比特币网络中安装、运行、参与挖矿，贡献你的计算资源和算力资源，保护比特币网络的安全。当然，现在你几乎是在挖矿。你无法获得奖励，因为有很多矿机专门用于挖矿，大量的矿机已经形成了矿池。个人单独挖矿并没有获得任何收益。可以考虑加入矿池一起挖矿。根据您的计算能力获得您应得的奖励。

随着越来越多的人使用比特币，比特币网络不断扩大，一些软件设计漏洞和一些新的需求出现，比特币需要更新代码以保证比特币网络的安全运行。由于任何人都可以运行比特币软件并维护相同的账本，所以大家在指定的时间点一起升级是理想的，这当然是不可能的，而且会极大地损害比特币网络的安全性。比特币网络中必须有新旧版本（两个以上）的软件一起运行。如何保证比特币软件的升级不会对比特币网络的安全造成致命的破坏比特币用什么软件交易，这是一门很深的学问。

比特币的软件升级分为软分叉和硬分叉两部分。所谓软分叉，是指新版比特币软件向后兼容旧版比特币软件，即旧版比特币软件验证规则下的无效区块和交易在比特币软件旧版验证规则下。新版本的比特币软件。也是无效的；在旧版比特币软件验证规则下有效的区块和交易在新版比特币软件验证规则下可能无效；也就是说，新版本的比特币软件收紧了验证规则，新版本下的有效区块和交易集是旧版本下有效区块和交易的子集。

所谓硬分叉是指在旧版比特币软件验证规则下无效的区块和交易，而交易在新版比特币验证规则下可能有效。

软分叉只需要将大部分比特币网络升级到最新的软件来执行新规则，而硬分叉需要比特币网络的所有参与者升级到最新的软件来执行新规则，否则它将导致比特币区块链的永久分叉。

比特币软件的升级协议经过三个阶段，然后以Bitcoin BIP（Bitcoin Improvement Proposal）的形式给出。

第一阶段：

参考 BIP 16

BIP 16 提案的主题是添加 Pay to Script Hash 交易类型。 P2SH 类型的交易的目的是将提供交易赎回条件的责任从发送者转移到赎回者。好处是它允许发件人使用固定的 20 字节散列支付任何交易，无论多么复杂，这很容易扫描或复制粘贴二维码中的散列。 P2SH的形式如下：

OP_HASH160 [20-byte-hash-value] OP_EQUAL

请注意，[20-byte-hash-value] 前面有一个 0x14 操作码，它将后面的 20 字节哈希值压入堆栈。

兑换脚本格式如下：

...signatures... {serialized script}

在未升级支持 P2SH 新功能的旧版本比特币软件中，当他们收到由支持 BIP 的新版本比特币软件创建的块时，他们只会验证 {序列化脚本} 匹配。 P2SH 中的 20 字节哈希，无需任何其他验证。需要避免出现在新版比特币软件验证规则下无效但对旧版比特币软件有效的情况。为了更优雅地升级，确保不会出现长期的链分叉，超过50%的矿工需要支持P2SH交易类型的验证，需要从旧的验证规则切换到新的规则同时。

为了确定是否有超过 50% 的计算资源支持 BIP 16，矿工需要更新他们的软件并将字符串“/P2SH/”放入他们创建的区块中包含的 coinbase 交易中。

2012年2月1日，新版软件会检查过去7天内支持P2SH交易类型的区块数量。如果超过 550 个区块的 coinbase 交易包含“/P2SH/”，则时间戳为 P2SH 类型的交易包含在 2012 年 2 月 15 日 00:00:00 之后的所有区块中，将在新规则下进行验证。如果大多数计算资源不支持新的验证规则，实施将被延迟（或被拒绝，一旦明确大多数将永远无法升级），结果是 BIP 16 的成功实施。

第二阶段：

参考区块链规则更新流程

我们最近对比特币区块接受规则进行了两项更改（BIP 16 和 BIP 30)；本文记录了规则更改期间的经验教训，并提供了对未来区块链规则更改处理的建议.

经验教训：

如果我能再次实施 BIP 16，知道我现在所知道的一切，我会分 3 个阶段实施 BIP 16 更改：

收紧“IsStandard”规则，以便检查“标准”输入，这将防止旧版本矿工意外交易 invalid-under-new-rules（即在旧版本中有效但在新版本中无效）交易）包含在它们的块中。添加了 n-of-3 CHECKMULTISIG 作为“标准”事务。添加 BIP 16“支付脚本哈希”作为“标准”交易。

可以在相对较快的时间内（1-2 周）进行完全没有争议的更改。

BIP 30（用于解决同一交易带来的问题）是一个完全没有争议的变化示例。

BIP 16 是一个有争议的变化示例。

在采用 BIP 16 期间，一些支持 BIP 16 的矿工未能使用 BIP 16 切换时间更新其从属节点，导致浪费时间在链的一小部分上进行哈希计算。其他用户也遇到此问题，因为他们使用的是尚未更新的旧版软件。

他们很快意识到并修复了他们的错误，但如果更改的切换时间是根据区块链的历史自动确定而不是固定的时间会更好。实现这种方法的代码只需要编写一次，测试一次，然后在以后的升级中重复使用。

在随后对 BIP 12/BIP 16/BIP 17 提案的讨论中，一些人建议新交易应该有一个新的版本号。这是一个好主意，我们核心开发人员应该从提案执行的一开始就考虑到这一点。我们应该使用区块和交易版本号来支持新的交易格式。

对于矿工来说，区块版本号是一种更好的方式来表明他们正在使用的验证规则，并确定是否有大多数人支持新的验证规则（BIP 16 将字符串 "/P2SH" "放入coinbase 交易来判断支持）。

如果旧版本的软件发现区块链中的大多数最新区块都有版本号，它不理解它应该警告用户该软件已过时并且需要更新，但忽略版本号并执行正常的区块和交易验证。

交易版本号是一种更好的方式来指定验证交易是否有效的规则。在中继交易或将其包含在挖掘块中之前，旧版本号的交易将在旧规则下验证，新版本号的交易将在新规则下验证。为了避免在区块链的一小部分分叉中，只有当比特币网络中的大多数节点支持新功能（通过最后 N 个块中的版本）时，具有新版本号的交易才会出现在一个块中。数量待确定）将根据新规则进行验证。

交易的版本号是其散列（即交易 ID）的一部分，也是其签名的散列的一部分，因此攻击者无法更改它。但是，使用新交易功能的软件需要确保交易具有正确的版本号，然后再要求用户签名或告诉用户交易已正确签名。

推荐的升级流程

为了顺利进行未来的升级，需要对比特币核心进行一些修改：

升级场景：

以下概述了如何以最小的风险处理一些未来的升级。

示例：使用抗量子计算的数字签名算法，将 OP_NOP1 重新定义为 OP_Q_CHECKSIGVERIFY。

必须设计操作码，以便交易验证失败，或者它的行为类似于无操作操作。任何其他设计（例如操作码消耗堆栈上的元素，或将数据留在堆栈上）都将允许攻击者伪造在新规则下有效但在旧规则下无效的交易，从而导致区块链分叉。

使用新操作码的交易被赋予一个新的版本号。运行新版本软件的矿工生产具有新版本号的块，因此可以衡量对新功能的支持。新节点将 OP_NOP1 解释为 OP_Q_CHECKSIGVERIFY 当且仅当交易的版本号正确并且最近创建的 1000 个区块中有 75% 具有更新的版本号（测试网上的 51% 就足够了）。

请注意，“75%”规则会自动处理旧区块链中可能包含在新规则下无效交易的部分，并且还会处理支持波动。区块链支持率低于 75% 的部分在旧版规则下验证，超过 75% 的部分在新版规则下验证。在获得明确、一致的支持率之前，用户不应依赖新功能。

示例：增加 MAX_BLOCK_SIZE（区块链的硬分叉）

增加一个区块的最大大小，超过当前的 1M 限制，（也许根据中值大小和一些过去区块之间的相关因子的乘积将其更改为一个），很有可能是未来的升级，因此每个一个区块可以容纳更多的交易。新的最大块大小规则可以实现如下：

新版本的软件创建具有新版本号的块。

如果版本号是新版本号或更高版本，则允许大于 MAX_BLOCK_SIZE 的块，并且最后 1000 个块中的 100% 是新版本号块。 （51% 在测试网上）

最后 1000 个区块的 100% 规则可能是理想的，实际准则可能略有不同（可能区块时间戳在 2015 年 1 月 1 日之后，最后 2000 个区块的 99% 是新版本号），因为这一变化意味着第一个大于 MAX_BLOCK_SIZE 的有效区块会立即将运行旧版本软件的矿工踢出区块链。

译者注：

1. BIP 34 是基于此更新规则的软件升级，该提案有两个动机：

该提案将当前区块高度添加到区块的coinbase交易中比特币用什么软件交易，并将区块的版本号从1升级到2。

这个提议与上面的更新规则略有不同，增加了一个 95% 的规则——“Point of no return”，即如果最后 1000 个区块包含超过 95% 的有 2 个或更多的区块，如果版本号是更高，则所有版本号为 1 的块都会被拒绝。

由于BIP 34没有改变交易验证的规则，所以交易的版本号没有升级，所以交易的版本号还是1。

2. BIP 66 提案使用版本号 3 的区块，BIP 65 提案使用版本号 4 的区块，但请注意交易版本号始终为 1 。译者认为，比特币后续的软分叉升级只是根据区块的版本号，而不是交易的版本号。

3. 由于此升级规则的限制，Bitcoin Core 开发者提出了 BIP 9。

第三阶段，BIP 9，将包含在比特币升级理念 (二).