Reference: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5141
What was the specific exploit in the Tx script evaluation process?
Explanation by Mike Hearn: https://bitcointalk.org/index.php?topic=152470.msg1620493#msg1620493
When Bitcoin was first released, it contained two completely fatal bugs that made the entire system worthless. Fortunately, they were found and fixed before Bitcoin actually had any serious value.
The first bug was that scripts were concatenated before being run instead of just using a shared stack. This meant that anyone could write a scriptSig that always evaluated to true and claim anyone elses coins. Fixed here in v0.3.2:
https://github.com/bitcoin/bitcoin/commit/73aa262647ff9948eaf95e83236ec323347e95d0
...
Needless to say, if somebody when this version was first released actually wrote such a scriptSig and stole some coins, that would have caused a chain split between old and new versions. Nobody did because, why bother? I'm not even sure Mt Gox existed back then, iirc that came some months later. Many script opcodes were disabled around this time (which is also a hard-forking change).
-
1So like the scriptsig "1 1 OP_EQUALVERIFY" could sign and obtain a Tx output? – pinhead May 10 '14 at 0:39
-
I'm a little unclear on how this could lead to someone stealing coins. Could you give an example scriptSig? – Nick ODell May 14 '15 at 19:22
-
@NickODell you could do things like push 0x{size of scriptPubKey} and then the execution would basically just involve pushing the serialized scriptPubKey on the stack, which would evaluate to true. Alternatively, a scriptSig of OP_TRUE OP_RETURN used to be able to spend any coins, before op return was changed to mean automatic failure. – morsecoder Jun 14 '15 at 3:48
