p2p: ban peers that send large NOTFOUND msgs?

brunoerg commented at 4:03 pm on March 7, 2026: contributor

Currently, NOTFOUND is sent in response to a GETDATA message which can contain at most MAX_INV_SZ items. If a peer sends a GETDATA message with more items than MAX_INV_SZ, the node is banned (Misbehaving).

I think it would make sense to add the same for NOTFOUND messages since sending more items than it is possible for GETDATA would not make sense, and we would also avoid to allocate more memory than is necessary (within the 4MB limit).

maflcko added the label P2P on Mar 10, 2026

fanquake added the label Brainstorming on Mar 10, 2026

fanquake commented at 8:15 am on March 17, 2026: member

cc @mzumsande @ajtowns @naiyoma

ajtowns commented at 1:52 am on March 18, 2026: contributor

Are we seeing large NOTFOUND messages in the wild?

Rather than banning, perhaps we should just process them more efficiently? Something like:

 0--- a/src/net_processing.cpp
 1+++ b/src/net_processing.cpp
 2@@ -5149,17 +5149,19 @@ void PeerManagerImpl::ProcessMessage(Peer& peer, CNode& pfrom, const std::string
 3
 4     if (msg_type == NetMsgType::NOTFOUND) {
 5         std::vector<CInv> vInv;
 6-        vRecv >> vInv;
 7-        std::vector<GenTxid> tx_invs;
 8-        if (vInv.size() <= node::MAX_PEER_TX_ANNOUNCEMENTS + MAX_BLOCKS_IN_TRANSIT_PER_PEER) {
 9-            for (CInv &inv : vInv) {
10+        unsigned int n_inv = ReadCompactSize(vRecv);
11+        if (n_inv <= node::MAX_PEER_TX_ANNOUNCEMENTS + MAX_BLOCKS_IN_TRANSIT_PER_PEER) {
12+            std::vector<GenTxid> tx_invs;
13+            while (n_inv-- > 0) {
14+                CInv inv;
15+                vRecv >> inv;
16                 if (inv.IsGenTxMsg()) {
17                     tx_invs.emplace_back(ToGenTxid(inv));
18                 }
19             }
20+            LOCK(m_tx_download_mutex);
21+            m_txdownloadman.ReceivedNotFound(pfrom.GetId(), tx_invs);
22         }
23-        LOCK(m_tx_download_mutex);
24-        m_txdownloadman.ReceivedNotFound(pfrom.GetId(), tx_invs);
25         return;
26     }

mzumsande commented at 8:49 am on March 18, 2026: contributor

I think banning here would make sense for consistency reasons, but probably won’t make much of a practical difference:

I think the current philosophy is that we allow peers to waste our resources to some degree unpunished. They can do so by sending us junk data in various ways (e.g. orphan txns, addr messages, invs). So if someone wants to do that just to annoy us, I don’t think they’d really opt to use NOTFOUND - after all I don’t think the serialization of 4MB into a vector is particularly resource intensive, compared to the cost of processing other junk data, such as INVs which trigger map lookups etc.?

0xB10C commented at 8:56 am on March 23, 2026: contributor

Are we seeing large NOTFOUND messages in the wild?

I don’t collect data on individual messages sizes, but summing up the bytes of NOTFOUND messages we receive per minute seems to be maxing out around 40kB/m over the last 30 days.

The average NOTFOUND message size is around 40 to 50 bytes.

p2p: ban peers that send large NOTFOUND msgs? #34771