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

英文原文地址:

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码或轻松地复制和粘贴。

详细说明

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

[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日）https://gist.github.com/gavinandresen/3966071的区块中验证交易时应用。

在区块链中早于1333238400个的交易，应用这些新的验证规则会失败。 https://bitcointalk.org/index.php?topic=46538。较旧的交易必须根据旧规则进行验证。 （有关详细信息，请参阅向后兼容性部分）。

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

{序列化脚本}中的签名操作将有助于每个块允许的最大数量（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 签名操作:

+22 签名操作

理论依据

这个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

引申阅读

• https://bitcointalk.org/index.php?topic=46538
• The Address format for Pay to Script Hash BIP
• M-of-N Multisignature Transactions BIP 11
• Quality Assurance test checklist

参考

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