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?

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

UPD: your output is 6a74686973206973206120746573740d0a and decoded to:

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

| improve this answer | |
  • 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 Jun 9 '15 at 10:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.