比特币 - bips/bip-0012.mediawiki，来自 jl2012/bips

跳至内容

jl2012/ bips Public

forked from bitcoin/bips

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

折叠文件树

文件

vault

搜索此仓库

/

bip-0012.mediawiki

复制路径

Blame更多文件操作

Blame更多文件操作

最新提交

luke-jr

Promote BIP 2 Draft->Active, and implement it

打开提交详情

Nov 30, 2016

959fecc · Nov 30, 2016

历史

历史

打开提交详情

查看此文件的提交历史。

86 lines (54 loc) · 5.86 KB

/

bip-0012.mediawiki

顶部

文件元数据和控制

• 预览

• 代码

• Blame

86 lines (54 loc) · 5.86 KB

Raw

复制原始文件

下载原始文件

大纲

编辑和原始操作

  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

Abstract

Permalink: Abstract

This BIP describes a new opcode (OP_EVAL) for the Bitcoin scripting system，and a new 'standard' transaction type that uses it to enables the receiver of bitcoins to specify the transaction type needed to re-spend them.

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

Motivation

Permalink: Motivation

Enable "end-to-end" secure wallets and payments to fund escrow transactions or other complex transactions in a way that is backwards-compatible for old clients and miners.

以一种对旧客户端和矿工向后兼容的方式，启用“端到端”安全钱包和支付，为托管交易或其他复杂交易提供资金。

Specification

Permalink: Specification

OP_EVAL will re-define the existing OP_NOP1 opcode, and will function as follows:

OP_EVAL将重新定义现有的OP_NOP1操作码，其功能如下：

• When executed during transaction verification, pops the item from the top of the stack, deserializes it, and executes the resulting script. 在交易验证期间执行时，从堆栈顶部弹出项，对其进行反序列化，并执行生成的脚本。
• If there is no item on the top of the stack or the item is not a valid script then transaction validation fails. 如果堆栈顶部没有项，或者该项不是有效的脚本，则交易验证失败。
• If there are any OP_CODESEPARATORs in the deserialized script then transaction validation fails. 如果反序列化的脚本中有任何OP_CODESEPARATOR，则交易验证失败。
• If there are any OP_EVALs in the deserialized script they are also executed, but recursion is limited to a depth of 2. 如果反序列化的脚本中有任何OP_EVAL，它们也会被执行，但是递归被限制为深度为2。
• Transaction verification must fail if interpreting OP_EVAL as a no-op would cause the verification to fail. 如果将OP_EVAL解释为no-op会导致验证失败，则交易验证必须失败。

A new standard transaction type (scriptPubKey) that is relayed by clients and included in mined blocks is also defined:

还定义了一种由客户端中继并包含在已挖掘区块中的新标准交易类型(scriptPubKey)：

    DUP HASH160 {20-byte-hash-value} EQUALVERIFY OP_EVAL

Which is redeemed by a standard scriptSig:

它由一个标准的scriptSig赎回：

    ...signatures... {serialized script}

Transactions that redeem standard OP_EVAL scriptPubKeys are only considered standard if the serialized script is, itself, one of the standard transaction types.

只有当 serialized script 本身是标准交易类型之一时，赎回标准OP_EVAL scriptPubKeys的交易才被认为是标准的。

Rationale

Permalink: Rationale

OP_EVAL allows the receiver of bitcoins to specify how they can be spent when they are spent, instead of requiring the sender of the bitcoins to know the details of how the bitcoins may be redeemed. The sender only needs to know the hash of the serialized script, and one new type of bitcoin address can be used to fund arbitrarily complex transactions.

OP_EVAL允许比特币的接收者指定比特币在被花费时如何被花费，而不是要求比特币的发送者知道比特币可能被赎回的细节。发送者只需要知道 serialized script 的哈希值，并且可以使用一种新型的比特币地址来资助任意复杂的交易。

If serialized script is a large or complicated multi-signature script, then the burden of paying for it (in increased transaction fees due to more signature operations or transaction size) is shifted from the sender to the receiver.

如果 serialized script 是一个大型或复杂的多签名脚本，那么支付它的负担(由于更多的签名操作或交易规模而增加的交易费用)将从发送者转移到接收者。

The main objection to OP_EVAL is that it adds complexity, and complexity is the enemy of security. Also, evaluating data as code has a long record of being a source of security vulnerabilties.

对OP_EVAL的主要反对意见是它增加了复杂性，而复杂性是安全的敌人。此外，将数据评估为代码长期以来一直是安全漏洞的源头。

That same argument can be applied to the existing Bitcoin 'scripting' system; scriptPubKeys are transmit as data across the network and are then interpreted by every bitcoin implementation. OP_EVAL just moves the data that will be interpreted. It is debatable whether or not the entire idea of putting a little interpreted expression evaluation language at the core of Bitcoin was brilliant or stupid, but the existence of OP_EVAL does not make the expression language less secure.

