mirror of
https://github.com/bitcoin/bips.git
synced 2024-11-19 01:40:05 +01:00
Update bip-0012.mediawiki
This commit is contained in:
parent
e918b50731
commit
6f288f0f68
@ -43,11 +43,11 @@ OP_EVAL allows the receiver of bitcoins to specify how they can be spent when th
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
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 vulnerabilities.
|
||||
|
||||
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.
|
||||
|
||||
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:
|
||||
There is a 1-confirmation attack on old clients that interpret OP_EVAL as a no-op, but it is expensive and difficult in practice. The attack is:
|
||||
|
||||
# Attacker creates an OP_EVAL transaction that is valid as seen by old clients, but invalid for new clients.
|
||||
# Attacker also creates a standard transaction that spends the OP_EVAL transaction, and pays the victim.
|
||||
|
Loading…
Reference in New Issue
Block a user