<p>Explanation by Mike Hearn:
<a href="https://bitcointalk.org/index.php?topic=152470.msg1620493#msg1620493" rel="nofollow">https://bitcointalk.org/index.php?topic=152470.msg1620493#msg1620493</a></p>

<blockquote>
  <p>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.</p>
  
  <p>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:</p>
  
  <p><a href="https://github.com/bitcoin/bitcoin/commit/73aa262647ff9948eaf95e83236ec323347e95d0" rel="nofollow">https://github.com/bitcoin/bitcoin/commit/73aa262647ff9948eaf95e83236ec323347e95d0</a></p>
</blockquote>

<p>...</p>

<blockquote>
  <p>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).</p>
</blockquote>

CC BY-SA 3.0
2014-05-10T00:39:50.710Z
So like the scriptsig "1 1 OP_EQUALVERIFY" could sign and obtain a Tx output?
pinhead
CC BY-SA 3.0
2015-05-14T19:22:00.573Z
I'm a little unclear on how this could lead to someone stealing coins. Could you give an example scriptSig?
Nick ODell
CC BY-SA 3.0
2015-06-14T03:48:29.987Z
@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
CC BY-SA 3.0
2014-05-09T15:47:51.227Z
2014-05-09T15:47:51.227Z
CoinHeavy
<p>Reference: <a href="http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5141">http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5141</a></p>

<p>What was the specific exploit in the Tx script evaluation process?</p>

<bitcoin-core><cve-2010-5141>
What was the vulnerability in v0.3.4 that allowed an attacker to steal coins?
pinhead
# What was the vulnerability in v0.3.4 that allowed an attacker to steal coins?

(Asked by: username_0 on 2014-05-09)

Reference: <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5141>

What was the specific exploit in the Tx script evaluation process?

**Tags:** bitcoin-core, cve-2010-5141


---

## 1 answers

### Answer by username_1 on 2014-05-09. Score: 1

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).

> **Comments:**
> **username_0**: So like the scriptsig "1 1 OP_EQUALVERIFY" could sign and obtain a Tx output?  
> **username_2**: I'm a little unclear on how this could lead to someone stealing coins. Could you give an example scriptSig?  
> **username_3**: @username_2 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.  

---

