In Bitcoin Core,
MAX_SIZE defines the maximum valid P2P message payload size to be 32MB. Is it realistic that a peer sends a message payload close to 32MB? What is the maximum, but still realistic message payload size?
Since Bitcoin Core pull request 5843, incoming messages larger than MAX_PROTOCOL_MESSAGE_LENGTH are rejected. This constant was initially set to 2 MiB, but later (as part of the segwit changes) increased to 4 MB.
Its purpose is memory DoS protection. An attacker that manages to open many connections to a victim node could otherwise e.g. start sending messages of 32 MiB (MAX_SIZE for all serialized objects), but never send the last byte. Those just-below-32MiB messages would need to be kept in memory before until the last byte arrives, before processing them. Limiting the maximum valid message size significantly reduces the impact of such an attack.
mempoolmessage could get close to that when
-peerbloomfiltersis set, but it is limited by
MAX_INV_SZso it would not. Looking forward to read an answer!
mempoolmessage (requesting unconfirmed transactions) has no payload. A node should respond with INVs to a
mempoolmessage. See also: developer.bitcoin.org/reference/p2p_networking.html#mempool. The resulting INV could have up to 50_000 entries with 4+32 byte each. 36 byte * 50_000 = 1.8 MB.