So, I've been digging into OP_RETURN. I get that there's a lot of debate around it, and I know you can tweak the max size to send it in bitcoin knots, but what's the actual limit that could make a block with it totally bogus? I was initially focusing on what’s allowed in the coinbase transaction of a block, but honestly, I'm not even sure if that's the main thing to consider. I got really mixed up trying to pin down the exact size. Like, I thought the max was 80 bytes based on the bitcoin developer guide, but then I see other places saying it’s 75 or even 40. Those last ones seem super outdated. Then I came across this hash d29c9c0e8e4d2a9790922af73f0b8d51f0bd4bb19940d9cf910ead8fbe85bc9b which looks like it breaks any rules. So, is there a limit that could render a transaction invalid, and in turn, invalidate any block that has it?
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.
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.
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).
It would happen only when transaction size would exceed the maximum block size, or when OP_RETURN will be executed in witness space.
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.
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.
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.
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.
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.
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.