Relay up to two (2) OP_RETURN outputs as IsStandard #5075

Consensus seems to be that 40 is too small, but 80 should be enough.

80 bytes conveniently stores another block header, serving as an anchor for another chain.

I see no consensus for this.

Consensus where? Links?

Not sure about just doubling the size, but an idea that was proposed on IRC (by @petertodd or @gmaxwell?) was to extend OP_RETURN with a specific size (say, 8 bytes) per output, so that there is place for output-specific data.

Edit: but this seems discussion more suited for the mailing list...

Would generally rather have more pushes allowed on a single op return than more op returns unless someone has a good case for more. One of the applications for larger opreturn data is for encrypted payment IDs on reuseable address payments...

Yes, I think this should be discussed on the ML first.

It's the first time I hear about this. If the consensus is to allow more data, I'd rather have one opreturn with multiple pushes though, as it's smaller in the blockchain.

Still, I'm not convinced about any use case that actually needs to store data in a transaction beyond a commitment to external data. And 32 bytes + some identification like we have now should suffice for that.

We definitely have a few use cases for embedding some block headers.

I would like to see some examples of that. Convenience is not a good reason, IMHO.

@jgarzik Block headers? Why?

I'm not aware of anyone besides Counterparty even asking for >40 bytes. Certainly never heard of two OP_RETURNs before this PR (although I think DarkWallet uses one per-output).

@luke-jr I was discussing the use-case for multiple OP_RETURNs the other day with a client working on colored coins.

It's definitely useful if you want to have a transaction using two orthogonal protocols, like colored coins + stealth addresses.

Extending OP_RETURN with a specific size per output would clearly be the best through.

Coloured coins don't need any data in the transaction itself... although I guess it's just an example.

I'd suggest extending protocols to accept multiple pushes in a single OP_RETURN - I think that's more generally agreeable.

@luke-jr Feedback from issuers has been they need more sigfigs than nValue encoding can reasonably provide. Equally in some cases being able to guarantee all transactions are public is a must. (in other cases you want the exact opposite!)

The colored coin standard I'm working on will be able to encode color amount/movement info into any PUSHDATA in the transaction specifically so we aren't tied to OP_RETURN, e.g. for sending colored coins to a stealth address. So removing restrictions on OP_RETURN will enable these protocols to avoid creating unspendable outputs in some cases.

Why not allowing whatever number of OP_RETURN (and push inside) but ensuring that the total length of the OP_RETURNs data is below 80 ?

This way, people can to encode some information per output, existing protocol would keep working unmodified, and new protocol could leverage more than 40 bytes in a single OP_RETURN if really needed.

Closing. Other proposals seem to be preferred.