<p>The scriptPubKey, decoded:</p>

<pre><code>02085c6600657566acc2d6382a47bc3f324008d2aa10940dd7705a48aa2a5a5e33 OP_CHECKSIG OP_SWAP 03f5d0fb955f95dd6be6115ce85661db412ec6a08abcbfce7da0ba8297c6cc0ec4 OP_CHECKSIG OP_SWAP OP_3 OP_PICK OP_SHA256 d68df9e32a147cffa36193c6f7c43a1c8c69cda530e1c6db354bfabdcfefaf3c OP_EQUAL OP_3 OP_PICK OP_SHA256 f531f3041d3136701ea09067c53e7159c8f9b2746a56c3d82966c54bbc553226 OP_EQUAL OP_BOOLAND OP_4 OP_PICK OP_SIZE OP_NIP 20 22 OP_WITHIN OP_BOOLAND OP_3 OP_PICK OP_SIZE OP_NIP 20 22 OP_WITHIN OP_BOOLAND OP_IF OP_3 OP_PICK OP_SIZE OP_NIP OP_3 OP_PICK OP_SIZE OP_NIP OP_EQUAL OP_PICK OP_ELSE OP_BOOLAND OP_ENDIF 
</code></pre>

<p>The scriptSig that spends the output, decoded:</p>

<pre><code>ca42095840735e89283fec298e62ac2ddea9b5f34a8cbb7097ad965b87568100 1b1b01dc829177da4a14551d2fc96a9db00c6501edfa12f22cd9cefd335c227f 3045022100a9df60536df5733dd0de6bc921fab0b3eee6426501b43a228afa2c90072eb5ca02201c78b74266fac7d1db5deff080d8a403743203f109fbcabf6d5a760bf87386d201 OP_FALSE
</code></pre>

<p>So they're combined, which results in:</p>

<pre><code>ca42095840735e89283fec298e62ac2ddea9b5f34a8cbb7097ad965b87568100 1b1b01dc829177da4a14551d2fc96a9db00c6501edfa12f22cd9cefd335c227f 3045022100a9df60536df5733dd0de6bc921fab0b3eee6426501b43a228afa2c90072eb5ca02201c78b74266fac7d1db5deff080d8a403743203f109fbcabf6d5a760bf87386d201 OP_FALSE 02085c6600657566acc2d6382a47bc3f324008d2aa10940dd7705a48aa2a5a5e33 OP_CHECKSIG OP_SWAP 03f5d0fb955f95dd6be6115ce85661db412ec6a08abcbfce7da0ba8297c6cc0ec4 OP_CHECKSIG OP_SWAP OP_3 OP_PICK OP_SHA256 d68df9e32a147cffa36193c6f7c43a1c8c69cda530e1c6db354bfabdcfefaf3c OP_EQUAL OP_3 OP_PICK OP_SHA256 f531f3041d3136701ea09067c53e7159c8f9b2746a56c3d82966c54bbc553226 OP_EQUAL OP_BOOLAND OP_4 OP_PICK OP_SIZE OP_NIP 20 22 OP_WITHIN OP_BOOLAND OP_3 OP_PICK OP_SIZE OP_NIP 20 22 OP_WITHIN OP_BOOLAND OP_IF OP_3 OP_PICK OP_SIZE OP_NIP OP_3 OP_PICK OP_SIZE OP_NIP OP_EQUAL OP_PICK OP_ELSE OP_BOOLAND OP_ENDIF 
</code></pre>

<p>It checks a signature of zero-length <code>OP_FALSE</code> against the pubkey <code>02085c6600657566acc2d6382a47bc3f324008d2aa10940dd7705a48aa2a5a5e33</code> Obviously, that returns false. But it doesn't actually cause an error, because <code>CHECKSIGVERIFY</code> wasn't used. The rest of the script executes, and finally a non-zero value is left on the stack. Therefore, the transaction is valid.</p>

<p>Since the transaction is now in the blockchain, other clients must understand it too.</p>

<p>So what was this guy doing? Beats me.</p>

