bips/bip-0016.mediawiki，位于ajtowns/bips的任意prevout

ajtowns
发布于 2025-05-05 21:30
阅读 14

该BIP (Bitcoin Improvement Proposal) 描述了一种新的比特币脚本交易类型，即“Pay to Script Hash (P2SH)”，并定义了适用于新交易的额外验证规则。P2SH 的目的是将提供交易赎回条件的责任从资金发送者转移到赎回者，允许发送者使用固定长度的 20 字节哈希来资助任何复杂的交易。

[跳至内容](https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0016.mediawiki#start-of-content)

[ajtowns](https://github.com/ajtowns)/ **[bips](https://github.com/ajtowns/bips)** 公开

派生自 [bitcoin/bips](https://github.com/bitcoin/bips)

- [通知](https://github.com/login?return_to=%2Fajtowns%2Fbips) 你必须登录才能更改通知设置
- [Fork\\
3](https://github.com/login?return_to=%2Fajtowns%2Fbips)
- [Star\\
3](https://github.com/login?return_to=%2Fajtowns%2Fbips)

### 折叠文件树

### 文件

bip-anyprevout

搜索此仓库

## bip-0016.mediawiki

复制路径

BlameMore file actions

### 最近提交

[![dergigi](https://img.learnblockchain.cn/2025/07/13/11970334_image.jpg)](https://github.com/dergigi)[dergigi](https://github.com/ajtowns/bips/commits?author=dergigi)

[transaction -> transactions](https://github.com/ajtowns/bips/commit/18f43a6b2a8423850c2cac617fa3053faf420007)

Apr 9, 2019

[18f43a6](https://github.com/ajtowns/bips/commit/18f43a6b2a8423850c2cac617fa3053faf420007) · Apr 9, 2019

### 历史

[历史](https://github.com/ajtowns/bips/commits/bip-anyprevout/bip-0016.mediawiki)

打开提交详情

[查看此文件的提交历史。](https://github.com/ajtowns/bips/commits/bip-anyprevout/bip-0016.mediawiki)

119 行 (71 loc) · 8.64 KB

## bip-0016.mediawiki

顶部

### 文件元数据和控制

- 预览

- 代码

- Blame

119 行 (71 loc) · 8.64 KB

[Raw](https://github.com/ajtowns/bips/raw/refs/heads/bip-anyprevout/bip-0016.mediawiki)

复制原始文件

下载原始文件

轮廓

编辑和原始操作

```
 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

```

| |
| --- |
| ## 目录 [Permalink: 目录](https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0016.mediawiki#table-of-contents) - [摘要](https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0016.mediawiki#user-content-Abstract) - [动机](https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0016.mediawiki#user-content-Motivation) - [规范](https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0016.mediawiki#user-content-Specification) - [原理](https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0016.mediawiki#user-content-Rationale) - [向后兼容性](https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0016.mediawiki#user-content-Backwards_Compatibility) - [序列化脚本大小的 520 字节限制](https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0016.mediawiki#user-content-520byte_limitation_on_serialized_script_size) - [参考实现](https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0016.mediawiki#user-content-Reference_Implementation) - [参见](https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0016.mediawiki#user-content-See_Also) - [参考](https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0016.mediawiki#user-content-References) |

### 摘要

[Permalink: 摘要](https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0016.mediawiki#abstract)

这个BIP描述了比特币脚本系统的一种新的“标准”交易类型，并定义了仅适用于新交易的附加验证规则。

### 动机

[Permalink: 动机](https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0016.mediawiki#motivation)

pay-to-script-hash 的目的是将提供赎回交易的条件的责任从资金的发送者转移到赎回者。

好处是允许发送者使用固定长度的 20 字节哈希来资助任何任意交易，无论多么复杂，该哈希足够短，可以从二维码扫描或轻松复制和粘贴。

### 规范

[Permalink: 规范](https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0016.mediawiki#specification)

定义了一种新的标准交易类型，该类型在中继并包含在已挖掘的区块中：

```
    OP_HASH160 [20-byte-hash-value] OP_EQUAL

```

\[20-byte-hash-value\] 应该是 push-20-bytes-onto-the-stack 操作码 (0x14)，后跟 20 个字节。

可以通过标准 scriptSig 赎回这种新的交易类型：

```
    ...signatures... {serialized script}

```

只有当 **serialized script** （也称为 **redeemScript**）本身是其他标准交易类型之一时，赎回这些 pay-to-script 输出点的交易才被认为是标准的。

在传递交易或考虑将它们包含在新区块中时，验证这些输出点的规则如下：

1. 如果 scriptSig 中有任何“push data”操作以外的操作，则验证失败。
2. 执行常规验证：从签名和 {serialized script} 创建一个初始堆栈，并计算脚本的哈希值，如果它与输出点中的哈希值不匹配，则验证立即失败。
3. 将 {serialized script} 从初始堆栈中弹出，并使用弹出的堆栈和反序列化的脚本作为 scriptPubKey 再次验证交易。

这些新规则仅应在验证时间戳 >= 1333238400（2012 年 4 月 1 日）的区块中的交易时应用 \[ [1](https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0016.mediawiki#cite_note-1)\]。在区块链中，早于 1333238400 的交易未能通过这些新的验证规则。 \[ [2](https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0016.mediawiki#cite_note-2)\]。较早的交易必须在旧规则下进行验证。（有关详细信息，请参阅向后兼容性部分）。

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

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

```

{serialized script} 中的签名操作应计入每个区块允许的最大数量 (20,000)，如下所示：

1. OP\_CHECKSIG 和 OP\_CHECKSIGVERIFY 计为 1 个签名操作，无论是否对其进行评估。
2. 紧随 OP\_1 到 OP\_16 之后的 OP\_CHECKMULTISIG 和 OP\_CHECKMULTISIGVERIFY 计为 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}

```

### 原理

[Permalink: 原理](https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0016.mediawiki#rationale)

此 BIP 取代了 BIP 12，后者提出了一种新的 Script 操作码 ("OP\_EVAL") 来完成此 BIP 中的所有内容以及更多内容。

这个 BIP（和 BIP 13，pay-to-script-hash 地址类型）的动机有些争议；有些人认为这是不必要的，并且复杂/多重签名交易类型应该通过简单地给发送者完整的 {serialized script} 来支持。作者认为，此 BIP 将最大限度地减少对已创建的用于将资金发送到 base58 编码的 20 字节比特币地址的所有支持基础设施所需的更改，从而使商家、交易所和其他软件能够更快地开始支持多重签名交易。

识别一种“特殊”形式的 scriptPubKey 并在检测到它时执行额外的验证是很糟糕的。但是，共识是替代方案要么更糟糕，要么实现起来更复杂，和/或以危险的方式扩展了表达语言的能力。

签名操作计数规则旨在通过静态扫描 {serialized script} 来轻松快速地实现。比特币对每个区块的最大签名操作数有限制，以防止对矿工的拒绝服务攻击。如果没有限制，恶意矿工可能会广播一个需要数十万个 ECDSA 签名操作才能验证的区块，并且它可能能够在网络的其余部分努力验证当前区块的同时抢先一步计算下一个区块。

对旧的实现存在 1 确认攻击，但在实践中成本高昂且困难。攻击是：

1. 攻击者创建一个 pay-to-script-hash 交易，该交易对于旧软件来说是有效的，但对于新实现来说是无效的，并使用它给自己发送一些币。
2. 攻击者还创建一个标准交易，花费 pay-to-script 交易，并支付给运行旧软件的受害者。
3. 攻击者挖掘一个包含两个交易的区块。

如果受害者接受 1 确认付款，那么攻击者获胜，因为当网络的其余部分覆盖攻击者的无效区块时，这两个交易都将失效。

这种攻击代价高昂，因为它要求攻击者创建一个他们知道会被网络其余部分失效的区块。这是很困难的，因为创建区块很困难，并且用户不应接受高价值交易的 1 确认交易。

### 向后兼容性

[Permalink: 向后兼容性](https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0016.mediawiki#backwards-compatibility)

这些交易对于旧的实现来说是非标准的，旧的实现（通常）不会转发它们或将它们包含在区块中。

当旧的实现验证由完全支持此 BIP 的软件创建的区块时，它们将验证 {serialize script} 的哈希值是否匹配，但不会执行其他验证。

通过恶意的 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 字节限制

[Permalink: 序列化脚本大小的 520 字节限制](https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0016.mediawiki#520-byte-limitation-on-serialized-script-size)

由于向后兼容性的要求，序列化脚本本身必须遵守与任何其他 PUSHDATA 操作相同的规则，包括不得将大于 520 字节的数据推送到堆栈的规则。因此，如果它引用的赎回脚本长度 >520 字节，则无法花费 P2SH 输出。例如，虽然 OP\_CHECKMULTISIG 操作码本身最多可以接受 20 个公钥，但使用 33 字节压缩公钥只能花费最多需要 15 个公钥才能赎回的 P2SH 输出：3 字节 + 15 个公钥 \* 34 字节/公钥 = 513 字节。

### 参考实现

[Permalink: 参考实现](https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0016.mediawiki#reference-implementation)

[https://gist.github.com/gavinandresen/3966071](https://gist.github.com/gavinandresen/3966071)

### 参见

[Permalink: 参见](https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0016.mediawiki#see-also)

- [https://bitcointalk.org/index.php?topic=46538](https://bitcointalk.org/index.php?topic=46538)
- [Pay to Script Hash BIP 的地址格式](https://learnblockchain.cn/article/18285)
- M-of-N 多重签名交易 [BIP 11](https://learnblockchain.cn/article/18286)
- [质量保证测试清单](https://learnblockchain.cn/article/18287)

### 参考

[Permalink: 参考](https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0016.mediawiki#references)

1. **[^](https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0016.mediawiki#cite_ref-1-0)** [删除 -bip16 和 -paytoscripthashtime 命令行参数](https://github.com/bitcoin/bitcoin/commit/8f188ece3c82c4cf5d52a3363e7643c23169c0ff)
2. **[^](https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0016.mediawiki#cite_ref-2-0)** [交易 6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192](http://blockexplorer.com/tx/6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192)

>- 原文链接： [github.com/ajtowns/bips/...](https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0016.mediawiki)
>- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

跳至内容

ajtowns/ bips 公开

派生自 bitcoin/bips

通知你必须登录才能更改通知设置
Fork\ 3
Star\ 3

折叠文件树

文件

bip-anyprevout

搜索此仓库

bip-0016.mediawiki

复制路径

BlameMore file actions

历史

打开提交详情

查看此文件的提交历史。

119 行 (71 loc) · 8.64 KB

bip-0016.mediawiki

顶部

文件元数据和控制

预览
代码
Blame

119 行 (71 loc) · 8.64 KB

Raw

复制原始文件

下载原始文件

轮廓

编辑和原始操作

  BIP: 16
  Layer: Consensus (soft fork)
  Title: Pay to Script Hash
  Author: Gavin Andresen &lt;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>- 参考

摘要

Permalink: 摘要

这个BIP描述了比特币脚本系统的一种新的“标准”交易类型，并定义了仅适用于新交易的附加验证规则。

动机

Permalink: 动机

pay-to-script-hash 的目的是将提供赎回交易的条件的责任从资金的发送者转移到赎回者。

好处是允许发送者使用固定长度的 20 字节哈希来资助任何任意交易，无论多么复杂，该哈希足够短，可以从二维码扫描或轻松复制和粘贴。

规范

Permalink: 规范

定义了一种新的标准交易类型，该类型在中继并包含在已挖掘的区块中：

    OP_HASH160 [20-byte-hash-value] OP_EQUAL

[20-byte-hash-value] 应该是 push-20-bytes-onto-the-stack 操作码 (0x14)，后跟 20 个字节。

可以通过标准 scriptSig 赎回这种新的交易类型：

    ...signatures... {serialized script}

只有当 serialized script （也称为 redeemScript）本身是其他标准交易类型之一时，赎回这些 pay-to-script 输出点的交易才被认为是标准的。

在传递交易或考虑将它们包含在新区块中时，验证这些输出点的规则如下：

如果 scriptSig 中有任何“push data”操作以外的操作，则验证失败。
执行常规验证：从签名和 {serialized script} 创建一个初始堆栈，并计算脚本的哈希值，如果它与输出点中的哈希值不匹配，则验证立即失败。
将 {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

{serialized script} 中的签名操作应计入每个区块允许的最大数量 (20,000)，如下所示：

OP_CHECKSIG 和 OP_CHECKSIGVERIFY 计为 1 个签名操作，无论是否对其进行评估。
紧随 OP_1 到 OP_16 之后的 OP_CHECKMULTISIG 和 OP_CHECKMULTISIGVERIFY 计为 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}

原理

Permalink: 原理

此 BIP 取代了 BIP 12，后者提出了一种新的 Script 操作码 ("OP_EVAL") 来完成此 BIP 中的所有内容以及更多内容。

对旧的实现存在 1 确认攻击，但在实践中成本高昂且困难。攻击是：

攻击者创建一个 pay-to-script-hash 交易，该交易对于旧软件来说是有效的，但对于新实现来说是无效的，并使用它给自己发送一些币。
攻击者还创建一个标准交易，花费 pay-to-script 交易，并支付给运行旧软件的受害者。
攻击者挖掘一个包含两个交易的区块。

如果受害者接受 1 确认付款，那么攻击者获胜，因为当网络的其余部分覆盖攻击者的无效区块时，这两个交易都将失效。

向后兼容性

Permalink: 向后兼容性

这些交易对于旧的实现来说是非标准的，旧的实现（通常）不会转发它们或将它们包含在区块中。

当旧的实现验证由完全支持此 BIP 的软件创建的区块时，它们将验证 {serialize script} 的哈希值是否匹配，但不会执行其他验证。

通过恶意的 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 字节限制

Permalink: 序列化脚本大小的 520 字节限制

由于向后兼容性的要求，序列化脚本本身必须遵守与任何其他 PUSHDATA 操作相同的规则，包括不得将大于 520 字节的数据推送到堆栈的规则。因此，如果它引用的赎回脚本长度 >520 字节，则无法花费 P2SH 输出。例如，虽然 OP_CHECKMULTISIG 操作码本身最多可以接受 20 个公钥，但使用 33 字节压缩公钥只能花费最多需要 15 个公钥才能赎回的 P2SH 输出：3 字节 + 15 个公钥 * 34 字节/公钥 = 513 字节。

原文链接： github.com/ajtowns/bips/...

登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

本文参与登链社区写作激励计划，好文好收益，欢迎正在阅读的你也加入。

bips/bip-0016.mediawiki，位于ajtowns/bips的任意prevout

折叠文件树

文件

bip-0016.mediawiki

最近提交

历史

bip-0016.mediawiki

文件元数据和控制

摘要

动机

规范

原理

向后兼容性

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

参考实现

参见

参考

0 条评论

文章目录