升级案例总结

我们用案例来整理和总结比特币的迭代过程。

负数交易案例

在复杂的比特币升级分析中提到的案例。有问题的交易发生在74638区块，当5个小时之后core团队发现这个问题后，立马发布了新的版本，并尽量告诉大多数节点（矿工、钱包）要从74637区块之后重新开始生成交易和区块。好链努力追赶坏链，最终在出现问题9个小时后，追赶上并超过了坏链（74691高度），坏链就失效了。

修复此问题时，新版本未修改新版本的区块号，所以新节点升级后的区块版本仍然为1，而且对于新版本和旧版本的节点来说，交易结构都没变、交易结构中的内容也没有不熟悉的，所以新版接受旧版交易和区块、旧版接受新版的交易和区块，但是新版不接受旧版的负值交易和区块。

BTC分叉出BCH案例

与在复杂的比特币升级分析文末提到的“非法交易”所描述的是一类事情。即，改变了交易的本身结构。

BTC分叉出BCH案例是在复杂的比特币升级分析（2）文章中提到的。BCH为了做到重放保护，将自己的交易签名类型的结构里，添加了FORK_ID这样的属性，当旧节点校验BCH交易时，发现并不认识FORK_ID这个东西，于是就认为此类交易为非法交易。

什么是重放保护？（复杂的比特币升级分析（2）提到过）

重放的意思是，假如比特币和BCH的代码除了1MB和8MB的区别，其余完全一致，那么比特币和BCH是共用同一套私钥、公钥、地址的。假设张三的地址A里有10个BTC，那么在分叉处BCH后，这个地址也同时拥有10个BCH。这时张三给李四转10个BTC，由于没有重放保护，导致张三的10个BCH也同时转给了李四！（为什么分叉后，会同时拥有10个BCH？这个问题以后的文章会提到。）

这是因为交易发起地址、剩余金额、收币地址、加锁解锁条件等等都是相同的，看起来是两个世界，实际上就类似于两个相同的交易在不同的区块链上同步执行而已。

这就会造成用户不必要的损失。为了解决这个问题，BCH将交易签名修改为与比特币完全不一样的规则：SIGHASH_FORKID。这也就是重放保护。

此案例，是将交易的结构进行了改变，导致旧版收到新版交易或区块时，对新的结构不认识而拒绝；新版在收到旧版交易或区块时，由于缺少了关键的FORK_ID信息而拒绝。最终结果是完全独立的两条链，互相不干扰对方。

ETH和ETC案例

在复杂的比特币升级分析（3）提到的案例，由于ETH从以太坊分叉较早，还没有上述的BTC和BCH的重放保护，导致ETC和ETH两条链的内容几乎完全一样，这就形成了旧兼容新、新兼容旧的现象，这个形式也导致了重放问题。这也就是后来BCH从BTC分叉时知道需要用到重放保护的原因。

此案例连版本号也没变、交易结构也没变，结构中的内容更是没有双方不熟悉的内容，故用户在用ETH发起交易时，用户的ETC资金也会同时被发起交易。因为ETC矿工以为用户要发起ETC支付（数据完全一致导致）。

P2SH案例

在复杂的比特币升级分析（4）提到的案例，是在标准交易类型中，新增了一种标准交易类型，这种标准交易类型为了解决多重签名的锁定脚本冗长的问题。

由于此升级方案，仅仅是添加了一种交易类型，新版本没有改变旧版本的任何交易结构、也没有在结构中添加任何节点不熟悉的内容。这个P2SH标准交易类型里的操作码，也都是旧节点所认识的，因为这些操作码在其它标准交易里都有，比如P2PKH里都有，仅仅是在锁里的内容稍微有些变化，旧节点在收到新节点发来的P2SH区块时，只是发现这种交易类型没见过，但也能验证通过，于是就验证通过区块了。但是对于旧节点收到的P2SH交易来说，一般对此类交易不转发、不验证、不放入区块，所以旧节点对P2SH交易是不接受的，仅接受区块。

综合上述几个案例，我们可以归纳一下比特币的升级方案：

1、如果是针对交易结构做出的修改（BTC BCH案例，增加FORK_ID信息），那么新旧双方都会不承认对方产出的交易和区块，导致分叉出两条链。

2、如果是针对交易结构中的内容做出修改，需要区分以下两种情况：

1）修改后的规则，是旧节点察觉不到的。

可以参考负数交易案例。规则修改后，新节点只要求正数，这个规则在旧节点那里完全察觉不到，因为旧节点正数或负数都支持，新节点发过来的都是正数，是没问题的。

2）修改后的规则，旧节点能察觉到。

可以参考P2SH案例。旧节点会发现交易类型不是标准的，但操作码是熟悉的，可以做验证操作。但由于规则里说明遇到非标准交易，则不验证；遇到非标准交易的区块，需要验证，故旧节点拒绝新交易，接受新区块。

对于“针对交易结构中的内容作出修改”这一方案，也同时需要考虑新版本何时开始不接受旧节点数据。

1）对于新旧版本互相不兼容对方数据的情况，由于在升级之后会立即不接受旧节点数据，故不需要考虑。

2）对于兼容的情况，就比如刚才提到的利用区块版本号以及全网支持数来决定是否拒绝旧节点数据的案例，根据历史阶段不同，制定出的规则不同。

比如，一开始的规则是，使用了新版本的节点，立即拒绝旧版本的数据。后来发现不太好，故有了ISM升级方案，即，如果75%同意则激活但接受旧节点、如果达到95%同意则拒绝旧节点。后来又发现不太好，又有了更好的升级方案：BIP9。

这些优化的升级方案，将在明天的文章中讲解到。

关注【通俗易懂区块链】，学懂区块链