Limit blocks to 32 MB, regardless of context

[kayabaNerve]

While the block size limit may be dynamically adjusted, regardless of the dynamic block size limit, the effective block size limit is to be min(dynamic_block_size_limit, 32 * 1024 * 1024) if this proposal is adopted.

This is due to the effective throughput of Monero nodes being such, as per the stressnet, and various parts of the Monero node assuming blocks do not become absurdly large (RPC, P2P limits) which 32 MB complies with yet still would cause a minimal batch size (blocks < 5) if any.

This proposal is made independently to any/all of the recent proposals on scaling due to their contention, yet this is simple, directly modeled after effective bandwidth limitations currently experienced, and still >100x the current penalty-free block size. While monerod may improve in the future, the protocol will also change in the future, making this only as constant as the protocol adopting it.

A sane static limit also simplifies the checking of blocks sent over the network, due to not requiring the context of the blockchain, whereas the current limit is infinite due to the miner transaction being unbounded (its own topic). After the unbounded miner transaction, the context-free limit is absurd due to blocks being allowed to have 0x10000000 transactions, which would be 268 GB if each transaction was just 1 KB.

[Har01d]

While 32 MB may look valid today, it may be become too low in a few years, but there will be a hard limit in place which would require a hard-forking change to be removed. This just introduces a risk of repeating the biggest Bitcoin's mistake while providing no benefit. Miners can have a "sane limit" by themselves, they're not stupid.

[kayabaNerve]

There seems to be sufficient agreement on 90 MB from the prior meeting, due to how the node's expected behavior breaks at ~100MB anyways. This limit is expected to not be reached for several years under existing candidate scaling proposals, but prevents things from breaking unexpectedly, pending the necessary reworks and improvements to the P2P layer and RPC for things to not break (allowing removing this limit, required for safe and correcr operation).

monero-project/monero#9433 was noted as a PR required (or a PR of similar effect) to update current serialization limits to accomodate such a limit.

[tevador]

Here is the table of outcomes when block space demand reaches 100 MB depending on whether a 90 MB hard cap is introduced and whether a future hard fork happens that fixes the problem at 100 MB:

	Fixed by a future HF	Not fixed by a HF
90 MB limit	network operates normally	network is congested
No limit	network operates normally	network breaks down

The outcomes differ only if 100 MB block space demand comes before the 100 MB limitation is fixed with a future hard fork. In this case, a congested network is certainly better than a broken network, which speaks in favor of the 90 MB temporary limit.

This just introduces a risk of repeating the biggest Bitcoin's mistake

Bitcoin didn't have a P2P protocol that would break at 1 MB. That limit was completely arbitrary.

In this case, we are talking about a limit that literally prevents the network from breaking down.

[Har01d]

In this case, we are talking about a limit that literally prevents the network from breaking down.

The solution to this issue should be fixing the 100 MB packet limit cap bug then, not introducing a new one. Monero is currently being advertised as having unlimited block size pretty much everywhere (including getmonero.org): you're breaking the social contract.

which speaks in favor of the 90 MB temporary limit

If you want to introduce a temporary limit to buy time to fix some bugs, it should be coded as temporary, i.e., it should have an expiration date in the near future.

[tevador]

The solution to this issue should be fixing the 100 MB packet limit cap bug

Yes, everyone agrees with this. Do you volunteer? Fixing the bug requires rewriting parts of the P2P protocol, which is not a trivial fix and is a hard fork itself. The 90 MB cap is an interim solution.

I think an acceptable compromise would be to publish a bounty funded from the Monero general fund to fix the bug. If nobody takes the bounty before a specific date (e.g. March 31st, 2026), we go ahead with the hard cap at the FCMP hard fork.

you're breaking the social contract.

The "social contract" is already broken. The fact is that monerod can't sync past a 100 MB block. We can either stick our head in the sand and pretend the problem doesn't exist, or we can introduce a temporary limit of 90 MB that prevents the network from breaking until the underlying issue is fixed.

If you want to introduce a temporary limit to buy time to fix some bugs, it should be coded as temporary, i.e., it should have an expiration date in the near future.

What would be the benefit of a fixed expiration date that can expire before the actual bug is fixed? Then we'd be back to square one with a breakable network.

[Har01d]

Yes, everyone agrees with this. Do you volunteer? I think an acceptable compromise would be to publish a bounty funded from the Monero general fund to fix the bug.

Yeah, a CCS project is a good idea. I can definitely chip in. By the way, why is it that imposing a hard cap doesn't require a bounty?

