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
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
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.
@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.
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.
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
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.
I think consideration for alternate fee structures for transactions that are more than strictly BCH denominations is an interesting idea. There may also be a time in the future that an alternate token gains enough traction to be of value so that miners would appreciate receiving them in coinbase transactions, who knows?
Point is, for now, it’s all quite speculative. Then what would be the trigger that brings such considerations to the forefront? I think if blocks start getting fuller and showing a clear trend upwards, we should start investigating the issue based on what that increase in content is actually composed of. At the same time we’ll have to balance the core architectural driver of making sure transaction costs doesn’t disenfranchise users of the BCH cryptoledger. My perspective for now is that this would be a wonderful problem to have as it would indicate a serious increase of BCH adoption.
This is exactly my intention.
Instead of banning certain type of usage, we can disincentivize it, but generally allow it.
There appear to be an agreement in the community right now that 223 bytes of OP_RETURN data is a lot.
So, we could start charging exponential (x10+) fee increases for anything above this limit. This way we both can have the cake and eat it - achieving the theoretically impossible.
We never know what type of usage we can get in the future and extra data for smart contracts, NFTs or some other usage we cannot yet imagine, could help create new niches for some blockchain-related products.
Flowee, BCHN, and BCHU have confirmed they can. Have you contacted and received any response from BCHD, Verde, and Knuth? @proteusguy
In this Reddit thread Verde’s marketing coordinator confirms they are already compliant in expectation of the May upgrade.
Yes, despite the little time left I think I will be able to implement this in Knuth by May 15th.
I see that some of my concerns were relevant after all.
I understand that in a broad sense, particularly in software development, a programmer can be considered a “user”. But at CHIP level I would recommend keeping our three main stakeholders (miners, developers, users) as clear as possible, at least at the required abstraction level. There are some obvious overlaps, but nevertheless, understanding that each stakeholder class may have different/tailored benefits brings value to the initiative.
While I agree with you that users (business are included in this stakeholder category)
, I would kindly disagree with
I will assume that you are using “regular person” as User stakeholder.
Probably you have heard of a particular case involving Op_Return in which by mid-2017, the BTC address 3QQB6AWxaga6wTs6Xwq8FYppgrGinGu15f paid itself ~174,000 times, including in each transaction an Op_Return.
I know this is an edge case, and although I’m not endorsing such behaviour, the case brings some exciting aspects to consider.
Up to date, Op-Return is the easiest way for users to insert information into the blockchain. But as we know, by our Relay Policy, only one Op_Return (up to 220 bytes) is allowed per transaction. Any user (including businesses) that wants to insert n-pieces of information (i.e., transaction payload) into the blockchain must proceed with the creation of n-transactions. This –taking the previous example despite BTC– results in a remarkable overhead in transaction count, transaction size, fees, and PoW, as the Op_Return size limit per transaction is not reached.
Having Multiple Op-Returns in place will help and benefit users (and businesses) in drastically reducing foodprint when dealing with several Op_Returns for whatever use case they have in mind. Mempool will see fewer congestions (at least for this specific cause), users would be able to improve Op_Returns dealing and pack them in fewer transactions, then use less space in mined Blocks and save fees.
Of course, wallets must provide the necessary and sufficient UX for this to be possible for most users since creating transactions through the console is not within reach of everyone’s knowledge. But your CHIP is the starting point (By the way, did you get any feedback from relevant BCH wallets?).
So, going back. I’m afraid I have to disagree with you in terms of “zero value” for users. I see this initiative with great value for users, who will be able to engage with the Op_Return resource in a more efficient way. And while such optimization would seem insignificant to some at the moment, let us bear in mind that these measures will surely become more relevant as we gain adoption. Time will tell.
Please take my comments as simple recommendations from the perspective of a user. I have no intentions of “correcting” your CHIP. I have no right to do that.
Please have in mind that I agree that once this CHIP gets activated, new developers will come with ideas on how to use multiple Op_Returns in novel ways, expand possibilities and drive even more value and benefit for users.
In no way I’m expecting you to cover the scope of such cases with associated benefits in your CHIP. What I would like is to set the precedent of doing the mental exercise that leads us to think about the benefits of the user as one of the three stakeholders of the system.
That does not involve engaging in the ancient dark arts (or light?) of scrying a crystal ball (as @bitcoincashautist mentioned, and that in fact has nothing to do with Philosophy I hope). It was never requested to know what other utility this could enable in the future by different actors, just the conceptual benefit of this particular CHIP for users, which I tried to exemplify above. Low-hanging-fruit or not, it should not overcome the idea of providing our users with value neither understanding what that value is.
It is actually funny seeing myself writing this. I’m a big supporter of your CHIP (as a user), and I would like to see it implemented. But not seeing the value it could bring to my class of stakeholders explicitly written in the CHIP body makes me wonder if someone even took to time to see this particular aspect through. Hence I did my best to provide my perspective of what that value could be.
I sincerely hope this helps to clarify my point of view.
Thanks much for the follow up! My understanding is that all these nodes are already in compliance with the CHIP or have PRs available to them now that get them into compliance. Presumably someone will correct me if I’m mistaken. 
Is the first I’ve heard of it. My personal history is that I was involved with BTC from prior to its announcement up through something like late 2010 - early 2011 - whenever it went somewhere between $1-$40 and all the conversations went to it’s price rather than the cryptostuff and core issue of peer-to-peer digital currency that I was interested in researching. Then I got dragged back in late 2016 with Ethereum and Stellar and didn’t understand what BCH was until @merc1er clued me in last year. So I’ve missed a lot of exciting history. 
I’m very glad that BCH is here and acting on the original vision that I had pursued and hope my efforts will keep it on that course successfully.
I interpret all polite criticism in the sense of the Principle of Charity and the entire purpose of this channel and the CHIP itself is to get as many eyes on it so we can cover all the bases.
As for the CHIP - it is in no way “mine” - especially since I took the original proposal pretty much whole cloth from Jonathan Silverblood’s original text - outside of me being the person who has volunteered to try to usher it through the process and incorporate our early efforts at CHIP adoption through which several key BCH players have advised and guided me in the attempt.
To that end - I see where you’re coming from and appreciate the insights. I’m not quite sure if they rise to the level of bringing in new key relevant points that would make the CHIP lacking in its duty should they be absent. By that I mean, whatever text your insights would result in an updated CHIP, that content does not come to my mind easily at this time. To wit - if you think this is a key component that would improve the CHIP’s value, I would ask you to offer up a PR in your own words that you believe would be of benefit.
Regardless of whether or not you choose to do so, I appreciate your efforts to read through it (standards processes are the “boring” bits of progress and no fun to slog through) and your insights that give me even more awareness of BCH & OP_RETURN history & relevance. Thanks.