在 vault · jl2012/bips 中的 bips/bip-0016.mediawiki
- jl2012
- 发布于 2025-02-20 21:32
- 阅读 23
该BIP (Bitcoin Improvement Proposal) 描述了一种新的比特币脚本系统中的“标准”交易类型，并定义了仅适用于新交易的额外验证规则。 Pay-to-script-hash (P2SH) 的目的是将提供赎回交易的条件责任从资金发送者转移到赎回者，允许发送者使用固定长度的 20 字节哈希来资助任何任意交易，无论多么复杂。
forked from bitcoin/bips
折叠文件树
文件
vault
搜索此仓库
/
bip-0016.mediawiki
复制路径
BlameMore file actions
BlameMore file actions
最近一次提交
Promote BIP 2 Draft->Active, and implement it
打开提交详情
2016年11月30日
959fecc · 2016年11月30日
历史
打开提交详情
119 行 (71 loc) · 8.64 KB
/
bip-0016.mediawiki
顶部
文件元数据和控制
-
预览
-
代码
-
Blame
119 行 (71 loc) · 8.64 KB
复制原始文件
下载原始文件
大纲
编辑和原始操作
BIP: 16
Layer: Consensus (soft fork)
Title: Pay to Script Hash
Author: Gavin Andresen <gavinandresen@gmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0016
Status: Final
Type: Standards Track
Created: 2012-01-03
| ## 目录<br>Permalink: 目录<br>- 摘要<br>- 动机<br>- 规范<br>- 原理<br>- 向后兼容性 <br> - 序列化脚本大小的 520 字节限制<br>- 参考实现<br>- 参见<br>- 参考文献 |
摘要
此 BIP 描述了比特币脚本系统的一种新的“标准”交易类型，并定义了仅适用于新交易的附加验证规则。
动机
pay-to-script-hash 的目的是将提供条件以赎回交易的责任从资金的发送者转移到赎回者。
这样做的好处是允许发送者使用固定长度的 20 字节哈希来资助任何任意交易，无论它有多复杂，该哈希足够短，可以从 QR 码扫描或轻松复制和粘贴。
规范
定义了一种新的标准交易类型，该类型会被中继并包含在已挖掘的区块中：
OP_HASH160 [20-byte-hash-value] OP_EQUAL
[20-byte-hash-value] 应为 push-20-bytes-onto-the-stack 操作码 (0x14) 后跟正好 20 个字节。
这种新的交易类型通过一个标准 scriptSig 来赎回：
...signatures... {serialized script}
只有当序列化脚本（也称为redeemScript）本身是其他标准交易类型之一时，赎回这些 pay-to-script 输出的交易才被认为是标准的。
在传递交易或考虑将它们包含在新区块中时，验证这些输出点的规则如下：
- 如果 scriptSig 中有任何操作不是“push data”操作，则验证失败。
- 完成正常的验证：从签名和{序列化脚本}创建一个初始堆栈，并计算脚本的哈希值，如果它与输出点中的哈希值不匹配，则验证立即失败。
- 将{序列化脚本}从初始堆栈中弹出，并使用弹出的堆栈和反序列化的脚本作为 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，后者提出了一个新的 Script 操作码 ("OP_EVAL") 来完成此 BIP 中的所有内容以及更多内容。
此 BIP（以及 BIP 13，即 pay-to-script-hash 地址类型）的动机有些争议；一些人认为这是不必要的，并且应该通过简单地给发送者完整的 {序列化脚本} 来支持复杂/多重签名交易类型。作者认为，此 BIP 将最大限度地减少对所有现有支持基础设施的更改，这些基础设施已经创建用于将资金发送到 base58 编码的 20 字节比特币地址，从而使商家、交易所和其他软件能够更快地开始支持多重签名交易。
识别一种“特殊”形式的 scriptPubKey 并在检测到它时执行额外的验证是很糟糕的。但是，共识是替代方案要么更难看，要么实现起来更复杂，和/或以危险的方式扩展表达语言的能力。
签名操作计数规则旨在通过静态扫描 {序列化脚本} 来轻松快速地实现。比特币对每个区块的最大签名操作数施加了限制，以防止对矿工发起拒绝服务攻击。如果没有限制，恶意矿工可能会广播一个需要数十万个 ECDSA 签名操作才能验证的区块，并且它可能能够在网络的其余部分努力验证当前区块时抢先一步计算下一个区块。
对旧的实现存在 1 确认攻击，但在实践中成本高昂且困难。攻击是：
- 攻击者创建一个 pay-to-script-hash 交易，该交易对于旧软件来说是有效的，但对于新实现来说是无效的，并使用它给自己发送一些币。
- 攻击者还创建一个标准交易，该交易花费 pay-to-script 交易，并支付给正在运行旧软件的受害者。
- 攻击者挖掘一个包含这两个交易的区块。
如果受害者接受了 1 确认付款，那么攻击者获胜，因为当网络的其余部分覆盖攻击者的无效区块时，这两个交易都将失效。
这种攻击成本高昂，因为它要求攻击者创建一个他们知道会被网络其余部分失效的区块。这很困难，因为创建区块很困难，并且用户不应接受价值较高的交易的 1 确认交易。
向后兼容性
这些交易对于旧的实现来说是非标准的，它们（通常）不会传递它们或将它们包含在区块中。
当旧的实现验证由完全支持此 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 GMT 之后的所有区块都应对其 pay-to-script-hash 交易进行完全验证。大约每周创建 1,000 个区块；因此，550 个区块应该大约是支持新功能的网络的 55%。
如果大多数哈希算力不支持新的验证规则，那么推出将被推迟（或者如果很明显永远无法实现多数，则将被拒绝）。
序列化脚本大小的 520 字节限制
由于向后兼容性的要求，序列化脚本本身也受到与任何其他 PUSHDATA 操作相同的规则的约束，包括不得将大于 520 字节的数据推送到堆栈的规则。因此，如果它引用的赎回脚本的长度 >520 字节，则无法花费 P2SH 输出。例如，虽然 OP_CHECKMULTISIG 操作码本身最多可以接受 20 个公钥，但使用 33 字节压缩公钥，只能花费最多需要 15 个公钥才能赎回的 P2SH 输出：3 字节 + 15 个公钥 * 34 字节/公钥 = 513 字节。
参考实现
https://gist.github.com/gavinandresen/3966071
参见
- https://bitcointalk.org/index.php?topic=46538
- Pay to Script Hash BIP 的地址格式
- M-of-N 多重签名交易 BIP 11
- 质量保证测试清单
参考文献
- ^ Remove -bip16 and -paytoscripthashtime command-line arguments
- ^ Transaction 6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192
- 原文链接： github.com/jl2012/bips/b...
- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
