Raising the 520 byte push limit & 201 operation limit

Consensus
#8

OK, the 220 byte limit is no longer relevant since you just invented a second way that makes P2SH pushing 4x as feasible or 1.25x as CIP-6.
His answer:

Hi MCCCS,

thanks for reaching out. First of all, the proposal to raise the
OP_RETURN limit was not merged in Bitcoin Core, but it’s actually in
Bitcoin Cash.

Have you tested this script? I’m very curious. It’s an interesting
approach. :slight_smile:

In Omni, the bare-multisig approach is a relict from the past and we
haven’t added a new way so far.

Cheers

Me:

I agree that this seems promising. I’ll try to upload something that
uses this method. I haven’t tried this script yet.

If this works, then the OP_RETURN limit needs to be QUADRUPLED to stay competitive
your graph at https://github.com/bitcoin/bitcoin/issues/12033 would become archaic.
It seems to be a nice candidate for class D transaction format.

I’ll report back, once I try this in a few weeks.

Thanks,
MCCCS

This is so exciting, although it’s off-topic to this discussion.

1 Like
CHIP 2024-12 P2S: Pay to Script
#9

I backported this to BCHN, see here:

2 Likes
#10

Bitcoin Unlimited is also porting this: Port core 16902 O(1): OP_IF/NOTIF/ELSE/ENDIF script implementation (!2428) · Merge Requests · bitcoinunlimited / BCHUnlimited · GitLab

1 Like
#11

I’m separately pushing for allowing multiple OP_RETURNs in a single transaction. Talk thus far was that the aggregate size of all OP_RETURNs would need to stay within the present 220 byte limit. Just running the question by you all to make sure that support for multiple OP_RETURNs won’t break any of this work. Any comments/feedback?

2 Likes
#12

Nope, I don’t think there will be any interaction with these two changes. :+1:

Want to start a new topic on allowing multiple OP_RETURNs? I’d love to see that happen.

In the past, I think a lot of resistance stemmed from the perception that OP_RETURN is a temporary hack in need of replacement by some formal “data” field in a new transaction format. (I think that misunderstands the transaction format, and OP_RETURN is actually an ideal solution within the TX model, e.g. SIGHASH_SINGLE.) So I think the strongest remaining concern is probably about the “fee structure” of adding extra data to the blockchain.

One conservative option might be to allow a total of N bytes across all OP_RETURN outputs, where the full, serialized size of the OP_RETURN output is counted. Also, I think we’ve just realized that the 220 byte limit was selected partially by mistake. It might be a good idea to select a new N based on the info above.

3 Likes
#13

FYI the multiple OP_RETURN proposal is here: Multiple OP_RETURNS - This time for real!.

2 Likes
#14

I think that once this suggestion is expanded into a full chip, it makes sense to make a note on both chips of how they interact with eachother.

My understanding is that the multiple opreturn chip would change how the limit is counted, but would not touch the actual number. This chip, on the other hand, could consider changing the actual number, but should not have any impact on how it’s counted.

Therefor, this chip will be the one to face the resistance of “more data on chain”, while the multiple opreturn remains a question about compatibility and interoperability between opreturn based protocols.

2 Likes
#15

Sounds great :rocket:

I think that would still be misplaced – raising the 520 byte push limit has no meanigful impact on data storage potential, since the MAX_TX_IN_SCRIPT_SIG_SIZE size (1650 bytes) is the primary VM-level limiter right now.

And even that is not a serious limiter – its just the threshold at which people will need to break larger “uploads” into multiple inputs (adding overhead of a few bytes per input). The first meaningful limit is MAX_STANDARD_TX_SIZE, which is 100,000 bytes. After that, MAX_TX_SIZE (if they have access to a mining pool) is 1 MB.

The TX size limits are really the first layer to place meaningful costs on “chain upload” applications, since applications have to start breaking “uploads” apart across multiple transactions. While possible, it’s usually not worth it – with the infrastructure and overhead the application would need to link transaction data together, it’s more worthwhile (and saves a lot of TX fees) to just serve the files directly, committing to hashes on chain.

