New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
9 participants
@jgarzik
Copy link
Contributor

jgarzik commented Oct 10, 2014

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.

Jeff Garzik
Relay up to two (2) OP_RETURN outputs as IsStandard
Consensus seems to be that 40 is too small, but 80 should be enough.
@sipa

This comment has been minimized.

Copy link
Member

sipa commented Oct 10, 2014

I see no consensus for this.

@TheBlueMatt

This comment has been minimized.

Copy link
Contributor

TheBlueMatt commented Oct 11, 2014

Consensus where? Links?

@laanwj

This comment has been minimized.

Copy link
Member

laanwj commented Oct 11, 2014

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

This comment has been minimized.

Copy link
Member

gmaxwell commented Oct 11, 2014

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

This comment has been minimized.

Copy link
Contributor

TheBlueMatt commented Oct 11, 2014

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

@sipa

This comment has been minimized.

Copy link
Member

sipa commented Oct 13, 2014

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

This comment has been minimized.

Copy link
Contributor

jgarzik commented Oct 13, 2014

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

@sipa

This comment has been minimized.

Copy link
Member

sipa commented Oct 13, 2014

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

@petertodd

This comment has been minimized.

Copy link
Contributor

petertodd commented Oct 13, 2014

@jgarzik Block headers? Why?

@luke-jr

This comment has been minimized.

Copy link
Member

luke-jr commented Oct 13, 2014

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

This comment has been minimized.

Copy link
Contributor

petertodd commented Oct 14, 2014

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

@laanwj laanwj added the P2P label Oct 22, 2014

@Flavien

This comment has been minimized.

Copy link
Contributor

Flavien commented Nov 12, 2014

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

This comment has been minimized.

Copy link
Member

luke-jr commented Nov 12, 2014

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

This comment has been minimized.

Copy link
Contributor

petertodd commented Nov 12, 2014

@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

This comment has been minimized.

Copy link
Member

NicolasDorier commented Nov 16, 2014

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

This comment has been minimized.

Copy link
Contributor

jgarzik commented Dec 31, 2014

Closing. Other proposals seem to be preferred.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment