<p>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.</p>
<p>I'm going to change the literals in your question a bit for simplicity, and try to answer the question:</p>
<blockquote>
<p>I see an output with scriptPubKey <code>OP_RETURN OP_PUSHBYTES_3 686c77</code>. Would an output with scriptPubKey <code>OP_RETURN 686c77</code> also be valid and/or standard?</p>
</blockquote>
<p>The first point is that in your notation, the string <code>OP_RETURN 686c77</code> 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.</p>
<p>For background, the script <code>OP_RETURN OP_PUSHBYTES_3 686c77</code> corresponds the script bytes whose hex encoding is <code>6a03686c77</code> (<code>6a</code> being <code>OP_RETURN</code>, and <code>03</code> being <code>OP_PUSHBYTES_3</code>). My assumption is that what you mean by <code>OP_RETURN 686c77</code> is the script whose hex bytes are <code>6a686c77</code>, i.e., the same bytes as before, but with the <code>OP_PUSHBYTES_3</code> byte dropped.</p>
<p>However, those script bytes would not be denoted <code>OP_RETURN 686c77</code>. It would be denoted <code>OP_RETURN OP_ENDIF OP_FROMALTSTACK OP_NIP</code> (because without the <code>03</code> bytes, the 3 bytes that follow are interpreted as opcodes, rather than as a literal).</p>
<p><strong>If your question is about the script <code>OP_RETURN OP_ENDIF OP_FROMALTSTACK OP_NIP</code> (hex <code>6a686c77</code>)</strong>, the answer is that by consensus rules this output is valid (even though it has an <code>OP_ENDIF</code> without corresponding <code>OP_IF</code>!) 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 <code>OP_RETURN</code> is only followed by pushes, not by other opcodes.</p>
<p>To add to the confusion, there exist other human-readable notations for Script, including a common one which just never uses <code>OP_PUSHBYTES_xx</code>. In the Bitcoin Core notation, the script whose hex bytes are <code>6a03686c77</code> is simply denoted <code>OP_RETURN 686c77</code> (with the <code>03</code> byte, and the pushing, implicit in the hex constant). So if you ask about <code>OP_RETURN 686c77</code>, 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.</p>

CC BY-SA 4.0
2024-06-27T15:06:12.810Z
Another valuable answer! I was not aware of the intricacies around notation. Had I been, I'd have perhaps used all hex in the question. I.e. Is  `6a68656c6c6f20776f726c64` a non-standard but valid output scriptPubKey, and is it practically equivalent to `6a0b68656c6c6f20776f726c64`? The last section of your answer covers that and I'm glad of the grey-matter upgrade from the rest.
Lee
CC BY-SA 4.0
2024-06-27T14:46:07.117Z
2024-06-27T14:53:10.183Z
2024-06-27T14:53:10.183Z
Pieter Wuille
<p>This is a notational issue, resulting from how you're choosing to write the Scripts in readable form.</p>
<p>This question simply makes no sense when you look at the actual binary encoding of Scripts, because the way to have a literal like &quot;68656c6c6f20776f726c64&quot; in Script <strong>is</strong> through what you call <code>OP_PUSHBYTES_11</code>. It's a stretch to call it an opcode even: it's simply a specific byte which means &quot;the next 11 bytes in the Script encoding are a literal that is to be pushed onto the stack&quot;. If you'd drop that byte, the bytes of your literal would instead be interpreted as opcodes, resulting in <code>OP_RETURN OP_ENDIF (invalid) OP_FROMALTSTACK OP_FROMALTSTACK (invalid) (unfinished push of 32 bytes)</code>.</p>
<p>There are multiple ways to write Scripts in human-readable form, but for example Bitcoin Core's disassembler will denote your script as <code>OP_RETURN 68656c6c6f20776f726c64</code>. The byte corresponding to what you call <code>OP_PUSHBYTES_11</code> is implicit in the length of the hex string that follows.</p>
<p>Also note that all of this is completely unrelated to <code>OP_RETURN</code>. <code>OP_RETURN</code> 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 <code>OP_RETURN</code> or something else.</p>