So beyond the 100 KB transaction size relay/policy limit, we’re just dealing with applications that want absolute censorship resistance and are willing to pay a serious premium for it. That price is currently 1 satoshi/byte, i.e. the price of 1 BCH per 100 MB of chain space. All these other limits just place slight inefficiencies on those base sizes by requiring a few extra bytes here and there.

If anyone is seriously concerned about that price, we need to address it directly, not fiddle with inconsequential properties of the VM.

2 Likes
P2SH32: a long-term solution for 80-bit P2SH collision attacks
#16

The P2SH scripts solve a very specific problem and have some benefits for some usecases. The specific problem is that it makes non-standard scripts fit in the payment protocol that is “address based”.
The added benefit is that in some cases the delayed exposing of a script is nice.

As we hopefully will soon get more attention to expanding payment protocols featuresets, one of the most often cited wishes is that we stop assuming an address and the payment protocol will allow the receiver to simply send over the outputs they want to include in the final transaction. Sending a full output (or more than one) enables many more usecases.

Most important such an approach allows us to use non-templated scripts in outputs in many more cases. Because p2sh already allows this implicitly, I doubt we’ll have a lot of problems getting this changed in the nodes policy to enable this, and open many more features.

This also paves the way to longer scripts that live in the tx-output and thus no longer have any problems with push limits since they no longer are pushed as a whole.

1 Like
#17

I’m concerned that discussion of raising the size limit and relating that to multiple OP_RETURNs might cause resistance to multiple OP_RETURNs. I understand that this isn’t entirely rational but I’d be willing to bet that lesser informed people or people who just never want a single extra byte be allowed and view multiple OP_RETURN as a lever by which it might win consensus will just attack everything associated with it. My preference is that we leave discussion of tx size limits til after the May fork and that it be carried forward without reference to the multiple OP_RETURN CHIP.

1 Like
#19

I would argue that this would be irresponsible, and that showing that there has been proper research into the topic and that as many of the edge-cases as possible has been taken into account is somewhat of a strict requirement.

Particulary so when you’re aiming to get something accepted on a very short time-frame. Avoiding the discussion in order to retain “popularity” is a strong warning signal to me, and one that - quite frankly - makes me want it to be excluded for may2021.

#20

You’re reading me wrong. Your own comment on Mar 1 claims that these are independent issues and I quite agree - it’s important to keep them as independent issues. But when you present both at the same time it’s going to be a natural reaction to tie them together which would be a mistake.

Understand that we’re talking about two dimensions here: First, the formal specification dimension, which I think all of us here are comfortable with and can be dealt with in a completely rational manner, secondly, the human consensus aspect of getting people to agree with changes that impact them yet have all kinds of different agendas and don’t have either the time or the capacity to fully appreciate all the details of the first dimension.

The concern I’m talking about here is focused on the second dimension. And we ignore it to our great peril. Now I would immediately change my mind and take on the fight if there was a compelling reason under the first dimension to increase transaction sizes immediately. But I haven’t experienced this (and it was explicitly something I was investigating in my own research) and I haven’t seen the case made for it. My personal opinion is that increasing tx sizes is inevitable - once a compelling case that demonstrates it’s necessary for BCH’s progress. I’ll be the first to push forward for it. Just let’s not get ahead of ourselves and certainly don’t accidentally trip up other progress to compound the error.

1 Like
#21

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.

Acknowledging that and making sure that the stakeholders are made aware of this is how we get the information required to take good decisions.

You said:

I’m concerned that discussion of raising the size limit and relating that to multiple OP_RETURNs might cause resistance to multiple OP_RETURNs. I understand that this isn’t entirely rational […]

The multiple OP_RETURN chip has an impact on how this is handled. The impact is positive, so there shouldn’t be a concern about this - it should be brought up and as many edge cases as possible should be considered by as many stakeholders as possible.

lesser informed people or people who just never want a single extra byte be allowed and view multiple OP_RETURN as a lever by which it might win consensus will just attack everything associated with it

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 preference is that we leave discussion of tx size limits til after the May fork

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

#22

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.

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.

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.

  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.

  1. 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.
1 Like
#23

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.

2 Likes
CHIP 2021-05 Targeted Virtual Machine Limits
#24

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?

#25

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.

#26

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.

#27

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.

1 Like
#28

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.