<p>Another very interesting question!</p>

<p>First, note the date of the transaction. Specifically:</p>

<pre><code>"created_at": "2013-10-25T13:16:51.598Z"
</code></pre>

<p>It turns out that until <a href="https://github.com/bitcoin/bitcoin/pull/3843" rel="nofollow">this issue</a>, ANY value could be used instead of OP_0. To quote Peter Todd:</p>

<blockquote>
  <p>While normally OP_0 is used, the actual value of this argument is not
  checked, and thus creates a source of mutability for any transaction
  with CHECKMULTISIG inputs.</p>
</blockquote>

<p>The patch <a href="https://github.com/bitcoin/bitcoin/commit/6380180821917c22ecfd89128ee60aae6f4cac33" rel="nofollow">here</a> actually made it so that the first argument of a standard multisig had to be OP_0 as to not cause transaction malleability.</p>

<p>Given that this transaction was before this commit got into the standard bitcoin client, that transaction was perfectly fine. You literally could have put almost any value as the first byte and it would have gone through.</p>

<p>Also note that this was a soft-forking change. It's still legal to put OP_INVALIDCODE instead of OP_0, it just won't be propagated by the standard bitcoin client and thus probably won't get into a block. Otherwise, this would have been a hard-forking change.</p>

<hr>

<p>Edit: It looks like the API from biteasy is different than other places like blockchain:</p>

<p>Note that the script begins with <code>00</code>, not <code>ff</code> as with biteasy.</p>

<p><a href="https://blockchain.info/rawtx/fccf964964c34994e5dbbb9ff7f914159b524b0831f6eea12255aa424b39090e" rel="nofollow">https://blockchain.info/rawtx/fccf964964c34994e5dbbb9ff7f914159b524b0831f6eea12255aa424b39090e</a></p>

<pre><code>{
"ver": 1,
"inputs": [
{
"sequence": 4294967295,
"prev_out": {
"spent": true,
"tx_index": 38094378,
"type": 0,
"addr": "35aHovjnZ9xdfYZsB2yBVTs6CWqnBpHNDY",
"value": 100000,
"n": 1,
"script": "a9142a9ada309638ec606f67e6b107867184c58a3aab87"
},
"script": "00473044022016c09f09b6c55c0afefa1c0f0b7fa5789b3fa486d19ba3e7f5338fc8a2701dc502203ab665792d477ffabcfb736b6d6951d238d5a8af8f9754cc29e9caab46b9b1dd01473044022016c09f09b6c55c0afefa1c0f0b7fa5789b3fa486d19ba3e7f5338fc8a2701dc502203ab665792d477ffabcfb736b6d6951d238d5a8af8f9754cc29e9caab46b9b1dd014cc9524104d9399e85461d925e4c3932cc033aee59873e1212216c81943d5634c2e45ee0f45181f69d63b236e53d286a43b2de2b0ee64850191771924430f92ac6542f3cf24104d9399e85461d925e4c3932cc033aee59873e1212216c81943d5634c2e45ee0f45181f69d63b236e53d286a43b2de2b0ee64850191771924430f92ac6542f3cf241046d38a48ed6f12b132cdf14e84d1d6678bbf0e148e1b4791ee39fa0945cecf86ecb870cd4c74a4e472b8e3034f771df0375a7c097adf2bc48ce9f2ea3e64e20dc53ae"
}
],
"block_height": 265976,
"relayed_by": "24.212.184.180",
"out": [
{
"spent": true,
"tx_index": 38095095,
"type": 0,
"addr": "1QKjwQ7tJGaWrXyftce4ns47gvZ67GoqMt",
"value": 80000,
"n": 0,
"script": "76a914ffd6391cff55413edb04761ecf1a447d80bfe74188ac"
}
],
"lock_time": 0,
"size": 435,
"double_spend": false,
"time": 1382706718,
"tx_index": 38095095,
"vin_sz": 1,
"hash": "fccf964964c34994e5dbbb9ff7f914159b524b0831f6eea12255aa424b39090e",
"vout_sz": 1
}
</code></pre>

