<blockquote>
<p><strong>What is OP_RETURN_252?</strong></p>
</blockquote>
<p>Here's my guess:</p>
<p>The input in a coinbase transaction is meaningless. The input's unlocking script (scriptSig) can never be executed. So it is never checked for validity. It is only used by miners, as a byte array, to record some private information which has no purpose for the rest of the Bitcoin network (but see note below about BIP34 height in coinbase).</p>
<p>Opcodes between 185 (OP_NOP10) and 253 (OP_PUBKEYHASH) are undefined.</p>
<p>I think the parser used by the mempool.space website has foolishly been asked to produce a disassembled opcode interpretation of the bytes in a meaningless locking script in an input in a coinbase transaction. It arbitrarily assigns the fictitious name OP_RETURN_186 through OP_RETURN_252 to bytes in the range 186-252 which occur at a point in a script where an opcode would be expected in a non-coinbase unlocking script.</p>
<p>I guess they chose names beginning with OP_RETURN, and making these codes a kind of synonym of OP_RETURN, so that the beleaguered parser is relieved of any obligation to parse the following bytes.</p>
<p>I would ignore the gibberish produced by mempool.space for a coinbase input.</p>
<hr />
<blockquote>
<p><strong>Is there some official documentation about these somewhere?</strong></p>
</blockquote>
<p>No.</p>
<p>Partly because Bitcoin has no officials to officiate official lists.</p>
<hr />
<h2>Coinbase input</h2>
<p><sup>(Notes from comments by <a href="https://bitcoin.stackexchange.com/users/208/pieter-wuille">PW</a> imported here for greater prominence)</sup></p>
<blockquote>
<p>Coinbase inputs are not scripts - they're just byte arrays. They're never executed, so it doesn't actually matter that they contain gibberish.</p>
</blockquote>
<blockquote>
<p>Coinbases must have exactly one input (no idea why, it's just a rule that has always existed), and since BIP34 (height-in-coinbase, introduced in 2012), the coinbase input's scriptSig must start with the script bytes corresponding to pushing the block's height onto the stack. The bytes after that push are still allowed to be gibberish however. There is also a rule that has always existed that the coinbase input scriptSig must be at most 100 bytes long (and at least 2, though that's implied now by its height push).</p>
</blockquote>

CC BY-SA 4.0
2022-11-23T15:40:29.677Z
Yeah, coinbase inputs are not scripts - they're just byte arrays. They're never executed, so it doesn't actually matter that they contain gibberish.
Pieter Wuille
CC BY-SA 4.0
2022-11-23T15:57:25.443Z
Guys, this conversation has been very enlightning and appreciated. Thank you very much.
RooSoft
CC BY-SA 4.0
2022-11-23T16:04:23.913Z
Oh one nit: coinbases must have *exactly* one input (no idea why, it's just a rule that has always existed), and since BIP34 (height-in-coinbase, introduced in 2012), the coinbase input's scriptSig must start with the script bytes corresponding to pushing the block's height onto the stack. The bytes after that push are still allowed to be gibberish however. There is also a rule that has always existed that the coinbase input scriptSig must be at most 100 bytes long (and at least 2, though that's implied now by its height push).
Pieter Wuille
CC BY-SA 4.0
2022-11-23T16:18:18.003Z
@Pieter: Thanks, answer adjusted accordingly.
RedGrittyBrick
CC BY-SA 4.0
2022-11-23T15:33:49.210Z
2022-11-23T16:31:05.830Z
2022-11-23T16:31:05.830Z
RedGrittyBrick
<p>The first scriptsig opcode in <a href="https://mempool.space/tx/50cfd3361f7162b3c0c00dacd3d0e4ddf61e8ec0c51bfa54c4ca0e61876810a9" rel="nofollow noreferrer">this coinbase transaction</a> is <code>OP_RETURN_252</code>, followed a bit later by a <code>OP_RETURN_188</code>.</p>
<p>These don't show in <a href="https://en.bitcoin.it/wiki/Script#Stack" rel="nofollow noreferrer">this list of opcodes</a>.</p>
<p>Digging the internet, I found this <a href="https://www.wpsoftware.net/rustdoc/bitcoin/blockdata/opcodes/all/constant.OP_RETURN_186.html" rel="nofollow noreferrer">rust lib</a> that has a bunch of these, starting from <code>OP_RETURN_186</code> up to <code>OP_RETURN_255</code>.</p>
<p>Is there some official documentation about these somewhere?</p>

