比特币 - bips/bip-0017.mediawiki，来自 jl2012/bips
- jl2012
- 发布于 2025-01-20 15:38
- 阅读 20
该BIP (Bitcoin Improvement Proposal) 提议引入一个新的比特币脚本操作码 OP_CHECKHASHVERIFY (CHV)，旨在允许比特币接收者指定重新花费资金所需的交易类型。该提案已撤回，但探讨了通过哈希验证脚本来实现更灵活的交易验证方式。
forked from bitcoin/bips
折叠文件树
文件
vault
搜索此仓库
/
bip-0017.mediawiki
复制路径
BlameMore 文件操作
BlameMore 文件操作
最近提交
Implement BIP 2 with merging master changes
2016年12月14日
3a28003 · 2016年12月14日
历史
打开提交详情
109 行 (65 loc) · 7 KB
/
bip-0017.mediawiki
顶部
文件元数据和控件
-
预览
-
代码
-
Blame
109 行 (65 loc) · 7 KB
复制原始文件
下载原始文件
轮廓
编辑和原始操作
BIP: 17
Layer: Consensus (soft fork)
Title: OP_CHECKHASHVERIFY (CHV)
Author: Luke Dashjr <luke+bip17@dashjr.org>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0017
Status: Withdrawn
Type: Standards Track
Created: 2012-01-18
License: BSD-2-Clause
| ## 目录<br>Permalink: 目录<br>- 摘要<br>- 版权<br>- 动机<br>- 规范<br>- 示例<br>- 原理<br>- 向后兼容性<br>- 参考实现<br>- 参见 |
摘要
此 BIP 描述了比特币脚本系统的一个新操作码 (OP_CHECKHASHVERIFY)，以及一种新的“标准”交易类型，它使用该操作码来使比特币的接收者能够指定重新花费它们所需的交易类型。
版权
该 BIP 在 BSD 2-clause 许可下获得许可。
动机
pay-to-script-hash 的目的是将提供条件以赎回交易的责任从资金的发送者转移到赎回者。
好处是允许发送者资助任何任意交易，无论多么复杂，使用固定长度的 20 字节哈希，该哈希足够短以从二维码扫描或轻松复制和粘贴。
规范
OP_CHECKHASHVERIFY 将重新定义现有的 OP_NOP2 操作码，并在执行时按如下方式运行：
- 首先，哈希先前脚本的末尾（在一般情况下，为 scriptSig；如果没有先前的脚本，则哈希一个空字符串），从最后评估的 OP_CODESEPARATOR 开始（如果不存在 OP_CODESEPARATOR，则从脚本的开头开始）
- 然后，将其与堆栈顶部的项目进行比较（如果没有，脚本会立即失败）
- 如果哈希匹配，则不执行任何操作，继续，就像 OP_NOP 一样；如果它们不匹配，脚本会立即失败。
- 请注意，在哈希匹配的情况下，顶部堆栈项目（正在比较的哈希）不会从堆栈中弹出。 这是为了向后兼容。
只有在区块中验证时间戳在 2012 年 2 月 23 日之后的交易时，才应应用此操作码重新分配（有关详细信息，请参阅向后兼容性部分）。
定义了一种新的标准交易类型，该类型已中继并包含在已挖掘的区块中：
[20-byte-hash-value] OP_CHECKHASHVERIFY OP_DROP
[20-byte-hash-value] 应为 push-20-bytes-onto-the-stack 操作码 (0x14)，后跟正好 20 个字节。
这种新的交易类型通过标准 scriptSig 赎回：
...signatures... OP_CODESEPARATOR {script}
仅当交易包含恰好一个 OP_CODESEPARATOR 并且附加的 script 本身是其他标准交易类型之一时，这些 pay-to-script 输出点 的交易才被视为标准交易。
示例
例如，对于一个签名所需的交易，scriptPubKey 和相应的 scriptSig 为：
scriptSig: [signature] OP_CODESEPARATOR [pubkey] OP_CHECKSIG
scriptPubKey: [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_CHECKHASHVERIFY OP_DROP
2-of-3:
scriptSig: [signatures...] OP_CODESEPARATOR 2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG
scriptPubKey: [20-byte-hash of {2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG} ] OP_CHECKHASHVERIFY OP_DROP
原理
此 BIP 取代了 BIP 12 和 BIP 16，后者建议在验证其哈希后从堆栈中评估脚本。
此 BIP（和 BIP 13，pay-to-script-hash 地址类型）的动机有些争议； 有些人认为这是不必要的，并且应该通过简单地将完整的 序列化脚本 提供给发送者来支持复杂/多重签名交易类型。 作者认为，此 BIP 将最大限度地减少对已创建的用于将资金发送到 base58 编码的 20 字节比特币地址的所有支持基础设施所需的更改，从而使商家、交易所和其他软件能够更快地开始支持多重签名交易。
对旧实现存在 1 次确认攻击，但在实践中成本高昂且困难。 攻击是：
- 攻击者创建一个 pay-to-script-hash 交易，该交易对于旧软件是有效的，但对于新实现是无效的，并使用它向自己发送一些币。
- 攻击者还创建一个花费 pay-to-script 交易的标准交易，并向运行旧软件的受害者付款。
- 攻击者挖掘一个包含两个交易的区块。
如果受害者接受这 1 次确认付款，那么攻击者就会获胜，因为当网络的其余部分覆盖攻击者的无效区块时，这两个交易都将失效。
攻击成本很高，因为它需要攻击者创建一个他们知道会被网络其余部分无效的区块。 这很困难，因为创建区块很困难，并且用户不应接受更高价值交易的 1 次确认交易。
向后兼容性
这些交易对于旧的实现是非标准的，旧的实现（通常）不会中继它们，也不会将它们包含在区块中。
当旧实现验证由完全支持此 BIP 的软件创建的区块时，不会验证 脚本 的哈希值是否匹配。
为了避免由恶意 pay-to-script 交易引起区块链分裂，需要仔细处理一种情况：
- 对于新客户端/矿工无效但对于旧客户端/矿工有效的 pay-to-script-hash 交易。
为了顺利升级并确保不会发生持久的区块链分裂，超过 50% 的矿工必须支持对新交易类型的完整验证，并且必须同时从旧的验证规则切换到新的验证规则。
为了判断是否有超过 50% 的哈希算力支持此 BIP，矿工被要求升级他们的软件，并将字符串“p2sh/CHV”放在他们创建的区块的 coinbase 交易的输入中。
在 2012 年 2 月 8 日，将检查区块链，以确定过去 7 天内支持 pay-to-script-hash 的区块数量。 如果至少 60% 的 coinbase 中包含“p2sh/CHV”，那么所有时间戳在 2012 年 2 月 23 日 00:00:00 GMT 之后的所有区块都将验证其 pay-to-script-hash 交易。
如果大多数哈希算力不支持新的验证规则，那么推出将被推迟（或者如果明确表示永远无法达到多数，则将被拒绝）。
使用 OP_NOP2，因此区块链中现有的 OP_EVAL (BIP 12) 交易仍然可以赎回。
参考实现
参见
- Pay to Script Hash BIP 的地址格式
- M-of-N 多重签名交易 (BIP 11)
- BIP 17 交易链示例: a b c d
- 原文链接： github.com/jl2012/bips/b...
- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
