I’m taking the structure/content of this whole cloth from Jonathan Silverblood’s excellent comment Brainstorm Multiple OP_RETURNs. Will add my own comments & information below.
Description in a couple sentences what the change is technically
Change in either standardness rules regarding OP_RETURN to allow multiple outputs with OP_RETURN in the same transaction, or change in interpretation of OP_RETURN itself to use it as a separator within the same OP_RETURN output.
Problem it’s trying to solve
Making OP_RETURN based protocols interoperable.
Potential positive impact on ecosystem
By supporting multiple OP_RETURNs in a way that makes it possible to have interoperable OP_RETURN protocols, we signal to developers that are interested in making such protocol that BCH desires their business. This would allow new usecases as well as empower existing usecases, ultimately working towards more adoption and a stronger network effect for BCH.
Potential negative impact on ecosystem
Depending on developer preference, could be a point of contention.
Depending on implementation, could end up encouraging more data storage on-chain.
Depending on implementation, could disrupt existing OP_RETURN based protocols or tooling.
— end of quote —
My team has been building an auction system using a combination of SLP NFTs & FTs over the last few months. The intention is that participants in the auction and those who will receive its proceeds should be able to reconstruct the entire auction with nothing more than an understanding of the protocol and access to the BCH block chain history. We have implemented a functioning back end and are now working on a nice GUI to be able to launch this for the public. However, two aspects of the protocol require additional information to be added, presumably via additional OP_RETURNs, in order to meet its goals. Therefore, we would not be able to run this on BCH and meet our goals until the BCH protocol is upgraded to handle this.
You can find the details of our Auction Protocol Specification here: BCH/SLP Auction Protocol Specification.
The aspects of the protocol that use additional OP_RETURNs are the auction metadata (Action Denomination & Total Winners) outputs for Figure 2 and the Bidder Return address output in Figure 5. Otherwise we’re a compliant but unusual combination of SLP NFTs & FTs. In the Limitations section we discuss existing challenges with BCH protocol and implementations that we’re having to work around. The single OP_RETURN limitation is the only one that is a blocker for our ability to fully meet our protocol’s goal.
Prior to the last November fork I reached out wherever I could to get feedback about support for multiple OP_RETURNs. The only push back I received was concern about making transactions too large. Our proposal recommends that whatever the limit impose on OP_RETURN size simply be applied in aggregate for the sum total of all OP_RETURNs. As it was too close to November and other events were quite distracting for that fork it was clear that it needed to wait until the next fork to be seriously considered for inclusion.
We would like to see that size increased some but the current limits are not blockers for our existing protocol.
Having a restriction of a single logical OP_RETURN imposes significant limits in our ability to test out new protocols easily. Hopefully the general BCH dev community agrees and would be willing to make this part of the upcoming May fork. Please feel free to reach out to me here or on Telegram as @proteusguy or our own project support channel on Gitter if you have any comments/questions.