7

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?

0xb10c
  • 1,392
  • 5
  • 21
  • 2
    Interesting question. I was thinking maybe the `mempool` message could get close to that when `-peerbloomfilters` is set, but it is limited by `MAX_INV_SZ` so it would not. Looking forward to read an answer! – Antoine Poinsot Mar 29 '22 at 10:21
  • AFAIK the `mempool` message (requesting unconfirmed transactions) has no payload. A node should respond with INVs to a `mempool` message. See also: https://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. – 0xb10c Mar 29 '22 at 10:31
  • 1
    Yes, i meant the size of the INV returned when being sent a `mempool` message. – Antoine Poinsot Mar 29 '22 at 10:57
  • 4
    I observed a 0.5.0 node try to send a message that was 6 MB I think. IIRC it was a headers message and it was a significant portion of the blockchain. Also there is lower maximum of 4 MB, see MAX_PROTOCOL_MESSAGE_LENGTH. – Andrew Chow Mar 29 '22 at 12:18

1 Answers1

6

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.

Pieter Wuille
  • 98,249
  • 9
  • 183
  • 287