CHIP 2021-03 Multiple OP_RETURNs for Bitcoin Cash

[proteusguy]

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.

Name

Multiple OP_RETURNs

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.

[Jonathan_Silverblood]

I would love to see this finally happening. I know the idea itself has significant support, but that there’s some contention on the exact details of it. For those who have strong opinions, I urge you to make one more attempt to try and find common ground - it might not end up as perfect as you would’ve wanted, but if we can just get something reasonable and safe out, I believe that would help create more adoption and more value for our users.

@proteusguy if you want to, I would recommend you to try and set up a CHIP and fill in a template like this one: Example-CHIP-Template.md · master · GeneralProtocols / Research / CHIPs · GitLab

It’s not a requirement from my end, but would function more like an aid to make sure that you’ve thought of as many of the costs, benefits and edge cases as possible, as well as reached out to those who are impacted by the change.

If you don’t, I might do it later on, but I don’t feel that I can take responsibility and ownership of multiple CHIPs at the moment.

[proteusguy]

I will look into that and see what I can do. Thanks.

[trout]

One thing I’d like to have seriously discussed when considering this topic is the tension between OP_RETURN and scaling for the cash use-case.

We are currently averaging around 300K transactions per day on the BCH network. If that number increased 1000x to 300M transactions per day, the conflict between OP_RETURN and the cash use-case would be much more acute.

In that 300M tx world, the vast majority of infrastructure will need to run on pruned nodes. Maintaining archival nodes with a full copy of the blockchain will become extremely expensive.

Rather than focus on putting more data on-chain, I’d like to see more exploration of moving data off-chain, but maintain reliable access to it.

[proteusguy]

Agree this is likely the biggest point of contention. Note that the proposal does not increase the maximum allowed transaction size at all. We’re just making OP_RETURN more flexible so devs can experiment with protocols on the BCH chain. I think this is critical for BCH to be able to evolve its implementation to ultimately fulfill its goal of being the go-to peer-to-peer decentralized currency.

My perspective of OP_RETURN is a mechanism for experimenting with new protocols. SLP is the primary example. It seems to be getting traction and demonstrating its value but it is a bit limited due to the additional complexity of deploying & operating SLP nodes due to its separation and defacto second-class citizenship on the BCH chain. Ultimately, if the community determines SLP-like tokens is a core value of BCH, it will be incorporated into the primary protocol as we’re seeing in the GROUP proposal. I believe this is a Good Thing ™ as it gives a chance for the protocol to demonstrate its value before burdening the core nodes and miners.

The business case we present (auction) is yet another example of this. If it gets traction, it will greatly improve the credibility and volume of transactions and value on BCH. If not, it will simply go away without ever impacting the core nodes or miners. This is but one of the several concepts we have on targeting distributed cryptoledgers. If dev teams like ours see that BCH is not amenable to such extensions and making successful ideas that align with the key goals of BCH first class citizens with full PoW protection then they will simply go elsewhere and BCH will lose that opportunity.

To better address your concerns (and the significant number of people who I believe rightfully share them - I do as well), I think it would be most useful if you might more clearly delineate what data you believe belongs on chain and what data you believe must remain off chain. I think consensus on that point more clearly defines the debate in a useful manner that allows us to strike a compromise that doesn’t alienate those who have current skin-in-the-game and those looking to adopt BCH and add theirs. If there’s an existing conversation thread elsewhere that covers these points I’d happily follow a link and summarize my understanding of them myself.

[trout]

To better address your concerns (and the significant number of people who I believe rightfully share them - I do as well), I think it would be most useful if you might more clearly delineate what data you believe belongs on chain and what data you believe must remain off chain.

I don’t think there is any objective answer to what data belongs on chain or should be off chain. At the current moment in history and scaling, I think BCH has struck a happy medium between the data use-case and the cash use-case. As the on-chain TX volume increases, the tension between these two use cases will increase.

At a certain scale, we need to get ALL data off-chain to avoid negative impacts to the cash use-case. It’s all a matter of scale.

