Why we should allow more than one OP_RETURN per transaction.

I will start off by saying that I am fully committed to the idea that we should prioritize the cash usecase and that by storing arbitrary data on chain we are reducing the ability for that usecase to scale.

That said, I believe that for us to be successful at cash we need to solve some outstanding usability problems and allow people to use cash in a way that suits them, rather than impose a fixed and strict way on everyone.

What good will come from spamming the blockchain with data?

Having the ability to store multiple sets of small data attached to transactions allows us to enrich the cash usecase by adding metadata that has properties that is otherwise difficult to achieve.

For example, consider one of the technical limitations of Bitcoin Cash today, the fact that transactions do not have a clear sender. This is relatively simple to solve by just adding an OP_RETURN to the transaction containing the senders identity and a signature by the senders key to prove that identity. To retain the privacy, this information could be encrypted.

Now this isn't a good argument for multiple OP_RETURNs in itself, since it's doable without, but what if the value you are sending is an SLP token? In that case SLP has already taken up the currently allowed OP_RETURN space and the user experience is degraded.

This empowering of the cash usecase is something I would love to see happen sooner rather than later. While multiple OP_RETURNs could be used for things that are detrimental to the cash usecase ("spamming"), retaining the existing size limits per OP_RETURN and and being careful about how we expand this functionality should help keep the various use cases in a reasonable balance.

Actual usecases

During the initial discussions I've had about this, I have frequently been asked what the actual usecases are. My answer to this is that I personally have a use for this with my CashIntents protocol, but this is not about me or my needs.

Just as it's not always easy to see the real value in exciting new things, I believe that the ability for OP_RETURN protocols to interact in a symbotic and beneficial way, like the SLP and CashIntent combination I listed earlier, is the real value here.

Having just a little bit more room for innovation here could prove to be very valuable as new developers come along with innovative ideas.

This is already a problem today

The first example where this limitation is already a problem today I found when talking about an SLP DEX developer. Since SLP is taking up the OP_RETURN, currently they already shove data they need to track with the transactions inside the transaction, but are using/abusing a different storage place for it.

I'm not saying that just because someone (like me) have an issue and could benefit from a change in this limitation, we should just go ahead and do it. What I am saying is that there's innovation to be had here if we opened up a little, and that it's time to have a healthy discussion on the subject.

What can we do about this?

In the end, this is going to come down to changing the consensus rules. The first step towards doing so should be to have a healthy discussion about it and for the involved parties to be clear about what they want to do and what they can accept.

To this end, I've submitted two improvement proposals to Bitcoin Unlimited, one that is a relatively straight forward (simply allow more), and one that has a more restrictive ruleset that keeps the total size limitation intact.