<p>Since Bitcoin Core <a href="https://github.com/bitcoin/bitcoin/pull/5843" rel="noreferrer">pull request 5843</a>, 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.</p>
<p>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.</p>

CC BY-SA 4.0
2022-03-29T14:46:28.967Z
2022-03-29T14:46:28.967Z
Pieter Wuille
<p>In Bitcoin Core, <a href="https://github.com/bitcoin/bitcoin/blob/7c72eabb57bde83abfc4bd5af70b884390ef847d/src/serialize.h#L31" rel="noreferrer"><code>MAX_SIZE</code></a> 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?</p>

CC BY-SA 4.0
2022-03-29T10:21:47.610Z
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
CC BY-SA 4.0
2022-03-29T10:31:26.453Z
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
CC BY-SA 4.0
2022-03-29T10:57:05.570Z
Yes, i meant the size of the INV returned when being sent a `mempool` message.
Antoine Poinsot
CC BY-SA 4.0
2022-03-29T12:18:49.403Z
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.
Ava Chow
<network><p2p><message>
What is the maximum, realistic P2P message payload size?
0xb10c
# What is the maximum, realistic P2P message payload size?

(Asked by: username_0 on 2022-03-29)

In Bitcoin Core, [`MAX_SIZE`](https://github.com/bitcoin/bitcoin/blob/7c72eabb57bde83abfc4bd5af70b884390ef847d/src/serialize.h#L31) 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?

**Tags:** network, p2p, message

> **Comments:**
> **username_1**: 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!  
> **username_0**: 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.  
> **username_1**: Yes, i meant the size of the INV returned when being sent a `mempool` message.  
> **username_2**: 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.  

---

## 1 answers

### Answer by username_3 on 2022-03-29. Score: 6 | Accepted answer

Since Bitcoin Core [pull request 5843](https://github.com/bitcoin/bitcoin/pull/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.


---

