This took me about half an hour…
Support change to allow multiple op_returns
Notice that this omits activation code, BCHN might want that 
1 Like
Good observation, and indeed simper. I created a PR to the CHIP here and made it simpler in master in this commit.
2 Likes
Removing the limit of 1 OP_RETURN actually removes a few lines of code. Counting the total aggregate total bytes adds approximately the same number of lines. It’s a wash code-wise and extremely low risk-wise. This is the simplest way to proceed for now. As it gets used we can reconsider the total size limit if there’s justification for doing so. I don’t anticipate this being a concern in the near future as our application is fairly complex already but works alongside SLP.
1 Like
BCHN implementation is ready too, including activation logic:
@proteusguy I see Tom already made a pull request to your CHIP with some clarifications. I would like to add a short technical spec as well. I’ll submit a PR after you processed Tom’s.
3 Likes
Tom’s PR has been merged. Go at it. 
From all I’ve seen so far, the general consensus within BCHN is supportive of the technical aspects of ‘CHIP-2021-03-12 Multiple OP_RETURNs for Bitcoin Cash’ .
Regarding ecosystem consensus around its activation in May, I would like to see more of that expressed by anybody potentially benefitting from (or being negatively affected by) this change.Simply, they could express themselves on this discussion thread, or post official position statements themselves on their sites or elsewhere, and link to those.
My personal opinion is that it’s a good proposal, my brief review of MR 1115 which has been implemented by @BigBlockIfTrue is that I’m confident we could safely activate the change (but that also requires a little coordination with BU’s deployment of it).
However, I would urge that we get more affirming feedback from other stakeholders.
This is what the BCH Network Discussions are intended to achieve, as I understand it, so I think it would set a good precedent if a meeting on this topic could be convened.
1 Like
Thanks & completely agree. But I need help from anyone/everyone on identifying who these stakeholders are and how to reach them. I’m afraid I’m relatively new to the BCH tech community (I don’t have a clue whether I’ve ever even heard of someone who was a BCH miner for example) and don’t have the requisite contacts to move this aspect further. I’ll happily follow up on all suggestions and contacts provided.
Many thanks…
2 Likes
Hello,
I would like to add my support to this proposal as a Stakeholder. Founder of the upcoming SLP NFT game enter-the-sphere.com . Co-Founder of Spice Token, and a Director of the SLP Foundation.
I believe having multiple_opreturns will add some interesting possibilities for NFTs for Enter The Sphere, our token solution needs to be as competitive as possible, and anything that expands the chance of something innovative being done on SLP, is something I support.
As I understand, implementation of this change will allow multiple assets to be on a single tx, something that can be very useful for pairing NFTs with other assets. A function that allows us to link NFT items with other assets easier than current.
This is my personal opinion and support as a non-technical stakeholder, this is not a technical endorsement nor have i reviewed deeply about whether these changes have cons on a technical basis (as far as I understand there is none).
Best regards,
Joey
3 Likes
FYI - I have added a link to the PR for Bitcoin Unlimited and have upgraded the CHIP status from Draft to Proposed. Please give it another once over and I would definitely appreciate any quotes you can send for me to add to the CHIP.
Would you be willing to provide a comment for inclusion into the CHIP? Thanks.
Would you be willing to give me a quote I can include in the CHIP? Thanks!
I think Multiple OP_RETURN CHIP will provide a way for better NFTs - both NFT (SLP) payload and BCP payload can be parts of one transaction, which will reduce the number of queries to retrieve the external content.
Stoyan Zhekov, bch-js developer
3 Likes
Apparently, contrary to intuition, due to specifics of the Bitcoin-QT codebase, complexity level of Multiple OP-returns is almost/practically the same as one single big OP-return.
So I am for it, as long as it does not affect the scalability of BCH.
I also believe that there would be no negative consequences on the ecosystem, as long as we promote cash function as the primary function of Bitcoin Cash.
It can be done in multiple ways - for example, exponentially increasing fee for every next OP_RETURN above certain limit (i.e. >= 3). This limit is completely arbitrary and we could let miners change it easily, just create a default.
I believe that if we don’t do this ourselves, miners will start modifying the software and doing it manually, so the limitation has to be done - this or some other way.
Bitcoin Cash is not Ethereum, the network is not designed to store large amounts of data not designated for transactions.
1 Like
@proteusguy It is interesting to see this CHIP getting traction and support from the ecosystem’s relevant stakeholders.
I went through the document, in particular to Motivations and Benefits. Although the explanation is clear, it gives me the impression that it places its weight on giving more experimentation power to interested developers, as mentioned:
This proposal aims to correct this minor oversight in order to bring the full potential of OP_RETURN’s experimental expressiveness to the BCH chain without incurring any additional trade-offs that were part of its original design.
I’m not saying this is necessarily a bad (or good) thing. But from my perspective, it would be nice to see in this CHIP, as in all CHIPs, clear statements about the benefits for users as one of the logical stakeholders.
The question is pretty straightforward:
- How would BCH users benefit from this change?
And then you can add one more:
- Could this change negatively affect any of BCH (money) properties?
You probably thought about it already, and you have a clear picture in your mind about this change’s positive consequences on users. I could think in a couple of ones myself, but I’m sure your CHIP would gain greater dimension if you include that information explicitly in the document with some examples.
If, with some analysis, we realize that as a matter of fact this change (or any change proposed by any CHIP) brings no benefit for users after all… Well, in that case, the discussion would take a different path.
Be certain I have no intention of placing an extra burden on your particular proposal. Still, as it’s the first CHIP to reach Proposal status 
, I find it relevant to lay some foundations for the future, of course in the form of a recommendation.
2 Likes
For what it’s worth I fully support this because it gives more freedom to users at virtually no additional cost to the blockchain.
This is correcting a historical wrong IMO. When OP_RETURN was first introduced, what was the rationale to place arbitrary restraints on how to structure the data written? What was the rationale to have it behave differently from other Script ops? This is not allowing more data per TX, it’s giving users the freedom to structure the data better, and they should have had this freedom from the beginning.
With things like this, I don’t believe it’s required to dwell too much on proving benefits. The fact that at least one user has a solution waiting for this enabler should be enough. It means that the benefit is >0, and when the cost is 0 or near 0, the benefits/costs will be >1 regardless of whether we can think of more uses or not.
On some philosophical points, we don’t have a magic ball, we can’t know what other utility this could enable if the ecosystem gets a new building block. That’s the beauty of decentralization. You can’t know what people will build with the tools and building blocks they will have available. With this proposal we’re giving them building blocks, but it’s some people out there who will build, the building blocks won’t assemble by themselves. With every building block given, we increase the likelihood that someone somewhere will come up with a “killer” app, and hopefully also increasing the number of those someones interested in building with our blocks. For building blocks that introduce a significant cost to the blockchain, then sure, we need a more deep evaluation. For low-hanging fruit like this – just take it.
2 Likes
Hey there @proteusguy ,
This took a bit of discussion among BCHN maintainers, so thanks for your patience - I can provide you this statement for inclusion into the CHIP:
This is a simple and logical change that provides more flexibility for OP_RETURN users without affecting the trade-offs associated with the limit. The proposal has been implemented in a BCHN change request and a majority of BCHN maintainers supports activating this change on 15 May 2021.
While this CHIP arrived at a fairly late moment, we believe that sufficient awareness has been raised such that it can nevertheless be activated in May provided all major full node clients can implement it by then.
- freetrader, lead maintainer of Bitcoin Cash Node
4 Likes
Correct…
Do you have a specific suggestion you might like to see? I believe the CHIP actually is composed at the correct scope with the correct stakeholders as-is but I could certainly be missing something.
In this case the “user” is the programmer. There’s zero direct value for an OP_RETURN to a regular person who transacts with the BCH currency. What they benefit from is the new applications and features that can be created and deployed quickly because of these capabilities so we’re one indirection removed. What those benefits are depends entirely on the app developers. We do provide the example of one such app, our Auction protocol as an example reference, but to try to defined the scope of such benefits would be misleading and, I suggest, inappropriate for this CHIP.
Many thanks. I have incorporated your comment into the CHIP.
1 Like