CC BY-SA 3.0
2015-03-10T03:12:21.777Z
I did notice that, as it's only biteasy which seems to flag the OP_0 as `ff` rather than `00`
Wizard Of Ozzie
CC BY-SA 3.0
2015-03-08T15:41:38.127Z
2015-03-08T18:39:56.237Z
2015-03-08T18:39:56.237Z
Jimmy Song
<blockquote>
  <p>But it's the raw hex where ff is representing the OP_0 (empty array)
  that is confusing me</p>
</blockquote>

<p>I do not see any problems with this tx. OK, pubkey1 == pubkey2 and there is one signature push repeated twice. But everything is correct</p>

<pre><code>01000000
01

9f3c95a83feaa2a84f5800ce482a50387fd8a7a142b0619a29923aab45574ca4:01000000

fd5c01 // scriptSig len
00     // push empty vector/zero value 
473044022016c09f09b6c55c0afefa1c0f0b7fa5789b3fa486d19ba3e7f5338fc8a2701dc502203ab665792d477ffabcfb736b6d6951d238d5a8af8f9754cc29e9caab46b9b1dd01
473044022016c09f09b6c55c0afefa1c0f0b7fa5789b3fa486d19ba3e7f5338fc8a2701dc502203ab665792d477ffabcfb736b6d6951d238d5a8af8f9754cc29e9caab46b9b1dd01
4cc9
  52
  4104d9399e85461d925e4c3932cc033aee59873e1212216c81943d5634c2e45ee0f45181f69d63b236e53d286a43b2de2b0ee64850191771924430f92ac6542f3cf2
  4104d9399e85461d925e4c3932cc033aee59873e1212216c81943d5634c2e45ee0f45181f69d63b236e53d286a43b2de2b0ee64850191771924430f92ac6542f3cf2
  41046d38a48ed6f12b132cdf14e84d1d6678bbf0e148e1b4791ee39fa0945cecf86ecb870cd4c74a4e472b8e3034f771df0375a7c097adf2bc48ce9f2ea3e64e20dc
  53ae
ffffffff

01
8038010000000000
1976a914ffd6391cff55413edb04761ecf1a447d80bfe74188ac
00000000
</code></pre>

CC BY-SA 3.0
2015-03-10T03:10:41.300Z
It's strange because I've got the same data when I run *getrawtransaction*, but the Python code I wrote which retrieves raw hex data from biteasy shows `ff`
Wizard Of Ozzie
CC BY-SA 3.0
2015-03-10T05:09:14.113Z
trust me. trust yourself. do not trust biteasy
amaclin
CC BY-SA 3.0
2015-03-10T05:57:24.097Z
I hear you mate: the Python code I wrote flags "interesting" Txs, which usually means a non-standard Tx template, but in this case it was both a non-standard Tx template and conflicting source hex data. I am acutely aware a full node (bitcoincore txindex=1) is *"canonical"* for Txs, whereas APIs are much less so. I know Blockchain.info and Blockexplorer.com have had issues with UTXOs balances and such, but wasn't aware APIs could differ in *raw hex*, since it implies the Blockchain data differs from consensus
Wizard Of Ozzie
CC BY-SA 3.0
2015-03-08T18:25:05.127Z
2015-03-09T09:40:19.160Z
2015-03-09T09:40:19.160Z
amaclin
<p>From Biteasy's API for TXID <a href="https://api.biteasy.com/blockchain/v1/transactions/fccf964964c34994e5dbbb9ff7f914159b524b0831f6eea12255aa424b39090e" rel="nofollow">fccf964964c34994e5dbbb9ff7f914159b524b0831f6eea12255aa424b39090e</a> we can see the following info regarding inputs (for a P2SH Tx):</p>

<pre><code>"script_sig_string": "[] [3044022016c09f09b6c55....]
"script_sig": "ff473044022016c09f09b6c55....
</code></pre>