I’m working on an idea for an off-chain database for storing OP_RETURN data. That would allow pruned nodes to dominate the network and give an off-chain place to store archival data. Developing this idea is not a priority for me though.

As TX volume increases on BCH, these issues will become more acute. The market will have to find some solution.

[tom]

@proteusguy

We’re just making OP_RETURN more flexible so devs can experiment with protocols on the BCH chain

The tricky part here is the balance. The first question to ask is, how does the idea of putting this on a BCH chain compare to a centralized system?

What we learned from SLP is that stuff built using op_return isn’t really decentralized. Memo, SLP and all other attempts so far are not decentralized, they just are uncensorable. Which has its worth.

So what did I say about balance? Yeah, the more stuff that is built on OP_RETURN style data, the more central servers and different indexers you will need. They are centralized because an SPV wallet can not be built that scales and is capable of doing SLP or any other such system properly. As BCH grows this problem will grow much faster. As the historical chains of SLP grow, this problem will grow too.
Bottom line, users of op-return based protocols require a trusted full node to participate, or admit that its not decentralized and simply trust some website like memo does.
Then there is no balance, its just centralized with an illusion of decentralization by association.

So, the question: what is the point of doing this on-chain? How does multiple op-returns benefit BCH?

[proteusguy]

Multiple OP_RETURNs, as I pointed out in my proposal, lets us experiment with things that would potentially be made part of the core BCH protocol in a manner that doesn’t cause problems for nodes or miners until their value is clearly justified. I think, given the current set of op codes, that’s about as far as we can go for now. However, the inclusion of future op codes, such as something that might serve an introspection capability to other tx/utxo’s, would possibly make OP_RETURNs more valuable in the context of on chain scripts. That last consideration is pure speculation and not an intention or goal on my part at this time.

The example of the value of OP_RETURNs vis-a-vis SLP I gave before is that, should SLP be seen as a core value of BCH, then it can be incorporated fully into the BCH protocol. I believe the GROUP proposal’s intention is to do just that. I haven’t had a chance to fully review the GROUP proposal to make a determination as to whether that’s the way it should be done but it does fit the model that I think works best for how we evolve BCH in a manner that encourages/enables experimentation without disrupting the key architectural components and mission of BCH. It allows new ideas to be quite fully exercised and demonstrate their value (and dangers) with fully working use cases so as to prevent a far more dangerous course of premature standardization/inclusion for half-baked but possibly popular ideas.

In the example of the use case of the AUCTION protocol that we’re implementing using SLP + multiple OP_RETURNs, the point of doing it on chain is that it allows anyone who knows the protocol to fully evaluate and reconstruct the auction and all its transactions without relying on a centralized app or having to trust that it behaved correctly and fairly. That’s a core benefit of cryptoledgers and there’s not a reasonable alternative method of doing this without a nasty hack like injecting opaque data into a multiple signature check which does increase the size of transactions that can’t be easily pruned from nodes. In the case of our AUCTION protocol, the value of the additional OP_RETURNs is only for the duration of the individual auction so there’s no harm when it eventually gets pruned except for purely historical reasons.

If this isn’t a satisfactory answer then I’d ask the counter question of what value would OP_RETURN have at all to BCH if not what I just described? There could be some as I’m still fairly new to BCH but I’m at a loss to describe what it would be. As it is today - if you want to try an extended/alternative protocol and you want it to interoperate with SLP (a quite popular protocol) then you’re out of luck because that single legit OP_RETURN is now occupied.

In terms of the question you made about balance - that’s precisely what I think this proposal achieves. OP_RETURN is an accepted opcode for BCH. It has a limited size to prevent its abuse. We keep the existing size constraint but allow it to be used more flexibly so that protocols interoperate cleanly and don’t disrupt BCH infrastructure or operations.

[proteusguy]

@trout

I don’t think there is any objective answer to what data belongs on chain or should be off chain.

I’ll go out on a limb here and partially agree with you. Absolutely the ultimate determination of what the sets of valid on-chain vs. off-chain data are subjective. However, it’s also clear that some data must objectively be on-chain and arguablly objective for some that should not. This leaves a significant subjective determination based on who the stakeholder is and what their motivations for using BCH are. I posed the question to attempt to understand yours so that I could see how closely we were already aligned and how much distance I’d need to cross to convince you.

