bips/bip-0012.mediawiki，位于 ajtowns/bips 的 bip-anyprevout
- ajtowns
- 发布于 2025-02-19 12:17
- 阅读 25
该BIP (Bitcoin Improvement Proposal) 提议引入一个新的操作码 OP_EVAL，旨在允许比特币的接收者指定重新花费这些比特币所需的交易类型，从而实现端到端安全钱包，并支持对旧客户端和矿工具有后向兼容性的复杂交易。
forked from bitcoin/bips
折叠文件树
文件
bip-anyprevout
搜索此仓库
/
bip-0012.mediawiki
复制路径
Blame更多文件操作
Blame更多文件操作
最近提交
打开提交详情
2016年11月30日
959fecc · 2016年11月30日
历史
打开提交详情
86 行 (54 loc) · 5.86 KB
/
bip-0012.mediawiki
顶部
文件元数据和控件
-
预览
-
代码
-
Blame
86 行 (54 loc) · 5.86 KB
复制原始文件
下载原始文件
大纲
编辑和原始操作
BIP: 12
Layer: Consensus (soft fork)
Title: OP_EVAL
Author: Gavin Andresen <gavinandresen@gmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0012
Status: Withdrawn
Type: Standards Track
Created: 2011-10-18
| ## 目录<br>Permalink: 目录<br>- 摘要<br>- 动机<br>- 规范<br>- 原理<br>- 向后兼容性<br>- 参考实现<br>- 参见 |
摘要
这个 BIP 描述了一个新的操作码 (OP_EVAL)，用于 比特币脚本系统，以及一个新的 '标准' 交易类型，它使用该操作码使比特币的接收者能够指定重新花费比特币所需的交易类型。
动机
启用“端到端”安全钱包和支付，以资助第三方托管交易或其他复杂交易，这种方式对旧客户端和矿工向后兼容。
规范
OP_EVAL 将重新定义现有的 OP_NOP1 操作码，并将按如下方式运行：
- 在交易验证期间执行时，从堆栈顶部弹出项目，对其进行反序列化，并执行生成的脚本。
- 如果堆栈顶部没有项目，或者项目不是有效的脚本，则交易验证失败。
- 如果反序列化的脚本中有任何 OP_CODESEPARATOR，则交易验证失败。
- 如果反序列化的脚本中有任何 OP_EVAL，它们也会被执行，但递归深度限制为 2。
- 如果将 OP_EVAL 解释为空操作会导致验证失败，则交易验证必须失败。
还定义了一种新的标准交易类型 (scriptPubKey)，它由客户端转发并包含在挖出的区块中：
DUP HASH160 {20-byte-hash-value} EQUALVERIFY OP_EVAL
它由标准 scriptSig 赎回：
...signatures... {serialized script}
只有当 serialized script 本身是标准交易类型之一时，才会认为赎回标准 OP_EVAL scriptPubKey 的交易是标准的。
原理
OP_EVAL 允许比特币的接收者指定在花费比特币时如何花费它们，而不是要求比特币的发送者知道如何赎回比特币的详细信息。发送者只需要知道 serialized script 的哈希值，并且可以使用一种新的比特币地址类型来资助任意复杂的交易。
如果 serialized script 是一个大型或复杂的多重签名脚本，那么支付它的负担（由于更多的签名操作或交易大小而导致的交易费用增加）将从发送者转移到接收者。
对 OP_EVAL 的主要反对意见是它增加了复杂性，而复杂性是安全性的敌人。此外，将数据评估为代码长期以来一直是安全漏洞的来源。
同样的论点也适用于现有的比特币“脚本”系统；scriptPubKey 作为数据在网络上传输，然后由每个比特币实现解释。OP_EVAL 只是移动将被解释的数据。将一种小的解释型表达式评估语言置于比特币核心的想法是聪明还是愚蠢，这是有争议的，但 OP_EVAL 的存在并不会降低表达式语言的安全性。
对将 OP_EVAL 解释为空操作的旧客户端存在 1 次确认攻击，但在实践中成本高昂且困难。攻击是：
- 攻击者创建一个 OP_EVAL 交易，该交易对旧客户端有效，但对新客户端无效。
- 攻击者还创建一个花费 OP_EVAL 交易的标准交易，并向受害者付款。
- 攻击者设法挖掘一个包含这两个交易的区块。如果受害者接受 1 次确认付款，那么攻击者获胜，因为当网络的其余部分覆盖攻击者的无效区块时，这两个交易都将失效。
这种攻击的成本很高，因为它要求攻击者创建一个他们知道会失效的区块。这很困难，因为比特币企业不应接受高价值交易的 1 次确认交易。
向后兼容性
令人惊讶的是，由于 OP_EVAL 重新定义了 OP_NOP1 操作码，因此标准 OP_EVAL 交易将通过旧客户端和矿工的验证。他们将仅检查 serialized script 是否哈希到正确的值；OP_EVAL 将被解释为空操作，并且只要哈希值正确，该交易将被认为是有效的（旧客户端和矿工将不进行签名检查）。
旧客户端将忽略 OP_EVAL 交易和依赖于它们的交易，直到旧矿工将非标准交易包含在其区块中或新矿工将其放入区块中。
避免恶意 OP_EVAL 交易造成的区块链分裂需要谨慎处理两种情况：
- 对于新客户端/矿工无效但对于旧客户端/矿工有效的 OP_EVAL 交易。
- 对于新客户端/矿工有效但对于旧客户端/矿工无效的 OP_EVAL 交易。
对于情况 (1)，新的客户端和矿工将被编码为将 OP_EVAL 解释为空操作，直到 2012 年 2 月 1 日。在此之前，将要求矿工将字符串“OP_EVAL”放入他们生成的区块中，以便可以衡量支持新操作码的算力。如果截至 2012 年 1 月 15 日少于 50% 的矿工接受更改，则推广将推迟到超过 50% 的算力支持 OP_EVAL 为止（如果明确表明大多数算力将无法实现，则推广将被拒绝）。
对于情况 (2)，将编写新的客户端和矿工来确保涉及 OP_EVAL 的交易在 OP_EVAL 被解释为空操作时有效。 新旧矿工/客户端都必须失败的交易示例：
scriptSig: {serialized OP_11}
scriptPubKey: OP_EVAL OP_11 OP_EQUAL
参考实现
https://github.com/gavinandresen/bitcoin-git/tree/op_eval
参见
https://bitcointalk.org/index.php?topic=46538
"Bitcoin Address 01" BIP
M-of-N 多重签名交易 BIP 11
- 原文链接： github.com/ajtowns/bips/...
- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
