Raising the 520 byte push limit & 201 operation limit

[proteusguy]

@Jonathan_Silverblood

But there is a proposal (this thread) where there is an actual discussion abour raising the op_return sizes (the talk about how it was chosen in the first place, and if it should be increased as part of this proposal) and that does play out differently depending on how multiple OP_RETURN support is implemented.

I think I was quite clear that I’m not against the concept - I just haven’t seen anything that requires it near term to justify pushing the change at this time or linking it with multiple OP_RETURN. If I missed such an argument (which contains practical examples) please point it out to me.

@Jonathan_Silverblood

Your role here is not to convince the lesser informed people to like or dislike your proposal. You should make sure that those impacted by the change have their needs considered and that the information necessary to take good decisions is publicly available and that there’s enough time to get edge-cases and details get properly worked out.

My role is to get a valuable change into BCH as quickly as possible so the BCH community will benefit from it. That necessarily requires anticipating objections and criticisms that are both rational and uninformed/irrational and being prepared to address/mitigate both as most appropriate. I am also a stakeholder in that my own app is blocked from deploying into production unless this change is made.

@Jonathan_Silverblood

This is perfectly fine, but paired with it comes the natural conclusion that the multiple OP_RETURN chip should also wait until after the May 2021 fork.

I have to protest “nonsense” with this assertion. The two are in no way linked any more than any other feature or capability of BCH which may be impacted by larger tx sizes. You’ve made no case for this whatsoever. Such a conclusion is unnatural.

@Jonathan_Silverblood

I don’t see why you find this problematic - In my view you should just add a statement somewhere in the multiple opreturn chip to document how accepting the multiple op_return chip would interact with a future change to the opreturn byte limits: namely that by changing to an aggregate across op_return outputs, any changes to the limit would have the intended effect of restricting the correct amount of bytes, as chosen by such an upgrade.

1. there is nothing unique about OP_RETURN that is impacted by increasing legal tx sizes. Most aspects of BCH are equally impacted. What you’re asking for amounts to saying “we can have more of these if the tx size is increased” which is true of just about everything. The CHIP quite directly addresses the impact of tx sizes by being neutral about them and assuring the audience that it has zero impact on tx sizes - which is a policy decision made because a) it makes it easier to get adopted, and b) there’s no known justification at this time for multiple OP_RETURN to require or benefit from a change in the tx size.

2. I frankly don’t understand your hangup with this. You’ve implied that I’m not being intellectually honest here which is incorrect. Why don’t we separate the issues and let raising the tx size proposal stand on it’s own? (I’m ready and willing to support it most likely.) There is ZERO reason to delay multiple OP_RETURN to after May 2021 as it is defined. I’ve reached out and made considerable efforts to verify this. If you have a legitimate technical reason to do so please present it in the chat on that CHIP.

3. I’ve been quite explicit about my concern and don’t think I can add anything to it except to refer you back to my prior explanation. It’s an opinion since it deals with things that are naturally political in nature, and you may have a different conclusion - but I don’t think it impacts the consensus for this proposal whatsoever so I don’t appreciate the desire to tie them together. Seems sloppy. Certainly if your proposal/CHIP has real-world use cases in which the size increase is demanded because of limits on OP_RETURN aggregate sizes then make that argument. Again, I’d support such a compelling argument. But let’s proceed in the proper order.

[BigBlockIfTrue]

@Jonathan_Silverblood

that does play out differently depending on how multiple OP_RETURN support is implemented.

No, it does not. Where we allow data to be placed in a transaction (single or multiple OP_RETURNs) is a completely separate debate from how much data we should allow in a transaction. Allowing multiple OP_RETURNs will not impact people’s opinions on the amount of data that should be permitted. So there is no reason to postpone the multiple OP_RETURNs decision until the other discussion reaches a new conclusion.

The genius of @proteusguy’s CHIP is that it separates the where from the how much, so that the where can be resolved much faster. I fully support it.

Within BCHN I had an extensive discussion with @cculianu who argued for allowing more OP_RETURN data, and in the end he also concluded that this is not a reason to block the multiple OP_RETURNs proposal now.

[Jonathan_Silverblood]

You might want to re-read what I stated. How multiple opreturns get implemented will indeed have an impact on that discussion and I do agree that @proteusguy chip (which is is based on my suggestion: BUIP140: Multiple OP_RETURN with shared size limit. | Bitcoin Forum) is great because it separates these concerns.

My argument is that this is something that should be clarified on the chip, not something to skip or avoid in the name of preventing loss of popularity.

If the interaction between future OP_RETURN bytelimit and the changes of this CHIP is something that won’t get documented in the chip for political reasons - then what OTHER political things might have the same treatment? Is this a good precedent?

The chip already tries to push for a change on a very short timeframe - is it not reasonable to expect that CHIP to prefer extensively documenting edgecase?

[Jonathan_Silverblood]

I just haven’t seen anything that requires it near term to justify pushing the change at this time

