My listening node (Core 31.1) got inbound connections from a small fleet announcing /Satoshi:31.0.0/ that, as far as I can tell, isn’t Bitcoin Core.
Who: 6,591 sessions from 22 IPv4 addresses (Oct 6–18), each in a different /16: AWS in 7 regions (17), Tencent (3), Alibaba (1), China Unicom (1). From Sep 16 to 21 the same addresses partly used /Sat0shi:31.0.0/ (with a zero).
Why I don’t think it’s Core:
No service flags. Core 31 always sets at least NETWORK_LIMITED | WITNESS (init.cpp#L863); NODE_NONE only appears on private-broadcast connections as /pynode:0.0.1/.
The stop: all 11 open sessions, including three that had been connected since Oct 12 and 15, closed between 12:54 and 13:28 UTC on Oct 18. Before that the longest gap between new sessions was 1.4 hours. None has come back to my node since.
Did anyone else see this fleet or the stop, or know who runs it? It looks different from #17: those peers announce 70016 and behave like 70015, and I found no address overlap.
Caveats: one node; polling getpeerinfo every 10 s; I only see the part of the fleet that connected to me.
Happy to share IPs and per-session data privately.
very nice. thanks for sharing! I had encountered this weird user agent as well but hadn’t looked into the details.
it’s interesting that they also reconnect back when we disconnect and end up evicting themselves (like linking lion). I see you’ve mentioned 1.4 hours as the longest time the fleet took to reconnect back - curious what the fleet’s usual reconnection rate is for you? I think I’m seeing 1 sec or less.
apparently these peers were sending us runestones!
the UNCOMMON•GOODS minting is still happening (via ordinary gossip relay) but the operator/operation has changed?
the OP_RETURN from the transactions which /Sat0shi:31.0.0/ peers sent us till October 18 had some extra fields and now the minting which gets mined in bitcoin blocks don’t have it anymore.
here’s what 1 of these peers sent node len from peer.observer (basically unsolicited runestone tx):
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?
Yesterday, I took a look at those nodes appearing on my node running peer-observer, about 31.0.0 + ver 70015 and p2aburn*. The images below show a counter on how many connections those peers opened to us per day, for reference here is the promql that generated this:
sum by (useragent) (
increase(peerobserver_p2p_version_useragent{useragent=~"/p2aburn.*|/Sat0shi:31.0.0/"}[1d])
)
p2aburn still active but in a way lower volume than before, unlike fleet which is zero.
I didn’t see any of you mentioning it, but on 2026-10-18 many vps providers had rebooted their machines due to CVE-2026-99999 (including mine), see more at #189. I suppose the operators didn’t realize it yet, maybe at some point they will.
I see some sort of correlation with what’s happening with compact block reconstruction degradation as discussed in delving#1052, I’m still writing a BNOC’s post about it, your report gave me some insights, thank you @benunskilled and @stratospher!
Thanks, the timeline is very helpful. Your last /Sat0shi:31.0.0/ on Sep 22 matches my node, when the same addresses switched to /Satoshi:31.0.0/
On the CVE reboots: I’m not sure they explain the stop, at least on my node. From Oct 16 the fleet only reached me from 8 AWS addresses, and AWS said EC2 was not affected and needed no action (2026-137-AWS). The last sessions from all 8 closed within about a minute (13:27–13:28 UTC on Oct 18), spread over 6 AWS regions on three continents. Host reboots across six regions at the same moment seem unlikely to me, and none of the fleet came back from any address since, so it looks more like something central on the operator’s side. That could still be a reboot, e.g. if their controller ran at one of the providers that did restart, so I can’t rule your idea out.
Looking forward to your post on the compact block side!
Since both seem to be re-connecting (probably because we kept evicting them), the number times we saw their version doesn’t indicate that they held X connections on that day.
As it also touches this post, I have found /txbroadcast:0.1/ that seems to act similarly as /Sat0shi:31.0.0/ and /Satoshi:31.0.0/ + 70015, it appeared a bit before Sat0shi. More details on #198.
