<blockquote>
  <p>The script is read left to right and is the concatenation of the output of a preceding Transaction to the input of a consuming Transaction</p>
</blockquote>

<p>Basically, though the scripts are not actually concatenated. The scriptSig is run, and then the scriptPubKey is run on the resulting stack. This distinction is occasionally important.</p>

<blockquote>
  <p>A script output can have only one corresponding transaction script that consumes it.</p>
</blockquote>

<p>There are many possible scriptSigs that could "solve" any scriptPubKey, but each output can only be spent once in a valid block chain.</p>

<blockquote>
  <p>but I'm unclear if this means non-standard scripts may never get incorporated into a block</p>
</blockquote>

<p>They can get into blocks, though miners using the standard client will never add them to <em>their</em> blocks.</p>

<blockquote>
  <p>How does the forth like processor know the difference between data on the stack and commands on the stack?</p>
</blockquote>

<p>Data is preceded by bytes 1 through 78, the pushdata ops.</p>

CC BY-SA 3.0
2013-01-01T18:06:14.677Z
Actually, in very old versions of the code, the txin script was concatenated with the txout script (with an OP_CODESEPARATOR between them). This resulted in the OP_RETURN flaw (where the txin script could basically just be "return true"), so it was changed to two separate executions.
Pieter Wuille
CC BY-SA 3.0
2013-01-01T00:54:44.213Z
2013-01-01T00:54:44.213Z
theymos
<p>I'm trying to understand how a script works but am having trouble reading a script (the output of one Tx... and the input of a second Tx) and figuring out how the computer (bitcoin-qt) knows which input in the script is data and which is a command.</p>

<p>Please correct my assumption:</p>

<ul>
<li><p>The script is read left to right and is the concatenation of the output of a preceding Transaction to the input of a consuming Transaction</p></li>
<li><p>A script output can have only one corresponding transaction script that consumes it.</p></li>
<li><p>There are several script commands and several are disabled in the current version of the client</p></li>
<li><p>The script can not rely on outside information (stock ticker) but can rely on an Oracle for these dependencies.</p></li>
<li><p>The script commands that are "commands" require certain data to be on the stack in order to function correctly</p></li>
<li><p>There are "standard scripts" (but I'm unclear if this means non-standard scripts may never get incorporated into a block)</p></li>
<li><p>If the concatenated evaluation of a preceding Tx Output and a subsequent Tx Input evaluates to true, then the transaction is valid.</p></li>
</ul>

<p><strong>Question</strong></p>

<ol>
<li>Can anyone tell me if those thoughts about scripts are correct?  </li>
<li>How does the forth like processor know the difference between data on the stack and commands on the stack?</li>
<li>Does the processor think everything is just data until it hits data that matches a known "function" </li>
</ol>

<transactions><development><script>
How do I read a script? How does the processor separate "data" from "commands"?
makerofthings7
# How do I read a script? How does the processor separate "data" from "commands"?

(Asked by: username_0 on 2012-12-31)

I'm trying to understand how a script works but am having trouble reading a script (the output of one Tx... and the input of a second Tx) and figuring out how the computer (bitcoin-qt) knows which input in the script is data and which is a command.

Please correct my assumption:

* The script is read left to right and is the concatenation of the output of a preceding Transaction to the input of a consuming Transaction
* A script output can have only one corresponding transaction script that consumes it.
* There are several script commands and several are disabled in the current version of the client
* The script can not rely on outside information (stock ticker) but can rely on an Oracle for these dependencies.
* The script commands that are "commands" require certain data to be on the stack in order to function correctly
* There are "standard scripts" (but I'm unclear if this means non-standard scripts may never get incorporated into a block)
* If the concatenated evaluation of a preceding Tx Output and a subsequent Tx Input evaluates to true, then the transaction is valid.

**Question**

1. Can anyone tell me if those thoughts about scripts are correct?
2. How does the forth like processor know the difference between data on the stack and commands on the stack?
3. Does the processor think everything is just data until it hits data that matches a known "function"

**Tags:** transactions, development, script


---

## 1 answers

### Answer by username_1 on 2013-01-01. Score: 5 | Accepted answer

> The script is read left to right and is the concatenation of the output of a preceding Transaction to the input of a consuming Transaction

Basically, though the scripts are not actually concatenated. The scriptSig is run, and then the scriptPubKey is run on the resulting stack. This distinction is occasionally important.

> A script output can have only one corresponding transaction script that consumes it.

There are many possible scriptSigs that could "solve" any scriptPubKey, but each output can only be spent once in a valid block chain.

> but I'm unclear if this means non-standard scripts may never get incorporated into a block

They can get into blocks, though miners using the standard client will never add them to *their* blocks.

> How does the forth like processor know the difference between data on the stack and commands on the stack?

Data is preceded by bytes 1 through 78, the pushdata ops.

> **Comments:**
> **username_2**: Actually, in very old versions of the code, the txin script was concatenated with the txout script (with an OP_CODESEPARATOR between them). This resulted in the OP_RETURN flaw (where the txin script could basically just be "return true"), so it was changed to two separate executions.  

---

