比特币改进协议BIP16(翻译)
比特币改进协议BIP16(翻译)
英文原文地址:
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进行验证的规则如下：
- 如果scriptSig(解锁脚本)中存在除“push data”以外的任何操作，验证失败。
- 正常验证完成：从签名和{序列化脚本}创建初始堆栈，并且计算脚本的哈希值，如果它与outpoint的哈希不匹配，则验证失败。
- {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），如下所示：
- OP_CHECKSIG和OP_CHECKSIGVERIFY计数为1签名操作，不管它们是否被评估。
- OP_CHECKMULTISIG和OP_CHECKMULTISIGVERIFY之前的OP_1到OP_16将被计入1到16签名操作，不管它们是否被评估。
- 所有其他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签名操作进行验证的区块，并且可能能够开始计算下一个块，而网络的其余部分工作来验证当前的这个区块。
对旧的实现有 一次确认 的攻击，但在实践中是昂贵和困难的。攻击是：
- 攻击者创建一个pay-to-script-hash 交易，这对旧软件是有效的，但对新实现无效，并使用它发送一些比特币。
- 攻击者还创建一个pay-to-script 标准交易，并支付运行旧软件的受害者。
- 攻击者运算一个包含这两个交易的块。
如果受害者接受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
参考
- Remove -bip16 and -paytoscripthashtime command-line arguments
- Transaction 6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192