同样的论点可以应用于现有的比特币“脚本”系统; scriptPubKeys作为数据在网络上传输，然后由每个比特币实现来解释。OP_EVAL只是移动将被解释的数据。将一种小的解释型表达式评估语言置于比特币核心地位的整个想法是聪明还是愚蠢，这是值得商榷的，但是OP_EVAL的存在并不会使表达式语言变得不那么安全。

There is a 1-confirmation attack on old clients that interepret OP_EVAL as a no-op, but it is expensive and difficult in practice. The attack is:

对将OP_EVAL解释为no-op的旧客户端存在1确认攻击，但实际上它既昂贵又困难。攻击是：

1. Attacker creates an OP_EVAL transaction that is valid as seen by old clients, but invalid for new clients. 攻击者创建一个OP_EVAL交易，该交易对于旧客户端来说是有效的，但对于新客户端来说是无效的。
2. Attacker also creates a standard transaction that spends the OP_EVAL transaction, and pays the victim. 攻击者还创建一个标准交易，该交易花费OP_EVAL交易，并支付给受害者。
3. Attacker manages to mine a block that contains both transactions. If the victim accepts the 1-confirmation payment, then the attacker wins because both transactions will be invalidated when the rest of the network overwrites the attacker's invalid block. 攻击者设法挖掘一个包含这两个交易的区块。如果受害者接受1确认付款，那么攻击者获胜，因为当网络的其余部分覆盖攻击者的无效区块时，这两个交易都将失效。

The attack is expensive because it requires the attacker create a block that they know will be invalidated. It is difficult because bitcoin businesses should not accept 1-confirmation transactions for higher-value transactions.

这种攻击代价高昂，因为它要求攻击者创建一个他们知道将会失效的区块。这是很困难的，因为比特币业务不应该接受高价值交易的1确认交易。

Backwards Compatibility

Permalink: Backwards Compatibility

Surprisingly, because OP_EVAL redefines the OP_NOP1 opcode, standard OP_EVAL transactions will validate with old clients and miners. They will check only that the serialized script hashes to the correct value; the OP_EVAL will be interpreted as a no-op, and as long as the hash is correct the transaction will be considered valid (no signature checking will be done by old clients and miners).

令人惊讶的是，由于OP_EVAL重新定义了OP_NOP1操作码，标准的OP_EVAL交易将通过旧客户端和矿工的验证。他们只会检查 serialized script 是否散列为正确的值；OP_EVAL将被解释为no-op，并且只要哈希值正确，该交易将被认为是有效的(旧客户端和矿工不会进行签名检查)。

Old clients will ignore OP_EVAL transactions and transactions that depend on them until they are put into a block by either an old miner that includes non-standard transactions in its blocks or by a new miner.

旧客户端将忽略OP_EVAL交易和依赖于它们的交易，直到它们被旧矿工(旧矿工在其区块中包含非标准交易)或新矿工放入区块中。

Avoiding a block-chain split by malicious OP_EVAL transactions requires careful handling of two cases:

要避免恶意OP_EVAL交易造成的区块链分裂，需要谨慎处理两种情况：

1. An OP_EVAL transaction that is invalid for new clients/miners but valid for old clients/miners. 对于新客户端/矿工无效但对于旧客户端/矿工有效的OP_EVAL交易。
2. An OP_EVAL transaction that is valid for new clients/miners but invalid for old clients/miners. 对于新客户端/矿工有效但对于旧客户端/矿工无效的OP_EVAL交易。

For case (1), new clients and miners will be coded to interpret OP_EVAL as a no-op until February 1, 2012. Before then, miners will be asked to put the string "OP_EVAL" in blocks that they produce so that hashing power that supports the new opcode can be gauged. If less than 50% of miners accept the change as of January 15, 2012 the rollout will be postponed until more than 50% of hashing power supports OP_EVAL (the rollout will be rejected if it becomes clear that a majority of hashing power will not be achieved).

对于情况(1)，新客户端和矿工将被编码为将OP_EVAL解释为no-op，直到2012年2月1日。在此之前，将要求矿工将字符串“OP_EVAL”放入他们生成的区块中，以便可以衡量支持新操作码的哈希算力。如果到2012年1月15日，接受此更改的矿工少于50%，则推广将推迟到超过50%的哈希算力支持OP_EVAL为止(如果很明显无法实现多数哈希算力，则将拒绝推广)。

For case (2), new clients and miners will be written to make sure that transactions involving OP_EVAL are valid if OP_EVAL is interpreted as a no-op. Example of a transaction that must fail for both old and new miners/clients:

对于情况(2)，将编写新的客户端和矿工，以确保如果OP_EVAL被解释为no-op，则涉及OP_EVAL的交易是有效的。 新旧矿工/客户端都必须失败的交易示例：

  scriptSig:  {serialized OP_11}
  scriptPubKey:  OP_EVAL OP_11 OP_EQUAL

Reference Implementation

Permalink: Reference Implementation

https://github.com/gavinandresen/bitcoin-git/tree/op_eval

See Also

Permalink: See Also

https://bitcointalk.org/index.php?topic=46538

"Bitcoin Address 01" BIP

M-of-N Multisignature Transactions BIP 11

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