The "social contract" is already broken. The fact is that monerod can't sync past a 100 MB block.

It's not. Obviously, there's no such thing as "unlimited blocks" in practice. But the current contract is that there's no defined cap in the protocol, and miners decide on the current safe soft limit. This proposal shifts the power balance from miners to developers and breaks the said social contract.

What would be the benefit of a fixed expiration date that can expire before the actual bug is fixed? Then we'd be back to square one with a breakable network.

Surely it's possible to estimate the needed time to fix it? Otherwise it can stay forever, like it did on Bitcoin. You can't guarantee the limit will be lifted. It's a much larger risk than the bogus "rogue miners will suddenly decide to nuke the network" theory. And, technically, if I understand it correctly, the network wouldn't even go down; only miners mining blocks over 100 MB would.

[kayabaNerve]

1. This already is a limit in the code. It's just thrown around and not handled properly.
2. New nodes would fail to sync the network as-is. This doesn't just mean miners of a certain size wouldn't have their blocks accepted. The RPC would also start to break.

[Har01d]

This already is a limit in the code

Yet you won't find any mention of this limit anywhere. All the existing articles and materials on dynamic blocks don't mention this limit. It's a bug that needs to be fixed.

Remember the 184 billion bitcoins bug? Well, the code allowed that many bitcoins! Yet not the social contract. It's the same here. It was a bug there, it it a bug here.

This proposal (and any other proposal that sets a hard cap on the block size) breaks one of the most important Monero features and further centralizes Monero around its development team.

[tevador]

By the way, why is it that imposing a hard cap doesn't require a bounty?

You are a developer, so it should be clear to you that adding a limit is a task for maybe 1 hour, while reworking the block sync protocol is a project for at least a few weeks.

But the current contract is that there's no defined cap in the protocol

There is, and has been since 2014:

https://github.com/monero-project/monero/blob/296ae46ed8f8f6e5f986f978febad302e3df231a/contrib/epee/include/net/levin_base.h#L71

Otherwise it can stay forever, like it did on Bitcoin. You can't guarantee the limit will be lifted.

There is already a limit of 100 MB. If your argument is that there is a probability that Monero will never hard fork again like Bitcoin, then the 100 MB limit will stay forever anyways, so your argument is moot.

And, technically, if I understand it correctly, the network wouldn't even go down; only miners mining blocks over 100 MB would.

It's the other way around. Nodes that are online at the time the 100 MB block is produced will continue, but new nodes coming online won't sync past that block, possibly leading to a chain split. In any case, the result is a broken network.

Remember the 184 billion bitcoins bug? Well, the code allowed that many bitcoins! Yet not the social contract. It's the same here. It was a bug there, it it a bug here.

Exactly. This proposal is for us to put a sanity limit so the "184 billion bitcoins bug" cannot be triggered maliciously (in this case, the 100 MB block bug). You are arguing that doing nothing (i.e. leaving the bug exploitable) is better than the sanity cap.

Here is the list of things to do, ordered from the best to the worst:

1. Fixing the bug (reworking the sync protocol)
2. Temporary 90 MB limit
3. Doing nothing

This proposal (and any other proposal that sets a hard cap on the block size) breaks one of the most important Monero features and further centralizes Monero around its development team.

I fail to see how a sanity limit 10% lower than the existing breakage limit will centralize Monero, even if Monero never hard forks again.

[fluffypony]

Here is the list of things to do, ordered from the best to the worst:

1. Fixing the bug (reworking the sync protocol)
2. Temporary 90 MB limit
3. Doing nothing

Is there a middle ground of sorts where we put a 90mb limit in for 2-4 years post-fork-height, and that gives enough time to flesh out changes to the sync protocol to handle larger blocks + gives the Internet time to expand? I suspect that the ongoing deployment of LEO satellites for Internet etc. will make this block size more feasible down the road, but our aim is to reduce the risk of harm in the interim.

The other way to do this is to massively increase tx fees to make such an attack prohibitively expensive for a motivated, well-resourced attacker, but I'm hopeful that the people arguing against this thread are also not arguing for a tx fee increase.

[tevador]

@fluffypony Here is the table of possible outcomes for a 90 MB limit with and without a fixed expiration date:

	Fixed in 2 years	Not fixed in 2 years
90 MB for 2 years	OK	exploitable network
90 MB until fixed	OK	OK but limited

The weighted outcome is better for the limit without a fixed expiration date.