The limit is 220 bytes of data for an op_return. The extra 3 bytes are 1 for the op_return opcode and 2 for the push opcodes.

I didn't check if the node would reject a 222 bytes op_return (I doubt it) but it might make more sense to limit to 220 in the URI and add the push opcode ourselves, as it's commonly done on the network already

This is also a good point for the implicit push. There is no reason you can't push some arbitrary data starting with 0x6a

I'm not sure about this restriction. To me it makes sense to either accept any arbitrary data (including weird stuff like OP_RETURN "6a6a6a") or else be even more restrictive by forcing the data to start with a push operator (anything in range "00" -- "4c").

I wrote this before seeing Fabien's review. Similar concern.

Feedback here is good. I'm thinking it might be more direct though to change the spec and require the opreturn= param to be fully formed and valid opreturn, i.e. starting with 6a, and simply use the 220+3 max.

Originally I figured including the 6a was a waste, as the 6a is implied by the opreturn=. However I don't think there's really a byte limit concern with URI creation, and not including the 6a creates more complications (validation functions need to specifically ignore it, whatever code being used to generate the URI is probably also having to slice off the 6a to comply with the spec, only for all wallet software to then have to add it back on before broadcasting).

If we are going to add our own opcodes -- imo not a bad appraoch -- spec does need to be quite different and more complicated, something like opreturn=true&pushCount=3&encoding=utf8&push1=xxxx&push2=xxxx&push3=xxx ... this type of approach would make it easier(ish) for non-developers to create opreturn URIs. imo tho we could expand to add this if there is demand, but starting with a one-param, always hex, always valid opreturn is the simplest.

I'm assuming the main use for this is creating very specific OP_RETURN outputs that can be indexed or tracked somehow by their creator, so requiring the hex to be "the exact thing" is the best first step.

OK following discussion

• We want to keep it so that app dev pushes 6a, so that this param can always only be an OP_RETURN
• Keep param to one string

Validation function here is for Cashtab convenience, i.e. I don't want to be broadcasting something to the node that I know will be rejected there. So we validate for valid OP_RETURN string before broadcasting the tx.

In this case, it would be invalid. We can push 6a arbitrarily if we like -- but it needs its own pushdata, which will not be 6a. So, we do want this test.

or else be even more restrictive by forcing the data to start with a push operator (anything in range "00" -- "4c").

I think this is the right approach.

I originally had this omitted, but it causes the unit test for just '6a' to fail since no error is thrown.

getStackArray('6a') = []

which is expected behavior.