<p>I do know a null byte vector (OP_0) is required for the <em>off by 1 error</em> for multisig Txs. But it's the raw hex where <code>ff</code> is representing the OP_0 (empty array) that is confusing me.  Is this being read as 2's complement of 0x00 or is it reading <code>OP_INVALIDOPCODE</code> as outlined on the Bitcoin Wiki Script page (quoted below)?</p>

<pre><code>OP_PUBKEYHASH      253  0xfd    Represents a public key hashed with OP_HASH160.
OP_PUBKEY          254  0xfe    Represents a public key compatible with OP_CHECKSIG.
OP_INVALIDOPCODE   255  0xff    Matches any opcode that is not yet assigned.
</code></pre>

<p>FYI, this Tx caused issues with the core software parsing the blockchain awhile back; that much I am aware. However I have yet to find an explanation online (omitting github/C++ code, which I am not well versed in reading)</p>

<transactions><script><raw-transaction>
Specific instance of Tx using a malformed null byte vector for P2SH; insight req
Wizard Of Ozzie
# Specific instance of Tx using a malformed null byte vector for P2SH; insight req

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

From Biteasy's API for TXID fccf964964c34994e5dbbb9ff7f914159b524b0831f6eea12255aa424b39090e we can see the following info regarding inputs (for a P2SH Tx):
"script_sig_string": "[] [3044022016c09f09b6c55....]
"script_sig": "ff473044022016c09f09b6c55....

I do know a null byte vector (OP_0) is required for the off by 1 error for multisig Txs. But it's the raw hex where ff is representing the OP_0 (empty array) that is confusing me.  Is this being read as 2's complement of 0x00 or is it reading OP_INVALIDOPCODE as outlined on the Bitcoin Wiki Script page (quoted below)?
OP_PUBKEYHASH      253  0xfd    Represents a public key hashed with OP_HASH160.
OP_PUBKEY          254  0xfe    Represents a public key compatible with OP_CHECKSIG.
OP_INVALIDOPCODE   255  0xff    Matches any opcode that is not yet assigned.

FYI, this Tx caused issues with the core software parsing the blockchain awhile back; that much I am aware. However I have yet to find an explanation online (omitting github/C++ code, which I am not well versed in reading)

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


---

## 2 answers

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

Another very interesting question!
First, note the date of the transaction. Specifically:
"created_at": "2013-10-25T13:16:51.598Z"

It turns out that until this issue, ANY value could be used instead of OP_0. To quote Peter Todd:

While normally OP_0 is used, the actual value of this argument is not
  checked, and thus creates a source of mutability for any transaction
  with CHECKMULTISIG inputs.

The patch here actually made it so that the first argument of a standard multisig had to be OP_0 as to not cause transaction malleability.
Given that this transaction was before this commit got into the standard bitcoin client, that transaction was perfectly fine. You literally could have put almost any value as the first byte and it would have gone through.
Also note that this was a soft-forking change. It's still legal to put OP_INVALIDCODE instead of OP_0, it just won't be propagated by the standard bitcoin client and thus probably won't get into a block. Otherwise, this would have been a hard-forking change.

