Looks like they have now switched to “signal” for BIP 110 in their subver. 
Looks like they have now switched to “signal” for BIP 110 in their subver.
These (sybil) nodes make up 92% of the “good” BIP110 nodes my bitcoin seed/crawler knows about: Bitcoin DNS Seeder Analysis
4 Likes
On 2026-03-24 at around 9:20 UTC one of my nodes made five outbound connections to bitprojects nodes. It didn’t have any before. These connections are still active.
I have logs for this, so I can investigate a bit (when I find the time to do so) why exactly this happened.
edit: I had a brief look at the logs. It turns out the node had a brief network disconnect due to datacenter maintaince, lost all it’s peers, and when it came back, it choose to open 5 outbound connection to bitprojects…
1 Like
greetings all, i’m the guy that was running this
update: all of these nodes are now shut down and will not return – intended outcome has been reached, proved the point, and it seems like everyone who needs to understand the severity/risk does see it now.
lmk any questions.
btw this entire infra I stood up cost about $2k/mo
3 Likes
Last stats before everything was shut down:
=== Inbound TCP/8333 (bitcoin) Connection and Network Stats ===
Total unique destination IPs: 3042
Total unique destination /24 subnets: 12
Total destination subnets sharing /16 boundary: 0
Total ASNs: 3 <<< BTW this defeats asmap in current state
Total subnets advertised per ASN: 4
Total inbound connections: 80526
Total unique source IPs: 35127
=== Source IP Connection Thresholds ===
Source IPs with 8+ connections: 653
Source IPs with 10+ connections: 433
Source IPs with 12+ connections: 307
Source IPs with 16+ connections: 178
Source IPs with 32+ connections: 38
Source IPs with 64+ connections: 14
Source IPs with 512+ connections: 0
Source IPs with 2048+ connections: 0
I tend to agree. Thanks.
Since Bitcoin Core nodes make by default 8 outbound-full-relay and 2 block-relay-only connections, I’m assuming every source with more than 10 connections is either a custom client trying to mass-connect to all IPs or multiple Bitcoin Core nodes making connections from the same host / IP.
This still leaves us with 220 nodes potentially making 8+ connections to you. The highest I’ve seen personally is 6 connections to bitprojects for a short while, which is still worrying.
Yeah this is why I split out these connection counts in this way. There were dozens of subnets and single IPs that spun up hundreds or thousands of connections, so I automated null routing those sources once crossing the 1024 threshold.
so at any point in time I believe there were hundreds of nodes that -only- connected to me, and that doesn’t sound good.
when the infra ran uninterrupted for 60+ days these single source counts were double or higher.
I should not be able to do something like this for $2k/mo.
1 Like
@fjahr ASNs are incredibly easy to justify approval for from the RIRs, and cost about $500 each for the higher numbers if buying, less if the RIR is assigning them. Getting dozens of them is easy. Even easier if an attacker is willing to spin up multiple legal entities and set up org accounts w/ the RIRs.
Separately on the IP side, renting/leasing IP space in /24 blocks costs about $0.30-0.40/mo per IP when rented from a third party/non carrier. Even less cost when you’re willing to rent poor reputation IPs, which bitcoin does not care about.
I intend to spin up some ways to pull down the full BGP routing table via API (will also put the code on github, pulls from FRR, can be spun up on cloud providers that support BGP), I think it would be useful to query the full AS path of a given node and use that for warnings. In the case of what I stood up, all of the ASNs and subnets shared common AS path ASNs.
1 Like
Linking to Steep increase in inbound connections on 2026-03-31 at 00:12 UTC here. Seems like @bitprojects shutting down the nodes caused a lot of nodes to look for new outbound peers at the same time.
1 Like
Related to this topic, I opened an issue on the Bitcoin Core repository back in December about updating our peer selection algorithm to be more robust against an attacker “simply” spinning up a high number of nodes across a small number of net groups.
If there is renewed interest in addressing these concerns, i would welcome some feedback there.
1 Like