What exactly is the maximum message length in OP_RETURN?

[bitkali]

Title. I know the controversies about OP_RETURN, and how you can adjust the maximum size to be relayed in bitcoin knots, but what is the maximum amount where any block containing it would be considered simply invalid? I was originally thinking more specifically about the size allowed in the coinbase transaction of a block, but I'm not sure that matters. Either way I was very confused when trying to find the value, because I remembered that in the bitcoin developer guide, the maximum was 80 bytes, however some sources say that it's 75 or even 40 (those last ones seem to be just outdated) and there's also d29c9c0e8e4d2a9790922af73f0b8d51f0bd4bb19940d9cf910ead8fbe85bc9b  , which seems to completely defy any limit. Is there even a limit that would make a transaction invalid, and therefor make any block containing it invalid?

[Ambatman]

but what is the maximum amount where any block containing it would be considered simply invalid?

There are no consensus rule about a limit for OP Return. So it would be valid as  long as the transaction and the block containing it sticks to consensus rules.
So technically the only consensus limit we can think of is the transaction limit, 4MB for Segwit and 1MB for non Segwit.

The Standardness rule for OP return is 80 bytes of data plus 3 bytes for the script structure.
But I think it has being removed or in progress in current update to the limit of transaction size.

d29c9c0e8e4d2a9790922af73f0b8d51f0bd4bb19940d9cf910ead8fbe85bc9b  , which seems to completely defy any limit. Is there even a limit that would make a transaction in

adding to what I said above
 transactions that breaks the standardness rule can still be valid and included in a block if mined
but they are not relayed by default as long as they stick to the consensus rule.

[stwenhao]

What exactly is the maximum message length in OP_RETURN?

It is defined by the maximum size of the block. See: https://mempool.space/tx/516c63376556d87c4779033327184ee00a08c4c14498e14673357ce4a791406b

So, in practice, it is something slightly below 1 MB. And if OP_RETURN is placed in unexecuted OP_IF branch, behind P2WSH, then it can take slightly less than 4 MB (edit: only up to 10000 bytes, because of MAX_SCRIPT_SIZE).

but what is the maximum amount where any block containing it would be considered simply invalid?

It would happen only when transaction size would exceed the maximum block size, or when OP_RETURN will be executed in witness space.

because I remembered that in the bitcoin developer guide, the maximum was 80 bytes, however some sources say that it's 75 or even 40

There are standardness rules. And it is set by default to 83 bytes, where one byte is taken by OP_RETURN, and two bytes are taken to declare the size of the stack push. And if you ignore Script decoding, then in practice, you can use one byte for OP_RETURN, and 82 bytes for anything.

Edit: Some people say 75, because this is the limit for which you can declare stack push size with a single byte, and not with two bytes. Others say 40, because it was historically set to this value. And in the latest version, it is unlimited by default (and only limited by other limits, like block size limit), and can be limited only by each node operator individually.

[achow101]

There are no consensus restrictions on outputs, other than the overall block weight limit. An output can contain any opcodes, even invalid ones, and it can contain an unlimited number of them, until the block weight limit is reached. The only time an output script has any consensus validation done on it is when it is being spent.

Within the standardness rules, the upcoming v30.0 Bitcoin Core release removes the limit by default. Of course, the actual size is still bound by the transaction weight limit standardness rule of 400000 weight units, and the block weight limit if standardness is being bypassed.

[mcdouglasx]

If I'm not mistaken, I think the current maximum for op_return is dictated by MAX_SCRIPT_SIZE which is 10kb, but in theory you could mine a block that is composed of 1 transaction with multiple op_return outputs, reaching a total of about 3.99 MB between them, but you would have to do this by mining your own block since by exceeding the policy -datacarriersize=100000 this tx would not be included in the mempol.

[gmaxwell]

If I'm not mistaken, I think the current maximum for op_return is dictated by MAX_SCRIPT_SIZE which is 10kb, but in theory you could mine a block that is composed of 1 transaction with multiple op_return outputs, reaching a total of about 3.99 MB between them, but you would have to do this by mining your own block since by exceeding the policy -datacarriersize=100000 this tx would not be included in the mempol.

Mistaken.  That limit is only imposed by consensus at spending time.  FWIW the default 'daracarriersize' is just the maximum standard transaction size.

 

[Mia Chloe]

~snip

I don't think there is actually a specific maximum OP_RETURN size that on its own makes a block invalid. I think the limits you're seeing like 75, 80 and 83 bytes are standardness rules which actually determine if a transaction will be relayed by most nodes on the network or not. A transaction that exceeds these standardness limits should still be valid if it adheres to the network's consensus rules.

In my opinion I think If a miner includes a non-standard but valid transaction in a block that block remains valid and will be accepted by the network. So basically the true invalidating limit for an OP_RETURN transaction is the maximum block size and weight which is around 4 MB for SegWit blocks. If including an OP_RETURN or infact any other data causes the total size of the block to exceed this consensus limit I believe that's when the entire block becomes invalid.

[Agbamoni]

Title. I know the controversies about OP_RETURN

First OP_RETURN was formerly called 'data carrier' when it was introduced. Normally this output cant be spent and it does not have to go into the utxo database which can be pruned in most cases. The size was limited to 40 bytes because of some application reasons later it was increased to 80 bytes which we all witness these days.

Is there even a limit that would make a transaction invalid, and therefor make any block containing it invalid?

Yes, there is a limit but you should know that if a transaction has OP_RETURN output with a data that exceed the allowed size limit, that transaction is invalid.