CC BY-SA 3.0
2015-08-28T18:13:45.177Z
`It checks a signature of zero-length OP_FALSE against the pubkey`: I'm confused on 2 things: 1) is a zero length sig just a single nullbyte? 2) but where does the `0b3eee...` come from I'm the spending scriptSig?
Wizard Of Ozzie
CC BY-SA 3.0
2015-08-28T18:21:12.850Z
@WizardOfOzzie `1` No, it's a item of no bytes. See OP_FALSE on the wiki. `2` Not sure I understand. It comes from the third push in the scriptSig. (Although it doesn't start with that.)
Nick ODell
CC BY-SA 3.0
2015-08-28T18:27:58.747Z
Re 1) ahhhhhh, so None in Python. 2) don't mind me... Ipad was hiding the code in right margin
Wizard Of Ozzie
CC BY-SA 3.0
2015-08-28T17:41:03.067Z
2015-08-28T17:41:03.067Z
Nick ODell
<p>The scriptPubKey for <a href="http://blockchain.info/rawtx/cbebc4da731e8995fe97f6fadcd731b36ad40e5ecb31e38e904f6e5982fa09f7?format=json" rel="nofollow">cbebc4da731e8995fe97f6fadcd731b36ad40e5ecb31e38e904f6e5982fa09f7</a> is:</p>

<blockquote>
  <p><code>0x2102085c6600657566acc2d6382a47bc3f324008d2aa10940dd7705a48aa2a5a5e33ac7c2103f5d0fb955f95dd6be6115ce85661db412ec6a08abcbfce7da0ba8297c6cc0ec4ac7c5379a820d68df9e32a147cffa36193c6f7c43a1c8c69cda530e1c6db354bfabdcfefaf3c875379a820f531f3041d3136701ea09067c53e7159c8f9b2746a56c3d82966c54bbc553226879a5479827701200122a59a5379827701200122a59a6353798277537982778779679a68</code></p>
</blockquote>

<p>Whilst it's outpoint:</p>

<blockquote>
  <p><code>01000000023bec4b2a0193b3cb63cc3a263654f29606d032bf62dfd8f8579aca2f6a2b82a8000000004948304502210091abb9de9d785cc8b0129377d148d6458d283fb732785513f8217ae098f6a95702205de7fb76b028a3a2e6e8aea4b34a2309138013f696df1c26f3000df63ab0c72e01ffffffff2e0ac83f7b3674664811dbbb244ef05cf887049411f5c1dc6b4b53ea7dfec743000000006a483045022100fc458d74fd6c75e64a26d790f40135c2c28d0ad229c56c98891e94cdb1d5309902205d9d035f01d730b64ab3436319e7f1d989f52aa09295b32a650627e392819da001201b1b01dc829177da4a14551d2fc96a9db00c6501edfa12f22cd9cefd335c227fffffffff01d09c790000000000b52102085c6600657566acc2d6382a47bc3f324008d2aa10940dd7705a48aa2a5a5e33ac7c2103f5d0fb955f95dd6be6115ce85661db412ec6a08abcbfce7da0ba8297c6cc0ec4ac7c5379a820d68df9e32a147cffa36193c6f7c43a1c8c69cda530e1c6db354bfabdcfefaf3c875379a820f531f3041d3136701ea09067c53e7159c8f9b2746a56c3d82966c54bbc553226879a5479827701200122a59a5379827701200122a59a6353798277537982778779679a6800000000</code></p>
</blockquote>

<p>The test vector spending it, <a href="http://blockchain.info/rawtx/cc60b1f899ec0a69b7c3f25ddf32c4524096a9c5b01cbd84c6d0312a0c478984?format=json" rel="nofollow">cc60b1f899ec0a69b7c3f25ddf32c4524096a9c5b01cbd84c6d0312a0c478984</a>, is:</p>

<blockquote>
  <p><code>0100000001f709fa82596e4f908ee331cb5e0ed46ab331d7dcfaf697fe95891e73dac4ebcb000000008c20ca42095840735e89283fec298e62ac2ddea9b5f34a8cbb7097ad965b87568100201b1b01dc829177da4a14551d2fc96a9db00c6501edfa12f22cd9cefd335c227f483045022100a9df60536df5733dd0de6bc921fab0b3eee6426501b43a228afa2c90072eb5ca02201c78b74266fac7d1db5deff080d8a403743203f109fbcabf6d5a760bf87386d20100ffffffff01c075790000000000232103611f9a45c18f28f06f19076ad571c344c82ce8fcfe34464cf8085217a2d294a6ac00000000</code></p>
