<p>I ran across a comment from Mike Hearn in the context of the old OP_RETURN bug that seemed insightful:</p>

<blockquote>
  <p>The scripting system always struck me as a rather late addition to the
  design. Satoshi admitted as much when he said that he added it after
  encountering an explosion of special cases as he designed various types of
  contracts. The fact that there's an obvious bug in CHECKMULTISIG is more
  evidence of this part being a general rush job, along with Satoshis
  willingness to disable much of its functionality later with the IsStandard
  checks. Also the design of CHECKSIG is an obvious retrofit, it would have
  made far more sense to decompose it, and we never found a use case for 99%
  of the opcodes despite having successfully designed (redesigned?) all the
  contract types he ever mentioned.</p>
</blockquote>

<p><a href="http://sourceforge.net/p/bitcoin/mailman/message/30479316/" rel="nofollow">http://sourceforge.net/p/bitcoin/mailman/message/30479316/</a></p>

CC BY-SA 3.0
2014-12-13T00:15:23.970Z
2014-12-13T00:15:23.970Z
Rich Apodaca
<p>Script was in the first version of Bitcoin. Satoshi developed Bitcoin in private before releasing the fully-usable Bitcoin 0.1, and he said very little about his thought-process, so we'll probably never know exactly why many things were done the way they were.</p>

<p>Script had several serious bugs when Bitcoin was first released, and some bugs still exist. It's clear that Satoshi didn't thoroughly test Script before releasing Bitcoin.  And while it contains a lot of complexity, it is still too incomplete for most opcodes to be of any real use. In light of this, it's often speculated that Script was something of an afterthought. Perhaps Satoshi's design originally sent bitcoins only directly to public keys, but when adding support for Bitcoin addresses and thinking about future transaction types, he realized that a scripting language would be useful for forward-compatibility.</p>

<p>A stack-based language is the natural choice here. Script processing is dead simple and very fast: just keep reading opcodes from the script and evaluating them until the script is complete. Each opcode is pretty much self-contained. It's also easy to analyze scripts due to the fact that everything to the right of a certain point in a script can be considered a function. You can know for sure that any scriptPubKey that starts with OP_RETURN will always fail validation, and that any script which ends with <code>&lt;pubKey&gt; OP_CHECKSIG</code> will always require the signature of that public key, regardless of what the rest of the script contains.</p>

<p>This functional aspect of Script was especially important when scripts were still evaluated by directly concatenating the scriptSig and scriptPubKey instead of evaluating them separately as is done today. In theory, you could put anything in the scriptPubKey and be sure that no matter what was in the scriptSig, your scriptPubKey would behave as a function taking an appropriate number of arguments from the stack. However, the opcode OP_RETURN originally just caused the script to end early instead of fail, so you could steal anyone's bitcoins by simply using the scriptSig <code>OP_TRUE OP_RETURN</code>. It was also possible to put a pushdata opcode right at the end of a scriptSig to turn the entire scriptPubKey into a constant (which evaluates to true). Satoshi fixed these bugs by changing the behavior of OP_RETURN to cause the transaction to immediately fail and making it so that scriptSig and scriptPubKey are evaluated in two separate steps.</p>

CC BY-SA 3.0
2014-07-30T04:38:52.257Z
There was another bug with concatenating scriptSig and scriptPubKey. If I place a hex digit 0x19 (not push 'x19', but one-byte script - the length of scriptPubKey) it makes the concatenaded version evaluated to TRUE
amaclin
CC BY-SA 3.0
2014-07-30T19:00:39.840Z
@amaclin I had speculated that this was possible in an earlier version of this answer, but then I thought that there was no way such an obvious attack actually worked, so I took that out. But apparently it does work. I added it back to my answer. Thanks.
theymos
CC BY-SA 3.0
2014-07-31T19:07:17.330Z
Thanks for the detailed answers. Are there any resources that I can read regarding these early bugs in the script?
k kurokawa
CC BY-SA 3.0
2014-07-29T17:26:18.040Z
2014-07-30T18:57:22.857Z
2014-07-30T18:57:22.857Z
theymos
<p>What is the history of the current existing scripting language in Bitcoin? </p>

