bip-anyprevout 项目中的 bips/bip-0017.mediawiki 文件

跳至内容

ajtowns/ bips Public

forked from bitcoin/bips

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

折叠文件树

文件

bip-anyprevout

搜索此仓库

/

bip-0017.mediawiki

复制路径

追溯更多文件操作

追溯更多文件操作

最近提交

luke-jr

Implement BIP 2 with merging master changes

2016年12月14日

3a28003 · 2016年12月14日

历史

历史

打开提交详情

查看此文件的提交历史。

109 行 (65 loc) · 7 KB

/

bip-0017.mediawiki

顶部

文件元数据和控件

• 预览

• 代码

• 追溯

109 行 (65 loc) · 7 KB

Raw

复制原始文件

下载原始文件

大纲

编辑和原始操作

  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

摘要

永久链接: 摘要

此 BIP 描述了比特币脚本系统的一个新的操作码 (OP_CHECKHASHVERIFY)，以及一个新的 “标准” 交易类型，它使用该操作码使比特币的接收者能够指定重新花费它们所需的交易类型。

版权

永久链接: 版权

此 BIP 在 BSD 2-clause 许可下获得许可。

动机

永久链接: 动机

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

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

规范

永久链接: 规范

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}

只有当赎回这些 pay-to-script 输出点的交易包含一个 OP_CODESEPARATOR 并且附加的 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 地址类型) 的动机有些争议；有些人认为这是不必要的，并且应该通过简单地给发送者完整的 {serialized script} 来支持复杂/多重签名交易类型。作者认为，此 BIP 将最大程度地减少对现有基础设施的所有支持基础结构所需的更改，这些基础结构已创建用于将资金发送到 base58 编码的 20 字节比特币地址，从而使商家、交易所和其他软件可以更快地开始支持多重签名交易。

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

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

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

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

向后兼容性

永久链接: 向后兼容性

这些交易对于旧实现是非标准的，旧实现通常不会中继它们或将其包含在区块中。

旧实现不会验证 script 的哈希值是否与他们验证由完全支持此 BIP 的软件创建的区块时匹配。

避免通过恶意 pay-to-script 交易进行区块链拆分需要仔细处理一种情况:

• 对于新客户端/矿工无效但对于旧客户端/矿工有效的 pay-to-script-hash 交易。

为了平稳升级并确保不会发生持久的区块链拆分，超过 50% 的矿工必须支持对新交易类型的完全验证，并且必须同时从旧验证规则切换到新规则。

为了判断是否有超过 50% 的哈希算力支持此 BIP，要求矿工升级其软件，并在他们创建的区块的 coinbase 交易的输入中放入字符串 “p2sh/CHV”。

在 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) 交易仍然可以赎回。

参考实现

永久链接: 参考实现

bitcoind git master 的验证、发送和接收

仅适用于 0.3.19+ 的验证

参见

永久链接: 参见

• 用于支付给脚本哈希 BIP 的地址格式
• M-of-N 多重签名交易 (BIP 11)
• BIP 17 交易链示例: a b c d

• 原文链接： github.com/ajtowns/bips/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～