BUIP149: Delimited OP_RETURNs

[Jonathan Silverblood]

BUIP149: Delimited OP_RETURNs
Submitted by: Jonathan Silverblood
Date: 2020/06/27

Status: DRAFT PROPOSAL


Summary
The purpose of this BUIP is to get a commitment from Bitcoin Unlimited to support a proposal to change how OP_RETURN functions within Bitcoin Cash.


Proposals
I propose that we raise the OP_RETURN size limitation and rework the OP_RETURN opcode, so that instead of being used only as the first opcode of an OP_RETURN output, it:

- Can be used more than once within an OP_RETURN output.
- Every time it is used it acts as a delimiter that makes the following push operations semantically grouped.
- Every time it is used, it limits how much data can be pushed after it.

This means that old OP_RETURN transactions will be parsed exactly the same as new ones (since the old only have one OP_RETURN opcode), which makes the old transactions forward-compatible. This also means that it becomes possible to use more than one OP_RETURN based protocol within a single transaction. By also having a limitation on how much data can be pushed, we can structurally prevent a situation where some protocol would make itself incompatible with any other by accident.

I propose that we raise the OP_RETURN size limitation to 512b or 1024b and that we make the max size between OP_RETURNS either 255b or 511b respectively, to guarantee that any two protocols will always work together.

The numbers are provided as an example for discussion and to set a ballpark of what the expectations are, but should not be seen as a requirement for this proposal.


Motivation
By commiting to support this change of OP_RETURN functionality, Bitcoin Unlimited would send a signal to other node software developers that this is something that is possible to change under consensus and would help start the necessary discussions in the community.


Background
With the expanse of OP_RETURN based protocols and the widespread adoption of SLP tokens there is a need to enable cross-protocol collaboration. We cannot predict all possible usecases for this feature, but there is already several protocols that either see a benefit to this (CashIntents with SLP) or that are working around current limitations in awkward ways (SLP and SLPDEX).


Budget
None

 

[torusJKL]

Why not allow for multiple OP_RETURN outputs in a single tx?
This is already supported by the protocol but is currently rejected by nodes because it is regarded as non-standard.

 

[Jonathan Silverblood]

Why not allow for multiple OP_RETURN outputs in a single tx?
This is already supported by the protocol but is currently rejected by nodes because it is regarded as non-standard.

There is strong sentiment against multiple op_returns by some node developers, so while I personally feel it's a cleaner solution, it's not a viable one given that it needs cooperation to be implemented. The delimiter method has support by the node devs that oppose multiiples, so may be something that can be agreed upon.

I would like to use multiple op_return based protocols together, and this does solve that need - so I'm proposing it here to see if people can and/or will rally around it.

The alternative option, sadly, is hacky workarounds - and I know that there are already people who are working in that direction.

 

[solex]

Updated to ref 149 and added to index.

 

[79b79aa8]

There is strong sentiment against multiple op_returns by some node developers

how are you gauging this sentiment?

 

[Jonathan Silverblood]

how are you gauging this sentiment?

By watching various dev channels, and in the youtube developer meetings Amaury from ABC makes it very clear that he does not want another solution, but will consider this one.

 

[theZerg]

@Jonathan Silverblood I'd be in favor of the non-consensus-change method of having multiple outputs due to the simplicity of getting from here to there, which I read that you are also in favor of. I hear from you that other devs are not in favor of that approach. But based on the one name you mentioned, I wonder if you are not being given the ol' time wasting runaround that'll drive you into a worse solution that's easier to say "no" to.

My inclination is therefore to vote "no" here and revisit this issue in Nov to see where we are. But even if this gets voted down, I would guide BU to not prevent either option from happening (without an explicit BUIP deciding that outcome), as I am interpreting this BUIP as a vote for explicit advocacy.

 

[Jonathan Silverblood]

This BUIP is currently included for voting, but BUIP139 and BUIP140 are not. This makes it appear in a way that's not impartial.

I would like to revoke this proposal entirely.

 

[torusJKL]

I have voiced my opinion early on and I'm not in favor of this BUIP.
But I don't think a BUIP should be allowed to be revoked once voting on it has begun.
We need to see how this will play out (I have the feeling that it will be rejected).

 

[Jonathan Silverblood]

I generally agree that it shouldn't be revoked after voting begins, but I think this case is exceptionally misleading and even if it is rejected the outcome will have negative impact that may not have had happened if the previous BUIPS (139, 140) was allowed to be voted on as well.

Note that neither of these buips replace one another, and all of them was put forward well in advance of the voting period. That some got included and others didn't can be chalked up to a misstake, but if so should be rectified:

Either include all of them, or include none of them.

 

[solex]

It is unfortunate there was a misunderstanding on the sequencing of these three BUIPs. As explained on telegram, the vote announcement explicitly asks for communication from proposers of draft BUIPs.

I do not think the result of 149 will have any effect on 139 and 140, which I am sure will be decided upon by the membership on their technical merits alone. A vote will be scheduled for a date soon after the next BCH upgrade. This, we know, has an uncertain outcome, due to ABC deciding to code their IFP tax such that it can fork them off the BCH blockchain and split the network just they have split the community once again. Hence, membership direction may be needed on any issue arising from the 15 November upgrade,