比特币改进协议BIP16:Pay to Script Hash(P2SH)

作者:犀牛饲养员

时间:2017年8月25日

来源:CSDN

英文原文地址:

https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki

标题 Pay to Script Hash(P2SH)

备注:P2SH 在2012 年被作为一种新型、强大、且能大大简化复杂交易脚本的交易类型而引入


摘要

此BIP描述了Bitcoin脚本系统的新“标准”交易类型,并定义了仅适用于新交易的其他验证规则。

目的

pay-to-script-hash目的是将提供条件的责任从资金发送者转移到接收方。

好处是允许发送者发起无论多复杂的交易,使用足够短的20字节固定长度的散列来扫描QR码或轻松地复制和粘贴。

详细说明

定义了一个包含在采矿区块中的新标准交易类型:

OP_HASH160 [20-byte-hash-value] OP_EQUAL

[20-byte-hash-value]应为推20字节到堆栈操作码(0x14),后跟20个字节。

这个新的交易类型被标准脚本代码赎回:

signatures... {serialized script}

如果序列化脚本(也称为redeemScript)本身就是其他标准交易类型之一,那么兑换这些pay-to-script outpoints的交易只能被视为标准。

传播交易或将其纳入新区块时对这些outpoints进行验证的规则如下:

  1. 如果scriptSig(解锁脚本)中存在除“push data”以外的任何操作,验证失败。
  2. 正常验证完成:从签名和{序列化脚本}创建初始堆栈,并且计算脚本的哈希值,如果它与outpoint的哈希不匹配,则验证失败。
  3. {serialized script}从初始堆栈弹出,并使用弹出的堆栈和反序列化脚本作为scriptPubKey再次验证交易。

这些新规则只应在使用时间戳=> 1333238400(2012年4月1日)[1]的区块中验证交易时应用。

在区块链中早于1333238400个的交易,应用这些新的验证规则会失败。 [2]。较旧的交易必须根据旧规则进行验证。 (有关详细信息,请参阅向后兼容性部分)。

例如,scriptPubKey和相应的scriptSig用于单签名所需的交易:

scriptSig: [signature] {[pubkey] OP_CHECKSIG}

scriptPubKey: OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL

{序列化脚本}中的签名操作将有助于每个块允许的最大数量(20,000),如下所示:

  1. OP_CHECKSIG和OP_CHECKSIGVERIFY计数为1签名操作,不管它们是否被评估。
  2. OP_CHECKMULTISIG和OP_CHECKMULTISIGVERIFY之前的OP_1到OP_16将被计入1到16签名操作,不管它们是否被评估。
  3. 所有其他OP_CHECKMULTISIG和OP_CHECKMULTISIGVERIFY都被计为20个签名操作。

举例:

+3 签名操作:

{2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG}

+22 签名操作

{OP_CHECKSIG OP_IF OP_CHECKSIGVERIFY OP_ELSE OP_CHECKMULTISIGVERIFY OP_ENDIF}

理论依据

这个BIP替代了BIP 12,它提出了一个新的脚本操作码(“OP_EVAL”)来完成此BIP中的所有操作。

这个BIP的动机(和BIP 13, pay-to-script-hash地址类型)有些争议; 有人觉得这是不必要的,复杂/多重签名的交易类型应该是通过简单地向发送人提供完整的{序列化脚本}来支持的。 作者认为,此BIP已经将改动做到最小,用以将资金发送到base58编码的20字节比特币地址,从而允许商家和交易所及其他软件开始支持多重签名交易。

识别scriptPubKey的一个“特殊”形式,并在检测到时执行额外的验证是丑陋的。 然而,一致认为,替代方案要么越来越复杂,要么以危险的方式扩大表达语言的力量。

签名操作计数规则旨在通过静态扫描{序列化脚本}来简单快速地实现。比特币对每个区块施加最大数的签名操作,以防止对矿工的拒绝服务攻击。如果没有限制,流氓矿工可能会广播一个需要数十万个ECDSA签名操作进行验证的区块,并且可能能够开始计算下一个块,而网络的其余部分工作来验证当前的这个区块。

对旧的实现有 一次确认 的攻击,但在实践中是昂贵和困难的。攻击是:

  1. 攻击者创建一个pay-to-script-hash 交易,这对旧软件是有效的,但对新实现无效,并使用它发送一些比特币。
  2. 攻击者还创建一个pay-to-script 标准交易,并支付运行旧软件的受害者。
  3. 攻击者运算一个包含这两个交易的块。

如果受害者接受1次确认付款,则攻击者获胜,因为当网络的其余部分覆盖攻击者的无效块时,两个交易将被无效。

攻击是昂贵的,因为它要求攻击者创建一个他们知道\将被网络的其它节点确认无效的区块。这是困难的,因为创建区块是的代价是非常高的,用户不应该接受高价值交易的一次确认交易。

向后兼容

这些交易对于旧的实现是非标准的,它们(通常)不会传播它们或将它们包含在区块中。

旧的实现将验证{serialize script}的哈希值在验证由完全支持此BIP的软件创建的区块时匹配,但不会进行其他验证。

为了避免区块链被通过恶意pay-to-script交易分割需要仔细处理一种情况:

一个pay-to-script-hash交易对新客户/矿工无效,但对旧客户/矿工有效。

为了正常升级并确保不会发生持久的区块链分裂,超过50%的矿工必须支持对新交易类型的全面验证,并且必须同时从旧的验证规则切换到新的规则。

为了判断是否有超过50%的散列能力支持此BIP,矿工们被要求升级他们的软件,并将字符串“/ P2SH /”输入到他们创建的区块的coinbase交易中。

2012年2月1日,检查区块链,以确定在过去7天支持pay-to-script-hash的区块数。如果550个或更多的coinbase交易中包含“/ P2SH /”,那么在2012年2月15日00:00:00之后的所有具有时间戳的区块将具有完全验证的pay-to-script-hash交易。一周内创建约1,000个区块;因此,550应该是支持新功能的网络的大约占比55%。

如果大多数散列算力不支持新的验证规则,那么推出将被推迟(或者如果明确表示绝大多数将永远不会实现)。

序列化脚本大小限制在520字节。

作为向后兼容性的要求的结果,序列化脚本本身受到与任何其他PUSHDATA操作相同的规则,包括大于520字节的数据可能被推送到堆栈的规则。因此,如果所引用的兑换脚本长度大于520字节,则不可能花费P2SH输出。例如,当OP_CHECKMULTISIG操作码本身可以接受多达20个pubkey时,使用33字节压缩的公钥,只能花费最多需要15个pubkey的P2SH输出来兑换:3个字节+ 15个pubkeys * 34个字节/ pubkey = 513字节。

参考实现

https://gist.github.com/gavinandresen/3966071

引申阅读

参考

  1. Remove -bip16 and -paytoscripthashtime command-line arguments
  2. Transaction 6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192

相关文章:

发表评论

您的电子邮箱地址不会被公开。