2

The first scriptsig opcode in this coinbase transaction is OP_RETURN_252, followed a bit later by a OP_RETURN_188.

These don't show in this list of opcodes.

Digging the internet, I found this rust lib that has a bunch of these, starting from OP_RETURN_186 up to OP_RETURN_255.

Is there some official documentation about these somewhere?

1 Answer 1

4

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 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).

4
  • 3
    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. Commented Nov 23, 2022 at 15:40
  • Guys, this conversation has been very enlightning and appreciated. Thank you very much.
    – RooSoft
    Commented Nov 23, 2022 at 15:57
  • 4
    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). Commented Nov 23, 2022 at 16:04
  • 1
    @Pieter: Thanks, answer adjusted accordingly. Commented Nov 23, 2022 at 16:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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