<p>Satoshi's original whitepaper on Bitcoin makes no mention of a stack based scripting language. So who was the first person to propose this idea and implement it? And why did they decide to choose a stack based language?</p>

<script><history>
History behind the scripting language in Bitcoin?
k kurokawa
# History behind the scripting language in Bitcoin?

(Asked by: username_0 on 2014-07-29)

What is the history of the current existing scripting language in Bitcoin?

Satoshi's original whitepaper on Bitcoin makes no mention of a stack based scripting language. So who was the first person to propose this idea and implement it? And why did they decide to choose a stack based language?

**Tags:** script, history


---

## 2 answers

### Answer by username_2 on 2014-07-29. Score: 23 | Accepted answer

Script was in the first version of Bitcoin. Satoshi developed Bitcoin in private before releasing the fully-usable Bitcoin 0.1, and he said very little about his thought-process, so we'll probably never know exactly why many things were done the way they were.

Script had several serious bugs when Bitcoin was first released, and some bugs still exist. It's clear that Satoshi didn't thoroughly test Script before releasing Bitcoin. And while it contains a lot of complexity, it is still too incomplete for most opcodes to be of any real use. In light of this, it's often speculated that Script was something of an afterthought. Perhaps Satoshi's design originally sent bitcoins only directly to public keys, but when adding support for Bitcoin addresses and thinking about future transaction types, he realized that a scripting language would be useful for forward-compatibility.

A stack-based language is the natural choice here. Script processing is dead simple and very fast: just keep reading opcodes from the script and evaluating them until the script is complete. Each opcode is pretty much self-contained. It's also easy to analyze scripts due to the fact that everything to the right of a certain point in a script can be considered a function. You can know for sure that any scriptPubKey that starts with OP\_RETURN will always fail validation, and that any script which ends with `<pubKey> OP_CHECKSIG` will always require the signature of that public key, regardless of what the rest of the script contains.

This functional aspect of Script was especially important when scripts were still evaluated by directly concatenating the scriptSig and scriptPubKey instead of evaluating them separately as is done today. In theory, you could put anything in the scriptPubKey and be sure that no matter what was in the scriptSig, your scriptPubKey would behave as a function taking an appropriate number of arguments from the stack. However, the opcode OP\_RETURN originally just caused the script to end early instead of fail, so you could steal anyone's bitcoins by simply using the scriptSig `OP_TRUE OP_RETURN`. It was also possible to put a pushdata opcode right at the end of a scriptSig to turn the entire scriptPubKey into a constant (which evaluates to true). Satoshi fixed these bugs by changing the behavior of OP\_RETURN to cause the transaction to immediately fail and making it so that scriptSig and scriptPubKey are evaluated in two separate steps.

> **Comments:**
> **username_3**: There was another bug with concatenating scriptSig and scriptPubKey. If I place a hex digit 0x19 (not push 'x19', but one-byte script - the length of scriptPubKey) it makes the concatenaded version evaluated to TRUE  
> **username_2**: @username_3 I had speculated that this was possible in an earlier version of this answer, but then I thought that there was no way such an obvious attack actually worked, so I took that out. But apparently it does work. I added it back to my answer. Thanks.  
> **username_0**: Thanks for the detailed answers. Are there any resources that I can read regarding these early bugs in the script?  

---

### Answer by username_1 on 2014-12-13. Score: 3

I ran across a comment from Mike Hearn in the context of the old OP\_RETURN bug that seemed insightful:

> The scripting system always struck me as a rather late addition to the
> design. Satoshi admitted as much when he said that he added it after
> encountering an explosion of special cases as he designed various types of
> contracts. The fact that there's an obvious bug in CHECKMULTISIG is more
> evidence of this part being a general rush job, along with Satoshis
> willingness to disable much of its functionality later with the IsStandard
> checks. Also the design of CHECKSIG is an obvious retrofit, it would have
> made far more sense to decompose it, and we never found a use case for 99%
> of the opcodes despite having successfully designed (redesigned?) all the
> contract types he ever mentioned.

<http://sourceforge.net/p/bitcoin/mailman/message/30479316/>


---

