Thanks! The tx breakdown explains a lot.
On reconnects: I poll getpeerinfo every 10 s, so sessions that end within a second like yours never show up for me. My inbound slots are full too. What I see for Oct 6–18:
- 17 of the 22 IPs held 2–3 connections at once. In 83 % of cases a new connection from an IP appeared and an older one from the same IP was gone within the same poll, which fits the self-eviction you describe.
- Across the fleet, a new visible session started about once a minute (median; 90 % within 7 min). The 1.4 h in my post was the longest of these gaps, not a per-IP reconnect time.
Possibly related to your burn row: a peer announcing /p2aburn:1.0/ (one IPv4 at Tencent, AS132203, not one of the 22) has connected to my node since at least Sep 16 and is still around after Oct 18. No service flags, protocol 70016. In its three longer sessions since Oct 16 it pushed unsolicited tx messages totalling 27,360, 1,080 and 2,700 bytes. All three are exact multiples of 90 (24-byte header + 66-byte tx), so 304, 12 and 30 transactions if each message is one tx. None were new to my mempool. I didn’t log txids, so I can’t confirm they’re P2A burns, but the size matches.
One question: you write /Sat0shi:31.0.0/ with a zero. On my node the same IPs used that spelling only until about Sep 21 and /Satoshi:31.0.0/ after that. Did yours keep the zero until Oct 18?