CHIP 2021-03 Multiple OP_RETURNs for Bitcoin Cash

[proteusguy]

@Leandrodimarco

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:

Correct…

@Leandrodimarco

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?

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.

[proteusguy]

Many thanks. I have incorporated your comment into the CHIP.

[proteusguy]

@ShadowOfHarbringer

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

[ShadowOfHarbringer]

@proteusguy

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.

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.

[BigBlockIfTrue]

@freetrader

provided all major full node clients can implement it by then.

Flowee, BCHN, and BCHU have confirmed they can. Have you contacted and received any response from BCHD, Verde, and Knuth? @proteusguy

[freetrader]

In this Reddit thread Verde’s marketing coordinator confirms they are already compliant in expectation of the May upgrade.

[fpelliccioni]

@BigBlockIfTrue

@freetrader

provided all major full node clients can implement it by then.

Flowee, BCHN, and BCHU have confirmed they can. Have you contacted and received any response from BCHD, Verde, and Knuth? @proteusguy

Yes, despite the little time left I think I will be able to implement this in Knuth by May 15th.

[Leandrodimarco]

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)

@proteusguy

benefit from is the new applications and features that can be created and deployed

, I would kindly disagree with

@proteusguy

There’s zero direct value for an OP_RETURN to a regular person who transacts with the BCH currency

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.

[proteusguy]

@BigBlockIfTrue

Flowee, BCHN, and BCHU have confirmed they can. Have you contacted and received any response from BCHD, Verde, and Knuth? @proteusguy

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.

[proteusguy]

@Leandrodimarco

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.

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.

@Leandrodimarco

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.

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.