Sounds like your perspective is the cash use case overrides all others. That’s fair. Do you then support the adoption of the GROUP proposal (or something like it) that would allow the token capabilities of SLP to be incorporated into the core protocol? I tend to lean this way but then doesn’t that add more data to the blockchain? Or do you reject that there should be any token other than BCH allowed in the blockchain and alternative currencies are distractions? That’s a position that would drive me and a lot of developers away from BCH.

My argument is that OP_RETURN is here and has a purpose that I described. Presently - and for the foreseeable near future, BCH has bandwidth to spare and would far more benefit from it being usefully used than preventing full exploitation of the protocol for fear of a future downside that may never have a chance to occur because of the core stakeholders being too conservative - the very phenomenon that I’d argue resulted in the BTC/BCH fork in the first place.

I don’t dismiss concerns about abuse of the blockchain or that in the future tx size/volume will be a problem (frankly a great problem to have) but I’m 100% confident we will be able to see it coming and do something about it in the technology space before it gets out of hand. More importantly, we don’t know what the capabilities of the technologies the BCH network depends on will be by time we are lucky enough for that inflection point to arrive.

So today we have OP_RETURN. We have a specific use case for an interesting & innovative use case for BCH/SLP that demands additional OP_RETURNs, and we don’t need to increase the legal transaction size limits by a single byte in order to fully exploit it. That’s real and now (in fact it’s delaying the launch of the product). The concerns you raise, legitimate as they are, remain theoretical and at some point in the distant future. What’s our priority today? Grow BCH or prevent its growth so we never have the problems that inevitably come from success?

[BigBlockIfTrue]

Do I understand correctly that you propose to keep the 223 byte limit for OP_RETURN outputs (at least for now), but allow the 223 bytes to be divided over more than one output? If so, all discussion of desirability and trade-offs of large on-chain data storage is irrelevant. This is also a simple change that can be deployed quickly. I would support it.

[proteusguy]

That’s correct. We’ll have multiple OP_RETURNs but they must share the aggregate max size overall. To play a bit of devil’s advocate, however, while indeed the theoretical on-chain impact of size is zero, the practical reality is that this could result in some increase of usage of that total which is currently unused. So, yes, the maximum boundary does not move, but the usage of that allocation would likely increase by some small amount. Appreciate your support.

[proteusguy]

I’ve finally gotten around to writing a proper CHIP for multiple OP_RETURN. Please have at it! Also, as I’m not super well connected in the BCH community, contacts for various stakeholders that I should present this to would be greatly appreciated.

[im_uname]

Note that this policy needs to be coordinated in a network upgrade. If it isn’t, and some miners upgrade for multiple opreturns piecemeal, merchants who use old nodes will not be able to observe the newly-allowed multiple op-return transactions at all (but they’ll still be mined), making doublespending trivial and consistent. Deployment of doublespend proof on merchants may mitigate to some extent, but we cannot force them on merchants.

[proteusguy]

This seems to be about as innocuous a change as possible and has been discussed for over a year. Is it not expected that during each 6 month fork nodes will require code upgrades? I’m not trying to be argumentative here, I’m really trying to understand and participate in the process (and thought I had been since approximately October of last year yet this is the first I’ve encountered such an objection). What are the expectations of node operators during these pre-scheduled code upgrades?

Not that this is a reason to “rush” a change but our application can’t be deployed on BCH without this. Had we been aware of this issue last year we certainly would have made considerable effort to address it so it’s a bit of a surprise.

[tom]

The fact is that for the May upgrade people will need to update their full node, and in that regards it makes a lot of sense to combine the two.

It has been sitting around for a while collecting dust, with about 2 months left.

I suggest discussing this with full node developers and seeing if they can actualy have the code stable and included in their planned release. Planned for the May15th upgrade. I don’t know if they are all going to release something in the next weeks, so better ask them.

