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

pull jgarzik wants to merge 1 commits into bitcoin:master from jgarzik:2014_op_return2 changing 2 files +15 −5

jgarzik commented at 6:17 pm on October 10, 2014: contributor

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.

Relay up to two (2) OP_RETURN outputs as IsStandard

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

d051ffa6d5

sipa commented at 6:45 pm on October 10, 2014: member

I see no consensus for this.
TheBlueMatt commented at 7:24 am on October 11, 2014: member

Consensus where? Links?
laanwj commented at 7:57 am on October 11, 2014: member

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…
gmaxwell commented at 8:03 am on October 11, 2014: contributor

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…
TheBlueMatt commented at 8:19 am on October 11, 2014: member

Yes, I think this should be discussed on the ML first.
sipa commented at 7:04 pm on October 13, 2014: member

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.
jgarzik commented at 7:17 pm on October 13, 2014: contributor

We definitely have a few use cases for embedding some block headers.
sipa commented at 7:23 pm on October 13, 2014: member

I would like to see some examples of that. Convenience is not a good reason, IMHO.
petertodd commented at 8:20 pm on October 13, 2014: contributor

@jgarzik Block headers? Why?
luke-jr commented at 9:29 pm on October 13, 2014: member

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).
petertodd commented at 11:14 am on October 14, 2014: contributor

@luke-jr I was discussing the use-case for multiple OP_RETURNs the other day with a client working on colored coins.
laanwj added the label P2P on Oct 22, 2014
Flavien commented at 5:38 pm on November 12, 2014: contributor

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.
luke-jr commented at 5:55 pm on November 12, 2014: member

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.
petertodd commented at 6:04 pm on November 12, 2014: contributor

@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.
NicolasDorier commented at 7:50 pm on November 16, 2014: contributor

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.
jgarzik commented at 11:52 am on December 31, 2014: contributor

Closing. Other proposals seem to be preferred.
jgarzik closed this on Dec 31, 2014
MarcoFalke locked this on Sep 8, 2021

Contributors
jgarzik sipa TheBlueMatt laanwj gmaxwell petertodd luke-jr Flavien NicolasDorier

Labels
P2P