<p>transaction <code>ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767</code> from the live blockchain contains a lot of syntactically incorrect txout scripts and is useful as a demonstration:</p>

<p>using pybitcointools:</p>

<pre><code>#!/usr/bin/env python2.7                                                        

from bitcoin import *
tx_hex = fetchtx("ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767")
tx_dict = deserialize(tx_hex)
for (txout_num, txout) in enumerate(tx_dict["outs"]):
    script = txout["script"]
    print "raw txout %d script: %s" % (txout_num, script)
</code></pre>

<p>output:</p>

<pre><code>raw txout 0 script: 01
raw txout 1 script: 0201
raw txout 2 script: 4c
raw txout 3 script: 4c0201
raw txout 4 script: 4d
raw txout 5 script: 4dffff01
raw txout 6 script: 4e
raw txout 7 script: 4effffffff01
</code></pre>

<p>analysing each of these txout scripts:</p>

<pre><code>01 = OP_PUSHDATA0(1)
</code></pre>

<p>this fails because it claims it will push 1 byte onto the stack, but then provides no bytes to push onto the stack</p>

<pre><code>0201 = OP_PUSHDATA0(2) &lt;01&gt;
</code></pre>

<p>this fails because it claims it will push 2 bytes onto the stack, but then only provides 1 byte to push onto the stack</p>

<pre><code>4c = OP_PUSHDATA1(?)
</code></pre>

<p>this fails because it is an incomplete OP_PUSHDATA1 opcode. the <code>4c</code> byte should be followed by another byte specifying the number of data bytes to push onto the stack, however it is not.</p>

<pre><code>4c0201 = OP_PUSHDATA1(2) &lt;01&gt;
</code></pre>

<p>this fails because it claims it will push 2 bytes onto the stack, but then only provides 1 byte to push onto the stack.</p>

<pre><code>etc
</code></pre>

<p>its funny that the output scripts in this particular transaction each have a different syntactically incorrect use of the OP_PUSHDATA commands. its almost as if someone had the same question as this and wanted to test if any syntax checking was implemented on scriptpubkeys. i'm glad they did this because its a very conclusive way to demonstrate that absolutely no syntax checking (and therefore no other checks either) are performed on scriptpubkeys before they are spent.</p>

