<ol>
<li>Not all miners accept transactions with null-data (OP_RETURN)
outputs</li>
<li>Not all nodes relay such transactions</li>
<li>Are you sure that your null-data transaction is standard (for clients 0.9.x+) ?</li>
</ol>

<p>UPD: your output is 6a74686973206973206120746573740d0a and decoded to:</p>

<pre><code>OP_RETURN // 6a
OP_DEPTH  // 74
OP_ENDIF  // 68 ... oups!
</code></pre>

<p>This is non-standard output. Because null-data output should contain only one OP_PUSH operation, not an arbitrary bytes</p>

CC BY-SA 3.0
2015-06-09T10:54:37.537Z
Got it, thanks! I was just doing OP_RETURN [data] instead of OP_RETURN [num bytes of data][data]. Tested a new transaction and it got picked up by many more mem pools (not in a block yet).

It does seem that 1. and 2. on your list are also correct, since in some older examples that had standard scripts (I created those with a library instead of manually) also took longer to go into a block.  
  
Additionally, some services like blockchain.info will refuse to broadcast them (They say the script is non standard even though it is)
Mike
CC BY-SA 3.0
2015-06-08T13:01:42.667Z
2015-06-08T13:08:24.727Z
2015-06-08T13:08:24.727Z
amaclin
<p>I was under the impression that null-data transactions were standard, but whenever I try to broadcast one it takes a while for it to appear in a block.</p>

<p>I tested this by broadcasting 2 transactions with same fees and same priority. The standard one got picked up in the next block, while the null-data one has yet to appear in a block (there's been 3 non-full blocks mined so far).</p>

<p>example tx: <a href="https://live.blockcypher.com/btc/tx/c0b0de8662054cadd461b488676a374f8f962c91612070e8e23b95d108d36217/" rel="nofollow">https://live.blockcypher.com/btc/tx/c0b0de8662054cadd461b488676a374f8f962c91612070e8e23b95d108d36217/</a></p>

<p>Am I doing anything wrong to make this transaction non-standard?</p>

<op-return><non-standard-transaction>
Do transactions with null data take longer to confirm?
Mike
# Do transactions with null data take longer to confirm?

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

I was under the impression that null-data transactions were standard, but whenever I try to broadcast one it takes a while for it to appear in a block.

I tested this by broadcasting 2 transactions with same fees and same priority. The standard one got picked up in the next block, while the null-data one has yet to appear in a block (there's been 3 non-full blocks mined so far).

example tx: <https://live.blockcypher.com/btc/tx/c0b0de8662054cadd461b488676a374f8f962c91612070e8e23b95d108d36217/>

Am I doing anything wrong to make this transaction non-standard?

**Tags:** op-return, non-standard-transaction


---

## 1 answers

### Answer by username_1 on 2015-06-08. Score: 4 | Accepted answer

Not all miners accept transactions with null-data (OP_RETURN)
outputs
Not all nodes relay such transactions
Are you sure that your null-data transaction is standard (for clients 0.9.x+) ?

UPD: your output is 6a74686973206973206120746573740d0a and decoded to:
OP_RETURN // 6a
OP_DEPTH  // 74
OP_ENDIF  // 68 ... oups!

This is non-standard output. Because null-data output should contain only one OP_PUSH operation, not an arbitrary bytes

> **Comments:**
> **username_0**: Got it, thanks! I was just doing OP_RETURN [data] instead of OP_RETURN [num bytes of data][data]. Tested a new transaction and it got picked up by many more mem pools (not in a block yet).  It does seem that 1. and 2. on your list are also correct, since in some older examples that had standard scripts (I created those with a library instead of manually) also took longer to go into a block.      Additionally, some services like blockchain.info will refuse to broadcast them (They say the script is non standard even though it is)  

---