</blockquote>

<p>The attached comments say <code>cc60b1f8...d0312a0c478984, which is a fairly strange transaction which relies on OP_CHECKSIG returning 0 when checking a completely invalid sig of length 0</code></p>

<p>What on earth is going on here?</p>

<transactions><script><raw-transaction>
How does the scriptPubKey for this test vector work?
Wizard Of Ozzie
# How does the scriptPubKey for this test vector work?

(Asked by: username_0 on 2015-08-28)

The scriptPubKey for [cbebc4da731e8995fe97f6fadcd731b36ad40e5ecb31e38e904f6e5982fa09f7](http://blockchain.info/rawtx/cbebc4da731e8995fe97f6fadcd731b36ad40e5ecb31e38e904f6e5982fa09f7?format=json) is:

> `0x2102085c6600657566acc2d6382a47bc3f324008d2aa10940dd7705a48aa2a5a5e33ac7c2103f5d0fb955f95dd6be6115ce85661db412ec6a08abcbfce7da0ba8297c6cc0ec4ac7c5379a820d68df9e32a147cffa36193c6f7c43a1c8c69cda530e1c6db354bfabdcfefaf3c875379a820f531f3041d3136701ea09067c53e7159c8f9b2746a56c3d82966c54bbc553226879a5479827701200122a59a5379827701200122a59a6353798277537982778779679a68`

Whilst it's outpoint:

> `01000000023bec4b2a0193b3cb63cc3a263654f29606d032bf62dfd8f8579aca2f6a2b82a8000000004948304502210091abb9de9d785cc8b0129377d148d6458d283fb732785513f8217ae098f6a95702205de7fb76b028a3a2e6e8aea4b34a2309138013f696df1c26f3000df63ab0c72e01ffffffff2e0ac83f7b3674664811dbbb244ef05cf887049411f5c1dc6b4b53ea7dfec743000000006a483045022100fc458d74fd6c75e64a26d790f40135c2c28d0ad229c56c98891e94cdb1d5309902205d9d035f01d730b64ab3436319e7f1d989f52aa09295b32a650627e392819da001201b1b01dc829177da4a14551d2fc96a9db00c6501edfa12f22cd9cefd335c227fffffffff01d09c790000000000b52102085c6600657566acc2d6382a47bc3f324008d2aa10940dd7705a48aa2a5a5e33ac7c2103f5d0fb955f95dd6be6115ce85661db412ec6a08abcbfce7da0ba8297c6cc0ec4ac7c5379a820d68df9e32a147cffa36193c6f7c43a1c8c69cda530e1c6db354bfabdcfefaf3c875379a820f531f3041d3136701ea09067c53e7159c8f9b2746a56c3d82966c54bbc553226879a5479827701200122a59a5379827701200122a59a6353798277537982778779679a6800000000`

The test vector spending it, [cc60b1f899ec0a69b7c3f25ddf32c4524096a9c5b01cbd84c6d0312a0c478984](http://blockchain.info/rawtx/cc60b1f899ec0a69b7c3f25ddf32c4524096a9c5b01cbd84c6d0312a0c478984?format=json), is:

> `0100000001f709fa82596e4f908ee331cb5e0ed46ab331d7dcfaf697fe95891e73dac4ebcb000000008c20ca42095840735e89283fec298e62ac2ddea9b5f34a8cbb7097ad965b87568100201b1b01dc829177da4a14551d2fc96a9db00c6501edfa12f22cd9cefd335c227f483045022100a9df60536df5733dd0de6bc921fab0b3eee6426501b43a228afa2c90072eb5ca02201c78b74266fac7d1db5deff080d8a403743203f109fbcabf6d5a760bf87386d20100ffffffff01c075790000000000232103611f9a45c18f28f06f19076ad571c344c82ce8fcfe34464cf8085217a2d294a6ac00000000`

The attached comments say `cc60b1f8...d0312a0c478984, which is a fairly strange transaction which relies on OP_CHECKSIG returning 0 when checking a completely invalid sig of length 0`

What on earth is going on here?

**Tags:** transactions, script, raw-transaction


---

## 1 answers

### Answer by username_1 on 2015-08-28. Score: 1 | Accepted answer

The scriptPubKey, decoded:

```
02085c6600657566acc2d6382a47bc3f324008d2aa10940dd7705a48aa2a5a5e33 OP_CHECKSIG OP_SWAP 03f5d0fb955f95dd6be6115ce85661db412ec6a08abcbfce7da0ba8297c6cc0ec4 OP_CHECKSIG OP_SWAP OP_3 OP_PICK OP_SHA256 d68df9e32a147cffa36193c6f7c43a1c8c69cda530e1c6db354bfabdcfefaf3c OP_EQUAL OP_3 OP_PICK OP_SHA256 f531f3041d3136701ea09067c53e7159c8f9b2746a56c3d82966c54bbc553226 OP_EQUAL OP_BOOLAND OP_4 OP_PICK OP_SIZE OP_NIP 20 22 OP_WITHIN OP_BOOLAND OP_3 OP_PICK OP_SIZE OP_NIP 20 22 OP_WITHIN OP_BOOLAND OP_IF OP_3 OP_PICK OP_SIZE OP_NIP OP_3 OP_PICK OP_SIZE OP_NIP OP_EQUAL OP_PICK OP_ELSE OP_BOOLAND OP_ENDIF 

```

The scriptSig that spends the output, decoded:

```
ca42095840735e89283fec298e62ac2ddea9b5f34a8cbb7097ad965b87568100 1b1b01dc829177da4a14551d2fc96a9db00c6501edfa12f22cd9cefd335c227f 3045022100a9df60536df5733dd0de6bc921fab0b3eee6426501b43a228afa2c90072eb5ca02201c78b74266fac7d1db5deff080d8a403743203f109fbcabf6d5a760bf87386d201 OP_FALSE

```

So they're combined, which results in:

```
ca42095840735e89283fec298e62ac2ddea9b5f34a8cbb7097ad965b87568100 1b1b01dc829177da4a14551d2fc96a9db00c6501edfa12f22cd9cefd335c227f 3045022100a9df60536df5733dd0de6bc921fab0b3eee6426501b43a228afa2c90072eb5ca02201c78b74266fac7d1db5deff080d8a403743203f109fbcabf6d5a760bf87386d201 OP_FALSE 02085c6600657566acc2d6382a47bc3f324008d2aa10940dd7705a48aa2a5a5e33 OP_CHECKSIG OP_SWAP 03f5d0fb955f95dd6be6115ce85661db412ec6a08abcbfce7da0ba8297c6cc0ec4 OP_CHECKSIG OP_SWAP OP_3 OP_PICK OP_SHA256 d68df9e32a147cffa36193c6f7c43a1c8c69cda530e1c6db354bfabdcfefaf3c OP_EQUAL OP_3 OP_PICK OP_SHA256 f531f3041d3136701ea09067c53e7159c8f9b2746a56c3d82966c54bbc553226 OP_EQUAL OP_BOOLAND OP_4 OP_PICK OP_SIZE OP_NIP 20 22 OP_WITHIN OP_BOOLAND OP_3 OP_PICK OP_SIZE OP_NIP 20 22 OP_WITHIN OP_BOOLAND OP_IF OP_3 OP_PICK OP_SIZE OP_NIP OP_3 OP_PICK OP_SIZE OP_NIP OP_EQUAL OP_PICK OP_ELSE OP_BOOLAND OP_ENDIF 

```

It checks a signature of zero-length `OP_FALSE` against the pubkey `02085c6600657566acc2d6382a47bc3f324008d2aa10940dd7705a48aa2a5a5e33` Obviously, that returns false. But it doesn't actually cause an error, because `CHECKSIGVERIFY` wasn't used. The rest of the script executes, and finally a non-zero value is left on the stack. Therefore, the transaction is valid.

Since the transaction is now in the blockchain, other clients must understand it too.

So what was this guy doing? Beats me.

> **Comments:**
> **username_0**: `It checks a signature of zero-length OP_FALSE against the pubkey`: I'm confused on 2 things: 1) is a zero length sig just a single nullbyte? 2) but where does the `0b3eee...` come from I'm the spending scriptSig?  
> **username_1**: @username_0 `1` No, it's a item of no bytes. See OP_FALSE on the wiki. `2` Not sure I understand. It comes from the third push in the scriptSig. (Although it doesn't start with that.)  
> **username_0**: Re 1) ahhhhhh, so None in Python. 2) don't mind me... Ipad was hiding the code in right margin  

---