CC BY-SA 4.0
2024-06-27T13:44:40.770Z
Yeah, there is a number of questions mentioning an `OP_PUSHBYTES_X` and i believe it is because they use `rust-bitcoin` which names the size prefixes this way: https://github.com/rust-bitcoin/rust-bitcoin/blob/554a5eb40c94cc7de7a42903cc7ae2fbc2bbd73a/bitcoin/src/blockdata/opcodes.rs#L77-L337.
Antoine Poinsot
CC BY-SA 4.0
2024-06-27T13:51:49.027Z
Would say a coinbase tx (non-standard tx) with an output of `OP_RETURN 68656c6c6f20776f726c64` be accepted by a node (assuming work threshold is met)?
Lee
CC BY-SA 4.0
2024-06-27T13:53:53.963Z
@Lee I think you're missing the point. `OP_RETURN 68656c6c6f20776f726c64` is **exactly** the same script as what you're calling `OP_RETURN OP_PUSHBYTES_11 68656c6c6f20776f726c64`, so yes. The difference is just how we're choosing to write that script in human-readable notation.
Pieter Wuille
CC BY-SA 4.0
2024-06-27T14:00:12.307Z
Yes, I'm not getting it yet! Wouldn't the script be `OP_RETURN 0b68656c6c6f20776f726c64` with the `OP_PUSHBYTES_11` being `0b`?
Lee
CC BY-SA 4.0
2024-06-27T14:12:13.297Z
Got it; all bytes after `OP_RETURN` are arbitrary (up to size specified in the output's ScriptPubKey Size field). One may add a PUSHBYTES byte as a courtesy to future readers/parsers, but its irrelevant to Bitcoin Core.
Lee
CC BY-SA 4.0
2024-06-27T14:18:36.793Z
See my updated answer, no the **byte** is absolutely not optional. It is just that in some ways of writing the script an `OP_PUSHBYTES_11` is emitted for it, and in others it's not (because it is implied by the fact that a hex character string follows).
Pieter Wuille
CC BY-SA 4.0
2024-06-28T04:01:17.407Z
@Lee The script `6a0b68656c6c6f20776f726c64` contains two operations: `6a` (`OP_RETURN`) and `0b68656c6c6f20776f726c64` (`OP_PUSHBYTES_11` followed by 11 bytes of data.) The `OP_PUSHBYTES_11` is always there; it's just a question of how you display the script. In the more explicit style of displaying it, you show the `OP_PUSHBYTES_NN`, followed by NN bytes of data. In the less explicit style, you can just show the data; if you have 11 bytes of data, that ALWAYS means there is an `OP_PUSHBYTES_11`, so you don't really need to show it. But both ways, it's the same script with the same opcodes.
Glenn Willen
CC BY-SA 4.0
2024-06-28T04:02:11.157Z
It's slightly silly that there are two different ways people display the same script, but it's not ambiguous (because data in a script ALWAYS requires a push opcode, and you can tell which one just by looking at the data.)
Glenn Willen
CC BY-SA 4.0
2024-06-28T05:25:07.807Z
@GlennWillen always from a standardness point of view (tx accepted to mempool, forwarded by nodes). From a consensus (valid only if found in mined block) viewpoint it could, I think, be omitted.
Lee
CC BY-SA 4.0
2024-06-27T13:41:15.020Z
2024-06-27T13:47:15.187Z
2024-06-27T13:47:15.187Z
Pieter Wuille
<p>It is not necessary for a data push to follow an <code>OP_RETURN</code>.</p>
<p>By consensus, it is not required that an <code>OP_RETURN</code> be followed by a data push. Encountering an <code>OP_RETURN</code> stops Script execution immediately with an error.</p>
<p>By standardness, a transaction may contain a single output with a bare script starting with an <code>OP_RETURN</code>. This <code>OP_RETURN</code> needs not be followed by a data push.</p>

CC BY-SA 4.0
2024-06-27T13:38:29.647Z
2024-07-01T08:53:22.787Z
2024-07-01T08:53:22.787Z
Antoine Poinsot
<p><strong>Script Notation:</strong></p>
<p><code>OP_RETURN &lt;11 bytes hexadecimal&gt;</code></p>
<p>and</p>
<p><code>OP_RETURN PUSH_BYTES_11 &lt;11 bytes hexadecimal&gt;</code></p>
<p>are synonyms.</p>
<p>They both translate to <code>0x6a0b&lt;11 bytes hexadecimal&gt;</code>.</p>
<p>I didn't know this when I asked the question...</p>
<hr />
<p><strong>Standardness of arbitrary bytes following OP_RETURN</strong></p>
<p>For clarity, my question should have been:</p>
<p>Does <code>0x6a&lt;any_bytes&gt;</code> in a ScriptPubKey, where the first byte of <code>&lt;any_bytes&gt;</code> is <em>not</em> the correct <code>PUSH_BYTES</code> value,  mean that the resulting transaction is <strong>1.</strong> non-standard or <strong>2.</strong> non-consensus-valid?</p>
<p><strong>1.</strong> Yes, it would be non-standard (not accepted to mempool/not forwarded by nodes).</p>
<p><strong>2.</strong> No, it would be consensus valid (acceptable if seen in an otherwise valid block) so long as the ScriptPubKey like this was &lt;10000 bytes.</p>
<hr />
<p><sub>Credit to Pieter Wuille's answers/comments. I wrote this to help me get to grips with it!</sub></p>

CC BY-SA 4.0
2024-06-28T05:22:16.563Z
2024-07-09T11:55:14.433Z
2024-07-09T11:55:14.433Z
Lee
<p>Is the <code>OP_PUSHBYTES</code> opcode always expected after <code>OP_RETURN</code>?</p>
<p>For instance, <a href="https://learnmeabitcoin.com/explorer/tx/6dfb16dd580698242bcfd8e433d557ed8c642272a368894de27292a8844a4e75#output-2" rel="nofollow noreferrer">the 2nd output of transaction <code>6dfb16dd580698242bcfd8e433d557ed8c642272a368894de27292a8844a4e75</code></a> is:</p>
<pre><code>OP_RETURN
OP_PUSHBYTES_11
68656c6c6f20776f726c64
</code></pre>
<p>Would</p>
<pre><code>OP_RETURN
68656c6c6f20776f726c64
</code></pre>
<p>work just as well? If not, where in the bitcoin core source code is the requirement for the OP_PUSHBYTES code enforced?</p>
<p>Is there a difference in requirement here (aside from the 80 byte limit) between <a href="https://bitcoin.stackexchange.com/a/122859/34190">standard and non-standard transactions</a>?</p>
<p>From <a href="https://en.bitcoin.it/wiki/Script#Flow_control" rel="nofollow noreferrer">bitcoin.it</a>, it seems <code>OP_PUSHBYTES</code> is not required but I've not yet found an example main net transaction without one.</p>

CC BY-SA 4.0
2024-07-09T12:51:12.687Z
Related: [If no push opcode, how does item still end up on stack](https://bitcoin.stackexchange.com/a/121985/13866)
RedGrittyBrick
<bitcoin-core><script><op-return>
Is the OP_PUSHBYTES_X opcode always required after OP_RETURN?
Lee
# Is the OP_PUSHBYTES_X opcode always required after OP_RETURN?

(Asked by: username_0 on 2024-06-27)

Is the `OP_PUSHBYTES` opcode always expected after `OP_RETURN`?

For instance, [the 2nd output of transaction `6dfb16dd580698242bcfd8e433d557ed8c642272a368894de27292a8844a4e75`](https://learnmeabitcoin.com/explorer/tx/6dfb16dd580698242bcfd8e433d557ed8c642272a368894de27292a8844a4e75#output-2) 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](https://bitcoin.stackexchange.com/a/122859/34190)?

From [bitcoin.it](https://en.bitcoin.it/wiki/Script#Flow_control), it seems `OP_PUSHBYTES` is not required but I've not yet found an example main net transaction without one.

**Tags:** bitcoin-core, script, op-return

> **Comments:**
> **username_1**: Related: [If no push opcode, how does item still end up on stack](https://bitcoin.stackexchange.com/a/121985/13866)  

---

## 4 answers

### Answer by username_2 on 2024-06-27. Score: 2 | Accepted answer

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.

> **Comments:**
> **username_0**: Another valuable answer! I was not aware of the intricacies around notation. Had I been, I'd have perhaps used all hex in the question. I.e. Is  `6a68656c6c6f20776f726c64` a non-standard but valid output scriptPubKey, and is it practically equivalent to `6a0b68656c6c6f20776f726c64`? The last section of your answer covers that and I'm glad of the grey-matter upgrade from the rest.  

---

### Answer by username_2 on 2024-06-27. Score: 3

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.

> **Comments:**
> **username_3**: Yeah, there is a number of questions mentioning an `OP_PUSHBYTES_X` and i believe it is because they use `rust-bitcoin` which names the size prefixes this way: https://github.com/rust-bitcoin/rust-bitcoin/blob/554a5eb40c94cc7de7a42903cc7ae2fbc2bbd73a/bitcoin/src/blockdata/opcodes.rs#L77-L337.  
> **username_0**: Would say a coinbase tx (non-standard tx) with an output of `OP_RETURN 68656c6c6f20776f726c64` be accepted by a node (assuming work threshold is met)?  
> **username_2**: @username_0 I think you're missing the point. `OP_RETURN 68656c6c6f20776f726c64` is **exactly** the same script as what you're calling `OP_RETURN OP_PUSHBYTES_11 68656c6c6f20776f726c64`, so yes. The difference is just how we're choosing to write that script in human-readable notation.  
> **username_0**: Yes, I'm not getting it yet! Wouldn't the script be `OP_RETURN 0b68656c6c6f20776f726c64` with the `OP_PUSHBYTES_11` being `0b`?  
> **username_0**: Got it; all bytes after `OP_RETURN` are arbitrary (up to size specified in the output's ScriptPubKey Size field). One may add a PUSHBYTES byte as a courtesy to future readers/parsers, but its irrelevant to Bitcoin Core.  
> **username_2**: See my updated answer, no the **byte** is absolutely not optional. It is just that in some ways of writing the script an `OP_PUSHBYTES_11` is emitted for it, and in others it's not (because it is implied by the fact that a hex character string follows).  
> **username_4**: @username_0 The script `6a0b68656c6c6f20776f726c64` contains two operations: `6a` (`OP_RETURN`) and `0b68656c6c6f20776f726c64` (`OP_PUSHBYTES_11` followed by 11 bytes of data.) The `OP_PUSHBYTES_11` is always there; it's just a question of how you display the script. In the more explicit style of displaying it, you show the `OP_PUSHBYTES_NN`, followed by NN bytes of data. In the less explicit style, you can just show the data; if you have 11 bytes of data, that ALWAYS means there is an `OP_PUSHBYTES_11`, so you don't really need to show it. But both ways, it's the same script with the same opcodes.  
> **username_4**: It's slightly silly that there are two different ways people display the same script, but it's not ambiguous (because data in a script ALWAYS requires a push opcode, and you can tell which one just by looking at the data.)  
> **username_0**: @username_4 always from a standardness point of view (tx accepted to mempool, forwarded by nodes). From a consensus (valid only if found in mined block) viewpoint it could, I think, be omitted.  

---

### Answer by username_3 on 2024-06-27. Score: 2

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 by username_0 on 2024-06-28. Score: 1

**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 username_2 username_2's answers/comments. I wrote this to help me get to grips with it!


---