CC BY-SA 3.0
2015-06-18T06:52:19.880Z
You'll find a lot of scripts like this on testnet3, and a smaller number on the main network. Many of them are attempting (and actually manage in some cases) to break reimplementations using obscure and undocumented behaviors.
Claris
CC BY-SA 3.0
2015-06-18T08:22:37.687Z
yep! it broke [my re-implementation](https://github.com/mulllhausen/btc-inquisitor) - that's the reason i'm asking :) but i don't see a whole lot of value for validating testnet blocks - people can put anything in there and there is not much hashpower to even guarantee valid blocks.
mulllhausen
CC BY-SA 3.0
2015-06-18T08:43:31.730Z
You're never going to download a block with invalid contents, because the block would just simply be invalid. The amount of proof of work for this is almost entirely orthogonal. You really shouldn't be reimplementing script, history has shown (bitcoinjs, bitcoin-ruby, btcd) that nobody has the capability to clone the behavior directly, no matter how many millions of dollars are poured into the effort. Unless this is for fun or experience, link to `libconsensus` and avoid losing piles of money. It's not foolproof, but it means you won't have avoidable mistakes in script execution.
Claris
CC BY-SA 3.0
2015-06-18T12:09:09.330Z
thanks for the warning but for me its purely educational. you never really know something until you can build it yourself from scratch.
mulllhausen
CC BY-SA 3.0
2015-06-18T12:21:40.363Z
i didn't know about `libconsensus` - that looks really useful!
mulllhausen
CC BY-SA 3.0
2015-06-18T18:23:25.180Z
For a learning experience go right ahead reimplementing. Somewhat unexpectedly, that's how some consensus bugs have been found in the past. The warning was mostly born of people reimplementing and then running million dollar companies on top of it without really acknowledging the risk.
Claris
CC BY-SA 3.0
2015-06-20T01:44:53.580Z
cool. yeah that's another reason for my re-implementation. so far i have always been late to the party - discovering ["bugs"](https://github.com/mulllhausen/btc-inquisitor/blob/master/btc_grunt.py#L1082-L1087) well after they have been fixed [by bips](https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki)
mulllhausen
CC BY-SA 3.0
2015-06-17T16:16:00.480Z
2015-06-17T23:26:08.650Z
2015-06-17T23:26:08.650Z
mulllhausen
<p>Absolutely no <em>consensus</em> validity checks are done on a <code>scriptPubKey</code>. Nodes have soft requirements called IsStandard for what they will relay to their peers as a transaction (a completely junk script or very large OP_RETURN output for example will not pass) but these are not consensus rules. Some miners will mine non-standard transactions into their blocks, but generally to get a transaction to them a transport other than the P2P network needs to be used. </p>

<p><code>OP_RETURN</code> is a special case refereed to as "provably un-spendable", this is a response to people jamming hashes and other data into <code>PubKeyHash</code> outputs as a way of pegging them in time to the block chain. Due to there being no way of knowing if the output is actually valid or not these outputs must be stored forever in the UTXO pool. An <code>OP_RETURN</code> prefixed output can absolutely never be spent, so nodes can safely forget that they ever existed. </p>

CC BY-SA 3.0
2015-06-16T11:05:56.187Z
thanks for the reply! but surely if someone builds a block with a syntactically incorrect txout script then no other miners will build on top of it? i'm looking for that criteria - ie for building on top of an already mined block
mulllhausen
CC BY-SA 3.0
2015-06-16T11:08:27.703Z
i have added a last paragraph to the op explaining a bit better...
mulllhausen
CC BY-SA 3.0
2015-06-16T11:11:35.030Z
The output script is never verified in Bitcoin, you can make something that is complete junk (`OP_CAT OP_CAT OP_CAT`) and that is valid in a block. If there is no way to satisfy the script and spend it again, then the value of the BTC there is simply stuck there forever. This transaction output is similar to your example, it pushes junk onto the stack for no reason. http://webbtc.com/tx/09ca982b6ab313cd7552b9a28e1dabdd37cab5e6ed05bb241579902c5f1e8989 Bonus points if you can work out what it is pushing onto the stack.
Claris
CC BY-SA 3.0
2015-06-16T11:16:24.790Z
hmm interesting. i'm guessing it is still syntactically correct though? eg `05aa` would fail? if not then it might be possible to use txout scripts for buffer overflow attacks on users...
mulllhausen
CC BY-SA 3.0
2015-06-16T11:23:16.280Z
i know they cant be used in `EvalScript()` - that's not my question.
mulllhausen
CC BY-SA 3.0
2015-06-17T06:06:11.533Z
No checks at all, not even on the size of data pushes. It's an array of bytes.
Claris
CC BY-SA 3.0
2015-06-17T08:08:36.350Z
cool. apparently [this transaction](http://blockexplorer.com/rawtx/ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767) does exactly that. i need to have a look at the raw hex but once i have confirmed this i will add it into your answer and mark it as the solution. feel free to get there before me :)
mulllhausen
CC BY-SA 3.0
2015-06-18T03:01:38.777Z
i created a new answer, since the results turned out to be more interesting than i thought!
mulllhausen
CC BY-SA 3.0
2015-06-16T11:03:26.663Z
2015-06-16T11:06:15.117Z
2015-06-16T11:06:15.117Z
Claris
<p>what is the criteria for a txout script to be accepted into a mined block? is there any criteria at all? the reason i ask is that <a href="https://github.com/bitcoin/bitcoin/blob/e5f1f5a26399c7d36fa8e2c29ec411eea49b0a4c/src/script/interpreter.cpp#L397-L400" rel="nofollow"><code>OP_RETURN</code></a> is regularly used in txout scripts yet it is not spendable:</p>

<pre><code>case OP_RETURN:
{
    return set_error(serror, SCRIPT_ERR_OP_RETURN);
}
</code></pre>

<p>and i have also <a href="http://blockexplorer.com/tx/77822fd6663c665104119cb7635352756dfc50da76a92d417ec1a12c518fad69" rel="nofollow">seen transactions</a> which push elements to the stack which are more than <a href="https://github.com/bitcoin/bitcoin/blob/v0.10.0rc3/src/script/script.h#L18" rel="nofollow">MAX_SCRIPT_ELEMENT_SIZE</a> bytes.</p>

<p>i'm guessing that a syntactically incorrect script such as:</p>

<pre><code>05aa
(ie OP_PUSHDATA(5) &lt;aa&gt;)
</code></pre>

<p>would not be permitted?</p>

<p>could someone point me to the code which miners use to validate whether a tx will be included or discarded as invalid (due to its txout scripts). i'm guessing it lies in <a href="https://github.com/bitcoin/bitcoin/blob/e5f1f5a26399c7d36fa8e2c29ec411eea49b0a4c/src/main.cpp" rel="nofollow">main.cpp</a>, but i would like to know where exactly, thanks.</p>

<p>obviously anybody can mine a block that is set up any way they like, but presumably there are fixed rules for whether it is considered valid or not - so other miners will know whether to use its hash as their prev-header-hash when mining the next block?</p>

<protocol><script>
txout script criteria (scriptpubkey critieria)
mulllhausen
# txout script criteria (scriptpubkey critieria)

(Asked by: username_0 on 2015-06-16)

what is the criteria for a txout script to be accepted into a mined block? is there any criteria at all? the reason i ask is that [`OP_RETURN`](https://github.com/bitcoin/bitcoin/blob/e5f1f5a26399c7d36fa8e2c29ec411eea49b0a4c/src/script/interpreter.cpp#L397-L400) is regularly used in txout scripts yet it is not spendable:

```
case OP_RETURN:
{
    return set_error(serror, SCRIPT_ERR_OP_RETURN);
}

```

and i have also [seen transactions](http://blockexplorer.com/tx/77822fd6663c665104119cb7635352756dfc50da76a92d417ec1a12c518fad69) which push elements to the stack which are more than [MAX\_SCRIPT\_ELEMENT\_SIZE](https://github.com/bitcoin/bitcoin/blob/v0.10.0rc3/src/script/script.h#L18) bytes.

i'm guessing that a syntactically incorrect script such as:

```
05aa
(ie OP_PUSHDATA(5) <aa>)

```

would not be permitted?

could someone point me to the code which miners use to validate whether a tx will be included or discarded as invalid (due to its txout scripts). i'm guessing it lies in [main.cpp](https://github.com/bitcoin/bitcoin/blob/e5f1f5a26399c7d36fa8e2c29ec411eea49b0a4c/src/main.cpp), but i would like to know where exactly, thanks.

obviously anybody can mine a block that is set up any way they like, but presumably there are fixed rules for whether it is considered valid or not - so other miners will know whether to use its hash as their prev-header-hash when mining the next block?

**Tags:** protocol, script


---

## 2 answers

### Answer by username_0 on 2015-06-17. Score: 2 | Accepted answer

transaction `ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767` from the live blockchain contains a lot of syntactically incorrect txout scripts and is useful as a demonstration:

using pybitcointools:

```
#!/usr/bin/env python2.7                                                        

from bitcoin import *
tx_hex = fetchtx("ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767")
tx_dict = deserialize(tx_hex)
for (txout_num, txout) in enumerate(tx_dict["outs"]):
    script = txout["script"]
    print "raw txout %d script: %s" % (txout_num, script)

```

output:

```
raw txout 0 script: 01
raw txout 1 script: 0201
raw txout 2 script: 4c
raw txout 3 script: 4c0201
raw txout 4 script: 4d
raw txout 5 script: 4dffff01
raw txout 6 script: 4e
raw txout 7 script: 4effffffff01

```

analysing each of these txout scripts:

```
01 = OP_PUSHDATA0(1)

```

this fails because it claims it will push 1 byte onto the stack, but then provides no bytes to push onto the stack

```
0201 = OP_PUSHDATA0(2) <01>

```

this fails because it claims it will push 2 bytes onto the stack, but then only provides 1 byte to push onto the stack

```
4c = OP_PUSHDATA1(?)

```

this fails because it is an incomplete OP\_PUSHDATA1 opcode. the `4c` byte should be followed by another byte specifying the number of data bytes to push onto the stack, however it is not.

```
4c0201 = OP_PUSHDATA1(2) <01>

```

this fails because it claims it will push 2 bytes onto the stack, but then only provides 1 byte to push onto the stack.

```
etc

```

its funny that the output scripts in this particular transaction each have a different syntactically incorrect use of the OP\_PUSHDATA commands. its almost as if someone had the same question as this and wanted to test if any syntax checking was implemented on scriptpubkeys. i'm glad they did this because its a very conclusive way to demonstrate that absolutely no syntax checking (and therefore no other checks either) are performed on scriptpubkeys before they are spent.

> **Comments:**
> **username_1**: You'll find a lot of scripts like this on testnet3, and a smaller number on the main network. Many of them are attempting (and actually manage in some cases) to break reimplementations using obscure and undocumented behaviors.  
> **username_0**: yep! it broke [my re-implementation](https://github.com/username_0/btc-inquisitor) - that's the reason i'm asking :) but i don't see a whole lot of value for validating testnet blocks - people can put anything in there and there is not much hashpower to even guarantee valid blocks.  
> **username_1**: You're never going to download a block with invalid contents, because the block would just simply be invalid. The amount of proof of work for this is almost entirely orthogonal. You really shouldn't be reimplementing script, history has shown (bitcoinjs, bitcoin-ruby, btcd) that nobody has the capability to clone the behavior directly, no matter how many millions of dollars are poured into the effort. Unless this is for fun or experience, link to `libconsensus` and avoid losing piles of money. It's not foolproof, but it means you won't have avoidable mistakes in script execution.  
> **username_0**: thanks for the warning but for me its purely educational. you never really know something until you can build it yourself from scratch.  
> **username_0**: i didn't know about `libconsensus` - that looks really useful!  
> **username_1**: For a learning experience go right ahead reimplementing. Somewhat unexpectedly, that's how some consensus bugs have been found in the past. The warning was mostly born of people reimplementing and then running million dollar companies on top of it without really acknowledging the risk.  
> **username_0**: cool. yeah that's another reason for my re-implementation. so far i have always been late to the party - discovering ["bugs"](https://github.com/username_0/btc-inquisitor/blob/master/btc_grunt.py#L1082-L1087) well after they have been fixed [by bips](https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki)  

---

### Answer by username_1 on 2015-06-16. Score: 3

Absolutely no *consensus* validity checks are done on a `scriptPubKey`. Nodes have soft requirements called IsStandard for what they will relay to their peers as a transaction (a completely junk script or very large OP\_RETURN output for example will not pass) but these are not consensus rules. Some miners will mine non-standard transactions into their blocks, but generally to get a transaction to them a transport other than the P2P network needs to be used.

`OP_RETURN` is a special case refereed to as "provably un-spendable", this is a response to people jamming hashes and other data into `PubKeyHash` outputs as a way of pegging them in time to the block chain. Due to there being no way of knowing if the output is actually valid or not these outputs must be stored forever in the UTXO pool. An `OP_RETURN` prefixed output can absolutely never be spent, so nodes can safely forget that they ever existed.

> **Comments:**
> **username_0**: thanks for the reply! but surely if someone builds a block with a syntactically incorrect txout script then no other miners will build on top of it? i'm looking for that criteria - ie for building on top of an already mined block  
> **username_0**: i have added a last paragraph to the op explaining a bit better...  
> **username_1**: The output script is never verified in Bitcoin, you can make something that is complete junk (`OP_CAT OP_CAT OP_CAT`) and that is valid in a block. If there is no way to satisfy the script and spend it again, then the value of the BTC there is simply stuck there forever. This transaction output is similar to your example, it pushes junk onto the stack for no reason. http://webbtc.com/tx/09ca982b6ab313cd7552b9a28e1dabdd37cab5e6ed05bb241579902c5f1e8989 Bonus points if you can work out what it is pushing onto the stack.  
> **username_0**: hmm interesting. i'm guessing it is still syntactically correct though? eg `05aa` would fail? if not then it might be possible to use txout scripts for buffer overflow attacks on users...  
> **username_0**: i know they cant be used in `EvalScript()` - that's not my question.  
> **username_1**: No checks at all, not even on the size of data pushes. It's an array of bytes.  
> **username_0**: cool. apparently [this transaction](http://blockexplorer.com/rawtx/ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767) does exactly that. i need to have a look at the raw hex but once i have confirmed this i will add it into your answer and mark it as the solution. feel free to get there before me :)  
> **username_0**: i created a new answer, since the results turned out to be more interesting than i thought!  

---