Edit: It looks like the API from biteasy is different than other places like blockchain:
Note that the script begins with 00, not ff as with biteasy.
https://blockchain.info/rawtx/fccf964964c34994e5dbbb9ff7f914159b524b0831f6eea12255aa424b39090e
{
"ver": 1,
"inputs": [
{
"sequence": 4294967295,
"prev_out": {
"spent": true,
"tx_index": 38094378,
"type": 0,
"addr": "35aHovjnZ9xdfYZsB2yBVTs6CWqnBpHNDY",
"value": 100000,
"n": 1,
"script": "a9142a9ada309638ec606f67e6b107867184c58a3aab87"
},
"script": "00473044022016c09f09b6c55c0afefa1c0f0b7fa5789b3fa486d19ba3e7f5338fc8a2701dc502203ab665792d477ffabcfb736b6d6951d238d5a8af8f9754cc29e9caab46b9b1dd01473044022016c09f09b6c55c0afefa1c0f0b7fa5789b3fa486d19ba3e7f5338fc8a2701dc502203ab665792d477ffabcfb736b6d6951d238d5a8af8f9754cc29e9caab46b9b1dd014cc9524104d9399e85461d925e4c3932cc033aee59873e1212216c81943d5634c2e45ee0f45181f69d63b236e53d286a43b2de2b0ee64850191771924430f92ac6542f3cf24104d9399e85461d925e4c3932cc033aee59873e1212216c81943d5634c2e45ee0f45181f69d63b236e53d286a43b2de2b0ee64850191771924430f92ac6542f3cf241046d38a48ed6f12b132cdf14e84d1d6678bbf0e148e1b4791ee39fa0945cecf86ecb870cd4c74a4e472b8e3034f771df0375a7c097adf2bc48ce9f2ea3e64e20dc53ae"
}
],
"block_height": 265976,
"relayed_by": "24.212.184.180",
"out": [
{
"spent": true,
"tx_index": 38095095,
"type": 0,
"addr": "1QKjwQ7tJGaWrXyftce4ns47gvZ67GoqMt",
"value": 80000,
"n": 0,
"script": "76a914ffd6391cff55413edb04761ecf1a447d80bfe74188ac"
}
],
"lock_time": 0,
"size": 435,
"double_spend": false,
"time": 1382706718,
"tx_index": 38095095,
"vin_sz": 1,
"hash": "fccf964964c34994e5dbbb9ff7f914159b524b0831f6eea12255aa424b39090e",
"vout_sz": 1
}

> **Comments:**
> **username_0**: I did notice that, as it's only biteasy which seems to flag the OP_0 as `ff` rather than `00`  

---

### Answer by username_2 on 2015-03-08. Score: 0

But it's the raw hex where ff is representing the OP_0 (empty array)
  that is confusing me

I do not see any problems with this tx. OK, pubkey1 == pubkey2 and there is one signature push repeated twice. But everything is correct
01000000
01

9f3c95a83feaa2a84f5800ce482a50387fd8a7a142b0619a29923aab45574ca4:01000000

fd5c01 // scriptSig len
00     // push empty vector/zero value 
473044022016c09f09b6c55c0afefa1c0f0b7fa5789b3fa486d19ba3e7f5338fc8a2701dc502203ab665792d477ffabcfb736b6d6951d238d5a8af8f9754cc29e9caab46b9b1dd01
473044022016c09f09b6c55c0afefa1c0f0b7fa5789b3fa486d19ba3e7f5338fc8a2701dc502203ab665792d477ffabcfb736b6d6951d238d5a8af8f9754cc29e9caab46b9b1dd01
4cc9
  52
  4104d9399e85461d925e4c3932cc033aee59873e1212216c81943d5634c2e45ee0f45181f69d63b236e53d286a43b2de2b0ee64850191771924430f92ac6542f3cf2
  4104d9399e85461d925e4c3932cc033aee59873e1212216c81943d5634c2e45ee0f45181f69d63b236e53d286a43b2de2b0ee64850191771924430f92ac6542f3cf2
  41046d38a48ed6f12b132cdf14e84d1d6678bbf0e148e1b4791ee39fa0945cecf86ecb870cd4c74a4e472b8e3034f771df0375a7c097adf2bc48ce9f2ea3e64e20dc
  53ae
ffffffff

01
8038010000000000
1976a914ffd6391cff55413edb04761ecf1a447d80bfe74188ac
00000000

> **Comments:**
> **username_0**: It's strange because I've got the same data when I run *getrawtransaction*, but the Python code I wrote which retrieves raw hex data from biteasy shows `ff`  
> **username_2**: trust me. trust yourself. do not trust biteasy  
> **username_0**: I hear you mate: the Python code I wrote flags "interesting" Txs, which usually means a non-standard Tx template, but in this case it was both a non-standard Tx template and conflicting source hex data. I am acutely aware a full node (bitcoincore txindex=1) is *"canonical"* for Txs, whereas APIs are much less so. I know Blockchain.info and Blockexplorer.com have had issues with UTXOs balances and such, but wasn't aware APIs could differ in *raw hex*, since it implies the Blockchain data differs from consensus  

---

