Is the OP_PUSHBYTES_X opcode always required after OP_RETURN?

Question

Is the OP_PUSHBYTES opcode always expected after OP_RETURN?

For instance, the 2nd output of transaction 6dfb16dd580698242bcfd8e433d557ed8c642272a368894de27292a8844a4e75 is:

OP_RETURN
OP_PUSHBYTES_11
68656c6c6f20776f726c64

Would

OP_RETURN
68656c6c6f20776f726c64

work just as well? If not, where in the bitcoin core source code is the requirement for the OP_PUSHBYTES code enforced?

Is there a difference in requirement here (aside from the 80 byte limit) between standard and non-standard transactions?

From bitcoin.it, it seems OP_PUSHBYTES is not required but I've not yet found an example main net transaction without one.

Answer 1

My existing answer stands, but as I feel we're talking past each other due to different assumptions about what Script notations mean, let me add this to dig deeper into that.

I'm going to change the literals in your question a bit for simplicity, and try to answer the question:

I see an output with scriptPubKey OP_RETURN OP_PUSHBYTES_3 686c77. Would an output with scriptPubKey OP_RETURN 686c77 also be valid and/or standard?

The first point is that in your notation, the string OP_RETURN 686c77 simply has no meaning. It does not correspond to any script at all. I don't mean that such a script would be invalid; I mean that literally this cannot be translated to actual script bytes.

For background, the script OP_RETURN OP_PUSHBYTES_3 686c77 corresponds the script bytes whose hex encoding is 6a03686c77 (6a being OP_RETURN, and 03 being OP_PUSHBYTES_3). My assumption is that what you mean by OP_RETURN 686c77 is the script whose hex bytes are 6a686c77, i.e., the same bytes as before, but with the OP_PUSHBYTES_3 byte dropped.

However, those script bytes would not be denoted OP_RETURN 686c77. It would be denoted OP_RETURN OP_ENDIF OP_FROMALTSTACK OP_NIP (because without the 03 bytes, the 3 bytes that follow are interpreted as opcodes, rather than as a literal).

If your question is about the script OP_RETURN OP_ENDIF OP_FROMALTSTACK OP_NIP (hex 6a686c77), the answer is that by consensus rules this output is valid (even though it has an OP_ENDIF without corresponding OP_IF!) because Scripts are not executed or interpreted until they are spent, and an OP_RETURN output like this is obviously unspendable. The only consensus rules governing scriptPubKeys is that they cannot exceed 10000 bytes, but there are absolutely no rules restricting what those bytes can be. As for standardness, the answer as of Bitcoin Core 27.0 is no; the requirement for OP_RETURN outputs to be standard is (among other things) that the OP_RETURN is only followed by pushes, not by other opcodes.

To add to the confusion, there exist other human-readable notations for Script, including a common one which just never uses OP_PUSHBYTES_xx. In the Bitcoin Core notation, the script whose hex bytes are 6a03686c77 is simply denoted OP_RETURN 686c77 (with the 03 byte, and the pushing, implicit in the hex constant). So if you ask about OP_RETURN 686c77, it really matters what you mean by that. Either you've switched to another encoding (for the same script, and nothing changed), or you've described something meaningless.

Answer 2

This is a notational issue, resulting from how you're choosing to write the Scripts in readable form.

This question simply makes no sense when you look at the actual binary encoding of Scripts, because the way to have a literal like "68656c6c6f20776f726c64" in Script is through what you call OP_PUSHBYTES_11. It's a stretch to call it an opcode even: it's simply a specific byte which means "the next 11 bytes in the Script encoding are a literal that is to be pushed onto the stack". If you'd drop that byte, the bytes of your literal would instead be interpreted as opcodes, resulting in OP_RETURN OP_ENDIF (invalid) OP_FROMALTSTACK OP_FROMALTSTACK (invalid) (unfinished push of 32 bytes).

There are multiple ways to write Scripts in human-readable form, but for example Bitcoin Core's disassembler will denote your script as OP_RETURN 68656c6c6f20776f726c64. The byte corresponding to what you call OP_PUSHBYTES_11 is implicit in the length of the hex string that follows.

Also note that all of this is completely unrelated to OP_RETURN. OP_RETURN is typically followed by a byte push like this, but it does not have to be. And the rules for how to encode byte pushes in Script apply always, whether the push follows an OP_RETURN or something else.

Answer 3

It is not necessary for a data push to follow an OP_RETURN.

By consensus, it is not required that an OP_RETURN be followed by a data push. Encountering an OP_RETURN stops Script execution immediately with an error.

By standardness, a transaction may contain a single output with a bare script starting with an OP_RETURN. This OP_RETURN needs not be followed by a data push.

Answer 4

Script Notation:

OP_RETURN <11 bytes hexadecimal>

and

OP_RETURN PUSH_BYTES_11 <11 bytes hexadecimal>

are synonyms.

They both translate to 0x6a0b<11 bytes hexadecimal>.

I didn't know this when I asked the question...

---

Standardness of arbitrary bytes following OP_RETURN

For clarity, my question should have been:

Does 0x6a<any_bytes> in a ScriptPubKey, where the first byte of <any_bytes> is not the correct PUSH_BYTES value, mean that the resulting transaction is 1. non-standard or 2. non-consensus-valid?

1. Yes, it would be non-standard (not accepted to mempool/not forwarded by nodes).

2. No, it would be consensus valid (acceptable if seen in an otherwise valid block) so long as the ScriptPubKey like this was <10000 bytes.

---

_{Credit to Pieter Wuille's answers/comments. I wrote this to help me get to grips with it!}