首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

复杂的比特币升级分析(4)

前文说到,升级方案还剩最后一种,即“交易验证不通过并且区块验证通过”。

本文来讲解这种方案到底是什么。在讲解这种方案之前,我们需要先回顾一下比特币的交易类型。

在复杂的比特币升级分析(2)文章中我们提到过交易分为几种交易类型:

· 标准交易

· 非法交易

· 非标准交易

标准交易

非法交易

非标准交易

指的是虽然新节点进行了升级,但升级后的所有交易结构并没有改变、也没有添加新的属性,交易验证过程中的操作码也都是旧节点熟悉的。但,锁定脚本并不属于旧节点所认识的标准交易中的任何一种交易类型。但是旧节点确实能验证,因为让它执行的操作都是知道的,只是这个操作流程并不是任何一种标准交易的操作流程。故,旧节点会将此类交易标注为非标准交易。

下面我们来用实际的案例来讲解非标准交易,因为“交易验证不通过并且区块验证通过”这种升级方案,就是采用了“非标准交易”这种交易类型来达到目的的。

P2SH案例

我们目前知道P2SH交易类型是属于标准交易类型了,但是它并不是从2009年一开始就有的,而是在2012年提出的方案,旨在解决多重签名锁定脚本过长导致使用此收币地址进行交易时需要输入很长才能使用的问题。

P2SH的解决方案是将很长的锁定脚本哈希加密成长度为20字节的字符串,并用OP_HASH160、OP_EQUAL等操作码进行上锁。锁的规则是:

OP_HASH160OP_EQUALVERIFY

1)新交易传播给旧矿工

当P2SH交易发送给旧版本矿工时,他发现这种锁定脚本规则并不符合他现在存储的标准交易的任何一种。在旧版本矿工升级此版本前,他所知道的标准交易只有P2PKH、P2PK、MULTISIG。

P2PKH的上锁规则如下

OP_DUPOP_HASH160HASHDATAOP_EQUALVERIFYOP_CHECKSIG

P2PK的上锁规则如下

OP_CHECKSIG

MULTISIG的上锁规则如下

M

...

N OP_CHECKMULTISIG

我们发现,虽然新版本的P2SH规则并不与上述规则一样,但是,是有相同操作码的!P2SH的OP_HASH160操作码、OP_EQUALVERIFY操作码,在P2PKH中都有!

也就是说,虽然旧版本矿工在收到P2SH交易时不知道是P2SH交易,但是操作码是能看懂并且能执行的。

但是,此时旧版本矿工并不执行,因为,大家对于这种能看懂但不属于任何标准交易格式的交易,也就是对于这种非标准交易的处理态度如下:

旧节点对于收到的非标准交易来说,不打包、不转发、不验证。

旧节点对于收到的带有非标准交易的区块来说,验证区块、验证交易,转发区块。

所以,当新交易发给旧矿工时,矿工是不会验证的,也不会放入区块中的。

2)旧交易传播给新矿工

此类版本升级,都会在新版本代码中增加一个特殊处理:如果是旧节点发来的交易或者区块,一律拒绝。这么做是为了保证旧节点能快速升级。

故,当旧节点交易传播给新版本矿工时,新版本矿工时拒绝的。

3)新区块传播给旧矿工

旧版本矿工在收到新版本矿工发来的区块时,如果发现有非标准交易,是不拒绝这个区块的。验证区块的逻辑没有验证交易的逻辑严谨,只需要验证交易签名是否能满足锁定脚本即可。不用确认发起交易的地址所对应的交易类型是否是标准交易类型。

故,旧版本矿工是接受新版本发来的区块的。

4)旧区块传播给新矿工

旧版本矿工生成的区块如果发给新版本矿工,新版本矿工的升级版本中的“特殊处理”会拒绝掉旧版本生成的区块。

综上,2012年的P2SH升级方案,就是“旧版本交易验证不通过但区块验证通过”的方案。

类似这种方案的,还有隔离见证(SegWit)。我们之后会聊到。

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

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180217G0DAIG00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券