2026 10 dont evict on frequent reconnect #36561

Add two rolling bloom filters to CConnman that record which addresses
(IPv6: which /48s) made inbound connection attempts in the current and
the previous INBOUND_RECONNECT_WINDOW (10 minutes). The filters are
swapped once a window has passed, so an address is remembered for
between one and two windows after its last attempt and then forgotten.
If more than two windows pass without any attempt, both filters are
cleared.

NoteInboundAttempt() records an attempt and reports whether the same
key made at least two attempts within that time. The threshold is two
rather than one so that a single honest retry is never counted: a peer
whose first connection was closed before it received anything retries
once with v1 (V2Transport::ShouldReconnectV1), and a node that restarts
reconnects once. An address that connects three times in twenty
minutes is not doing either. It is not used yet.

IPv6 is keyed by /48 because the entity this targets controls a whole
/48 and could otherwise use a fresh address per attempt. Honest nodes
sharing a /48 are lumped together; in practice that is rare (a day of
inbound traffic on a busy node showed 60 distinct /48s carrying 64
distinct /64s) and it only matters while the node is full.

Since the filters can't count, each key uses two entries: key+1 after
the first attempt and key+2 after the second. Entries are only inserted
when not already present: every insert counts towards the filter's own
generation rollover, and an address that retries every second must not
push the others out.

When an inbound connection arrives from an address that already made
two attempts within the last one to two INBOUND_RECONNECT_WINDOWs and
all inbound slots are taken, drop the new connection instead of
evicting an existing peer for it. If a slot is free the connection is
accepted as before, so this is not a ban: it only decides who gives
way when we are full.

This targets entities that open many short-lived inbound connections
and reconnect within a second of being disconnected. On a full node
every such attempt evicted an existing peer, which is almost always
the youngest one, i.e. an honest peer that connected a moment ago.

Inbound Tor connections (which all come from the local Tor proxy),
local addresses in general and NoBan peers are not tracked. The
test-only option -test=inbound_reconnect_check_local applies the check
to local addresses so that the functional tests, which connect from
127.0.0.1, can exercise it.

The result is stored in CNode::m_recent_reconnect for use by the
tx-relay capacity check in net_processing.

With -inboundrelaypercent, a new inbound peer that relays transactions
can evict an existing tx-relaying inbound peer when it sends its
version message (or later, when it switches to tx relay with
filterload/filterclear). On nodes with default settings the tx-relay
slots fill long before the overall inbound limit, so this is where
reconnecting entities evict the most peers.

Apply the same rule as in CreateNodeFromAcceptedSocket: if the address
of the new peer connected recently, drop the new peer when the
tx-relay slots are full, instead of evicting an existing one.

Split CConnman::EvictTxPeerIfFull() into InboundTxRelayFull() and the
eviction attempt so that the capacity check can be used on its own.

Cover both paths of the reconnect check with -maxconnections=13 (two
inbound slots, one of them for tx relay): a reconnecting address is
accepted while a slot is free, dropped at accept time when the inbound
slots are full, dropped after version (and after filterload) when the
tx-relay slot is taken, forgotten after two windows, and treated as
before without the test-only option that includes local addresses in
the check.

With two inbound slots nothing is ever evictable, so p2p_eviction.py is
extended to run its 21-peer setup a second time with the check applied
to local addresses: the peer that triggered an eviction before is now
dropped instead, and all other peers stay connected.