02:33:56 <br-m> <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.
02:35:50 <br-m> <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.
02:44:56 <br-m> <vtnerd> @spirobel:kernal.eu: https://github.com/monero-project/monero/blob/48ad374b0d6d6e045128729534dc2508e6999afe/contrib/epee/include/storages/levin_abstract_invoke2.h#L48
02:45:18 <br-m> <vtnerd> thats probably what kaya is referencing. there are currently limits separate from total packet size in place
02:45:46 <br-m> <vtnerd> I have a serialization patch that alleviates this but its somewhat complicated and has basically no reviews
02:46:34 <br-m> <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)
02:59:31 <br-m> <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
03:00:14 <br-m> <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 
10:23:36 <br-m> <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 https://mrelay.p2pool.observer/e/ioHWqtMKd3FoRnM3 ]
10:36:03 <DataHoarder> > honest miners try to apply the longest chain rule, but get stuck because they cant accept the block that was too large.
10:36:23 <DataHoarder> they don't accept that block then, which means they end up making their own chain there
11:16:30 <br-m> <kayabanerve:matrix.org> @vtnerd:monero.social: Also various RPC methods, but those may even break at 90 MB blocks due to the overhead there.
11:16:55 <br-m> <kayabanerve:matrix.org> I did cite we'd have to bump the deserialization constants.
12:35:57 <br-m> <articmine> @spirobel:kernal.eu: How much larger is this block than the short term median MS?
12:36:15 <br-m> <articmine> The malicious block 
12:37:01 <br-m> <articmine> How long is the attacking chain?
12:45:15 <br-m> <articmine> If the malicious block is greater than 2MS this block would break consensus.