Yes - but I didn’t ask you to push for the change. I’ve asked you to document the interaction your proposal has with regards to future changes to the opreturn byte limit. I suggested you do this by referencing this chip since this chip have an active discussion on it and may, or may not, depending on the outcome of that discussion, might want to include such a change.

or linking it with multiple OP_RETURN.

If by linking it you mean “include the change in”, then no - absolutely not. As I’ve said multiple times, I want you to document the interaction.

I have to protest “nonsense” with this assertion. The two are in no way linked any more than any other feature or capability of BCH which may be impacted by larger tx sizes.

I never argued that it should wait as a result of being possible impacted by larger tx sizes - I argued that it should wait because it is outright dangerous to push changes through without regard for proper communication and documentation, and you very clearly stated that you preferred to not document how your proposal would interact with a likely future change, citing that it would be better if we didn’t have that discussion before it has already been deployed.

I find that behavour to be risk-seeking and dismissive, you were pointed out that there was something here that might have an impact on your change - the expectation is that you will address what that impact is, document it and show that it’s safe, and that assertation of safety should go through peer review over a reasonable amount of time.

Since you are actively pushing for having this change on a very short timeframe, I believe it is more than reasonable that you respond to request to documenting edgecases in a fortcoming way.

[BigBlockIfTrue]

I agree it would be reasonable to mention in the CHIP that the CHIP intentionally focuses on the where and not on the how much, and that it does not interfere with changing the how much in the future.

[proteusguy]

I don’t think your case is made and the claim that I’m being less than forthcoming is utterly without merit. I’ve explicitly made multiple OP_RETURN independent of any considerations for tx size changes and make that point clear in the CHIP. That is the very definition of being above board. The CHIP is neutral regarding such considerations and that’s a proper policy to take.

That said, I don’t see a developed CHIP for your proposal yet. Maybe I missed it. Do you have a link to it that I could review? I’ll look at it and consider putting a reference to it in the multiple OP_RETURN one at that time.

[Jonathan_Silverblood]

Then why are you unwilling to explicitly document:

the interaction your proposal has with regards to future changes to the opreturn byte limit

When requested to do so? Is it not a reasonable request?

I’ve explicitly made multiple OP_RETURN independent of any considerations for tx size changes and make that point clear in the CHIP.

Yes, but the while the chip does make it clear that it does not want to change the actual number of bytes, and that it is intentionally agnostic towards doing so, it doesn’t make it clear what impact the change it does propose have if the day should come when such a change is to be made.

There are three possible futures:

• smaller opreturn limits.
• same opreturn limits.
• larger opreturn limites.

Adopting the aggregate counting changes the outcome for these (for the better!) and should be documented.

When evaluating alternatives, it would be reasonable to reject, for example, BUIP #139 because it amplifies such changes unintentionally.

[proteusguy]

@Jonathan_Silverblood

Yes, but the while the chip does make it clear that it does not want to change the actual number of bytes, and that it is intentionally agnostic towards doing so, it doesn’t make it clear what impact the change it does propose have if the day should come when such a change is to be made.

I don’t understand how you justify your demand that I predict what every possible future of OP_RETURN might be in the CHIP. Either the impact is immediately apparent and obvious to everyone or it’s not an depends entirely on how the size adjustment is made. It would seem to me that the place to document that is in the future CHIP that proposes to change the size - not in the CHIP that has nothing whatsoever to do with a size change. I’m not inclined to predict all future possibilities.

Meanwhile, I don’t know why you continue to argue the point when I’ve already agreed to consider your request to reference your CHIP once you give me a link to the CHIP you’d like referenced. How about we just pursue that option for now so we might reach some consensus?

[Jonathan_Silverblood]

Either the impact is immediately apparent and obvious to everyone or it’s not

It’s not.

demand that I predict what every possible future

I don’t - I ask that you document a handful of realistic and relatable cases: “what happens if we do X and have not adopted this CHIP? what happens if we do the same but have adopted this CHIP?”

It is absolutely relevant to the chip you are putting forward, because the outcome changes if we adopt your chip or not.

[proteusguy]

My original understanding was that you wanted me to refer to some size change CHIP that I hadn’t seen. Apparently that was not what you’re asking for. I honestly don’t know what will satisfy you but you seem to have something rather specific in mind that you want. Rather than wait for me to write the perfect text that satisfies your demands, my suggestion is that you submit a PR to the CHIP for consideration then there won’t be a need for so much confused back and forth.

[bitjson]

Hi all, I just published a draft CHIP on this subject. If you’re interested, I’d appreciate review and feedback here:

CHIP: Targeted Virtual Machine Limits

This proposal replaces several poorly-targeted virtual machine (VM) limits with alternatives which protect against the same malicious cases while significantly increasing the power of the Bitcoin Cash contract system: the 520-byte stack element size limit is raised to 10,000 bytes. The 201 operation limit is removed. A new cumulative hashing limit is introduced, limiting contracts to 660 digest iterations per evaluation. A new stack memory usage limit is introduced, limiting contracts to 130,0…