Merge pull request #1523 from vehorny/patch-3

 BIP-12: typo fix 

1 files changed, 2 insertions, 2 deletions

diff --git a/bip-0012.mediawiki b/bip-0012.mediawiki
index 70069d6..bd3d88c 100644
--- a/bip-0012.mediawiki
+++ b/bip-0012.mediawiki
@@ -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.