<spirobel:kernal.eu> Can you name these constants? we should make a list if there are multiple dependencies. If any of those changes the 32 mb gut value becomes invalid. > <@kayabanerve:matrix.org> There's other constants within the protocol which also cause this limit. It isn't solely derivative of the packet size.

<vtnerd> agreed, but its also not a trivial change to get this outcome. you’ve gotta store data somewhere between levin packets > <@jeffro256> > That constant seems to be the limiting factor for levin throughput.

<vtnerd> @spirobel:kernal.eu: github.com/monero-project/monero/bl…orages/levin_abstract_invoke2.h#L48

<vtnerd> thats probably what kaya is referencing. there are currently limits separate from total packet size in place

<vtnerd> I have a serialization patch that alleviates this but its somewhat complicated and has basically no reviews

<vtnerd> 0xfffc worked on a bumping these constants, but its just a stop-gap to what I was attempting (a limit based on tx-size, etc., instead of pure limits based on strings, etc)

<jeffro256> True, which would be a DoS vector in itself if we don't verify PoW of objects before downloading > <@vtnerd> agreed, but its also not a trivial change to get this outcome. you’ve gotta store data somewhere between levin packets

<jeffro256> But if we do verify PoW before downloading another round of packets, at least our counterparty has to mine a block to send another packet of bad data

<spirobel:kernal.eu> @vtnerd: that means caking on another limit in the form of max blocksize can not possibly solve the problem at hand: a malicious attacker crafts a block larger than what levin will accept and put it in a chain with smaller blocks at the end. Then he mines those enough so they become the longest chain. honest miners try to [... too long, see mrelay.p2pool.observer/e/ioHWqtMKd3FoRnM3 ]

> honest miners try to apply the longest chain rule, but get stuck because they cant accept the block that was too large.

they don't accept that block then, which means they end up making their own chain there

<kayabanerve:matrix.org> @vtnerd:monero.social: Also various RPC methods, but those may even break at 90 MB blocks due to the overhead there.

<kayabanerve:matrix.org> I did cite we'd have to bump the deserialization constants.

<articmine> @spirobel:kernal.eu: How much larger is this block than the short term median MS?

<articmine> The malicious block

<articmine> How long is the attacking chain?

<articmine> If the malicious block is greater than 2MS this block would break consensus.