CHIP 2021-03 Multiple OP_RETURNs for Bitcoin Cash

CHIPs Standards Track
,
#6

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.

1 Like
#7

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?

1 Like
#8

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.

2 Likes
#9

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?

2 Likes
#10

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.

1 Like
#11

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.

3 Likes
#12

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.

1 Like
Cash Improvement Proposals (CHIPs and Proto CHIPs) List
#13

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.

2 Likes
#14

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.

1 Like
#15

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.

3 Likes
#16

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).

1 Like
#17

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).

2 Likes
#18

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.

#19

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.

2 Likes
#20

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.

#21

@cculianu Switching to unlimited outputs with cumulative size limit is simple to implement, and doesn’t change economics of on-chain data storage.

#22

The way this is refused is by sending a p2p message (or equivalent on other protocol) with reject. Code= RejectNonstandard. Reason: “multi-op-return”. (explained here: Reject)

This would be removed, But it does show a great example of how reject messages work. The code should IMOHO stay RejectNonstandard. The reason for rejecting a transaction with too much op-return space allocated can be suggested to be included in the chip. I would support that and I hope someone can suggest something.

2 Likes
#23

This took me about half an hour…

Support change to allow multiple op_returns

Notice that this omits activation code, BCHN might want that :wink:

1 Like
#24

@tom See my comment

#25

Good observation, and indeed simper. I created a PR to the CHIP here and made it simpler in master in this commit.

2 Likes