02:33:36
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:30
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:36
vtnerd:
@spirobel:kernal.eu: https://github.com/monero-project/monero/blob/48ad374b0d6d6e045128729534dc2508e6999afe/contrib/epee/include/storages/levin_abstract_invoke2.h#L48
02:44:58
vtnerd:
thats probably what kaya is referencing. there are currently limits separate from total packet size in place
02:45:26
vtnerd:
I have a serialization patch that alleviates this but its somewhat complicated and has basically no reviews
02:46:14
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:11
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
02:59:54
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:16
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:35:43
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:03
DataHoarder:
they don't accept that block then, which means they end up making their own chain there
11:16:09
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:35
kayabanerve:matrix.org:
I did cite we'd have to bump the deserialization constants.
12:35:37
articmine:
@spirobel:kernal.eu: How much larger is this block than the short term median MS?
12:35:55
articmine:
The malicious block
12:36:40
articmine:
How long is the attacking chain?
12:44:54
articmine:
If the malicious block is greater than 2MS this block would break consensus.