I do agree with Imaginary Username on the zero-conf issue. When half the nodes on the network dismiss a transaction as invalid, while the other doesn’t, then it becomes trivial to play the system which we don’t want. Unfortunately double spend proofs are not yet included in most (or even any) merchant software.

So, bottom line, feel free to push it. But don’t get too dissapointed when it moves to a future date. Upgrading an entire ecosystem is simply just something that takes time.

[BigBlockIfTrue]

While it’s very late to push new proposals for the May upgrade, I believe this can be implemented really quickly, so if there are no objections (please collect feedback from all nodes immediately) then we can still include it for May, with activation mechanism identical to the other non-consensus upgrade (removal of the unconfirmed chain limit).

[BigBlockIfTrue]

I have discussed this with several BCHN team members and I will draft an implementation of this CHIP in BCHN (with activation mechanism tied to unconfirmed chain limit removal).

[freetrader]

Thank you @BigBlockIfTrue for taking the lead on implementing this in BCHN.

I will state here some of the comments I made in BCHN-internal discussion.

1. I believe the current error code/message for refusing a transaction due to multiple op_returns, needs to change to be clearer, since multiple op_returns are then allowed. I think this isn’t something standardized across implementations, but it may still be good to note it in the CHIP as a possible consideration for implementations. Just to avoid a confusing error message. (note: I didn’t check the BU-based implementation yet, maybe that is handled well there)

2. I think such a change, which affects other tools, should be made available on a testnet prior to the upgrade. That doesn’t leave a whole lot of time before May (BCHN is only planning to put out one release before then), but it could probably be rolled out on testnet4 since 0-conf impacts are not a problem and testnet4 should be for testing with the same standardness rules as on mainnet (or upgraded mainnet).

3. I do think it would be highly advisable to get fuller feedback from those who build or operate op_return based protocols on BCH at present.

4. I may have more comments regarding the contents of the ActorForth CHIP after more review, but from the technical side (the “Specification” part) I think it’s clear as written and so far no problems with it from BCHN side.

[Jonathan_Silverblood]

I’ve read through the CHIP now. I am happy with changing the byte counting from per-opreturn to aggregate of all opreturns and I thinkt that’s how it should’ve been in the first place. I think it’s great that this is getting more attention, but I am a bit concerned with the timeline.

I know this is an old discussion, and that there’s been multiple proposals on the matter so the technical aspect I think is well-understood by now. However, I feel that the cost/risks have been too focused on the protocol side and not enough attention have been given to the actual projects/people that could be impacted by this.

I believe this will be address when work is done to identify and get feedback from stakeholders.

All this said, I do recognize that this is a matter that:

1. it’s not a strict consensus change
2. it is surgically small operation, it is not complex
3. the discussion around it have time on its side

I will also state that I have been pushing for this before and that I want it for a project I am working on.

So I will support this for May, only if we can make sure that stakeholders from existing or aspiring projects get engaged and the each of the node software teams asserts that they have had enough time to collaborate on an implementation in order to be confident about the quality.

I will absolutely support this for a different activation point when/if the non-technical concerns have been addressed.

I will also do my part, and state that I am such a stakeholder, I have a project (Jonathan Silverblood / Cash Intents · GitLab) that would benefit from multiple op_returns and that my usage works well with the aggregated counting implementation suggest here.

A statement you can add to your CHIP:

I believe multiple OP_RETURNs should be adopted, it is highly valuable as it makes it possible for OP_RETURN based protocols to work together to create value. I also believe that counting the aggregate number of bytes is in line with the intent of the original functionality.

[cculianu]

FWIW the technical / code changes for this are trivial (in the node at least).

The simplest thing: just allow 5 or 10 or 20 (or unlimited?) OP_RETURNs in a mainnet standard tx is super easy to do as a code change; my opinion is that it likely would have minimal negative impact on either wallets or the node.

Only question is – does rest of ecosystem want this or not want it?

RE: The byte counting thing – that’s actually harder. Would be just easier / less insane to just make the byte count remain unchanged. That is – if we say raise the limit from 1 to 5 on number of OP_RETURNS, each can be 220 bytes of payload.