Raising the 520 byte push limit & 201 operation limit

Consensus
#3

Hi, the developer of BlockUpload.io here,

I would vote NACK on this change unless OP_RETURN size limit is proportionally increased. The website uses 1-of-8 multisig in a P2SH where there is one real public key and the rest are fake 65-byte data pushes. OP_RETURN size limit was upgraded to 220 because DexX7 the Omni developer calculated that it was more feasible to use the P2SH method than OP_RETURN if the limit was less than 220 bytes. We should keep the limits proportional or OP_RETURN will only be used by those can’t afford changing the code.

It should be adjusted so that OP_RETURN is always more feasible (because that’s its purpose) otherwise we can expect everyone to push lots of data to move to P2SH multisig.

5 Likes
#4

Thanks for the heads up! I had totally forgotten the origin of the 220 byte OP_RETURN limit. Here’s the commit in BCHN. Is there any more BCH-specific discussion we can link to here?

I don’t remember ever digging into this, and think I may be misunderstanding the analysis in the linked CIP6 document:

What is requiring the un-hashed data to be directly included in the 520 byte P2SH redeem script?

Is it not possible to include only a hash of the data in the redeem script (to protect the data from being modified before the TX is mined), then provide the un-hashed data before it in the unlocking bytecode?

If I’m not mistaken, the 1650 byte limit on unlocking bytecode (MAX_TX_IN_SCRIPT_SIG_SIZE) should give you well over ~1.5KB of space to commit data, and the 520 byte push limit only affects how many chunks that data must be divided into.

1 Like
CHIP 2021-05 Targeted Virtual Machine Limits
#5

You’re right - multisig doesn’t matter, as presented in CIP6.

That’s new to me, I’ll experiment with that idea and report back.

Could you please give a link to a source code where MAX_TX_IN_SCRIPT_SIG_SIZE is defined?

#6

It’s in policy.h in most C++ implementations. :+1:

#7

I e-mailed Dexx about it:

Hi Dexx7,

I’m the developer of a tool used to store files in the blockchain (blockupload) and
I would be grateful if you could share you opinion on something:

Jason Dreyzehner and I were discussing (link to this webpage)
about the most efficient way of pushing data. My website used Class B transaction, multsig-in-P2SH,
which I thought of as efficient. We were wondering if the following would work, and why Omni doesn’t use the following (in P2SH):

ScriptPubKey: OP_HASH160 <hash> OP_EQUALVERIFY 1 <fake public keys> <real public key> 7 OP_CHECKMULTISIG(VERIFY OP_DEPTH OP_0 OP_EQUAL)
ScriptSig: <1600 byte data push> <real signature>

The parts in parentheses are optional, but desirable malleability checks.

The scriptsig’s length limit can be found here: bitcoin/policy.cpp at 4a540683ec40393d6369da1a9e02e45614db936d · bitcoin/bitcoin · GitHub

Jason thought of this way as strictly superior than class B or even CIP-6 (link that you posted) that seems to be the current best. This seems unbelievably efficient to me. I was wondering whether you had any experience with an upload method similar to this, or why Omni decided not to use this?

Thank you,
MCCCS

#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