<script><opcodes><rust-bitcoin>
What is OP_RETURN_252?
RooSoft
# What is OP_RETURN_252?

(Asked by: username_0 on 2022-11-23)

The first scriptsig opcode in [this coinbase transaction](https://mempool.space/tx/50cfd3361f7162b3c0c00dacd3d0e4ddf61e8ec0c51bfa54c4ca0e61876810a9) is `OP_RETURN_252`, followed a bit later by a `OP_RETURN_188`.

These don't show in [this list of opcodes](https://en.bitcoin.it/wiki/Script#Stack).

Digging the internet, I found this [rust lib](https://www.wpsoftware.net/rustdoc/bitcoin/blockdata/opcodes/all/constant.OP_RETURN_186.html) that has a bunch of these, starting from `OP_RETURN_186` up to `OP_RETURN_255`.

Is there some official documentation about these somewhere?

**Tags:** script, opcodes, rust-bitcoin


---

## 1 answers

### Answer by username_1 on 2022-11-23. Score: 4 | Accepted answer

> **What is OP\_RETURN\_252?**

Here's my guess:

The input in a coinbase transaction is meaningless. The input's unlocking script (scriptSig) can never be executed. So it is never checked for validity. It is only used by miners, as a byte array, to record some private information which has no purpose for the rest of the Bitcoin network (but see note below about BIP34 height in coinbase).

Opcodes between 185 (OP\_NOP10) and 253 (OP\_PUBKEYHASH) are undefined.

I think the parser used by the mempool.space website has foolishly been asked to produce a disassembled opcode interpretation of the bytes in a meaningless locking script in an input in a coinbase transaction. It arbitrarily assigns the fictitious name OP\_RETURN\_186 through OP\_RETURN\_252 to bytes in the range 186-252 which occur at a point in a script where an opcode would be expected in a non-coinbase unlocking script.

I guess they chose names beginning with OP\_RETURN, and making these codes a kind of synonym of OP\_RETURN, so that the beleaguered parser is relieved of any obligation to parse the following bytes.

I would ignore the gibberish produced by mempool.space for a coinbase input.

---

> **Is there some official documentation about these somewhere?**

No.

Partly because Bitcoin has no officials to officiate official lists.

---

## Coinbase input

(Notes from comments by [PW](https://bitcoin.stackexchange.com/users/208/username_2-username_2) imported here for greater prominence)

> Coinbase inputs are not scripts - they're just byte arrays. They're never executed, so it doesn't actually matter that they contain gibberish.

> Coinbases must have exactly one input (no idea why, it's just a rule that has always existed), and since BIP34 (height-in-coinbase, introduced in 2012), the coinbase input's scriptSig must start with the script bytes corresponding to pushing the block's height onto the stack. The bytes after that push are still allowed to be gibberish however. There is also a rule that has always existed that the coinbase input scriptSig must be at most 100 bytes long (and at least 2, though that's implied now by its height push).

> **Comments:**
> **username_2**: Yeah, coinbase inputs are not scripts - they're just byte arrays. They're never executed, so it doesn't actually matter that they contain gibberish.  
> **username_0**: Guys, this conversation has been very enlightning and appreciated. Thank you very much.  
> **username_2**: Oh one nit: coinbases must have *exactly* one input (no idea why, it's just a rule that has always existed), and since BIP34 (height-in-coinbase, introduced in 2012), the coinbase input's scriptSig must start with the script bytes corresponding to pushing the block's height onto the stack. The bytes after that push are still allowed to be gibberish however. There is also a rule that has always existed that the coinbase input scriptSig must be at most 100 bytes long (and at least 2, though that's implied now by its height push).  
> **username_1**: @username_2: Thanks, answer adjusted accordingly.  

---

