Topic: Loads of fake peers advertised on bitcoin network (Read 635 times)

It smells (read stinks) to me that it could be some government agency, and this is happening in same time when they are pushing hard for some crazy bill regulations for Bitcoin and all crypto.
I can't prove anything but it could be they are collecting information for some tracking and surveillance of all nodes and transactions.

They are both correct (ignoring the errors coming from their methodology). Bitnodes shows nodes that are listening for incoming connection (among spy nodes) but the other is showing all nodes in existence including nodes that don't listen for incoming connections.

The conclusion interest me. Bitcoin have 12775 nodes (according to https://bitnodes.io/ which exclude node which don't accept incoming connection), so DoS cost is quite expensive and it probably only reduce propagation speed to whole network. However, it's major concern for altcoin which have very few full node count.

They are both correct (ignoring the errors coming from their methodology). Bitnodes shows nodes that are listening for incoming connection (among spy nodes) but the other is showing all nodes in existence including nodes that don't listen for incoming connections.

@piotr_n mention Luke's DNS seed down for a while, so i wonder how accurate is it.

So is this number of nodes from Bitnodes more correct than Luke Dashjr version that is showing much more nodes?
https://luke.dashjr.org/programs/bitcoin/files/charts/software.html

We do not know who the spammers are but this might suggest that one of their objectives is learning information about the Bitcoin P2P network, esp. about its topology.

The conclusion interest me. Bitcoin have 12775 nodes

the thousand 'new buckets' approach and each node being able to access only 64 of them, does not seem to be helping much, considering that all the nodes advertise incoming addresses without checking them.

Now imagine scenario that you're starting a new node, with a brand new IP.
It is going to have a hard time getting incoming connections anytime soon, considering that it competes with hundreds of thousands of fake IPs.

Plus every node looses time trying to connect to these fake addresses.
Not sure what is the core's algo of choosing a new IP to connect to, but whatever it is, it will surely also have to deal with a lot of dead tries.

What is the core's algorithm for selecting addresses to return after receiving getaddr request?

Does it only pick those from the "tried" buckets?

Same for sending spontaneous addr messages: does it have to "try" it first, before it can route a new addr to its peeers?
I am not completely sure, but it seems like I'm getting (most of) those fake addresses from a legit bitcoin core peers.
I have a suspicion that because of the algorithm bitcoin core uses for routing new addresses, it's somehow facilitating this problem.

You shouldn't assume everyone use Bitcoin Core. OP is developer of alternative full node client, so it's likely he's talking about his gocoin node.

Here's the reply I got from Pieter Wuille about this subject

I think it's the same as the the result of getnodeaddresses 0 RPC.
Note: it will take a while (GUI will freeze while loading) if you have hundred of thousands of entries in your peers database.

All my nodes' peers databases are now over 700k records
...
Does bitcoin core have a limit of peers upon witch it won't accept new addresses into the database?

> This is an interesting read: https://bitcointalksearch.org/topic/loads-of-fake-peers-advertised-on-bitcoin-network-5348856
>
> So according to this, somebody is spamming the bitcoin network with addr message pointing to invalid addresses and ports, which bloats the peers.dat and corresponding structure in memory.

The peers.dat file and the structure in memory have a fixed size, so those are not a problem.

> Since peers.dat uses a custom record type which I don't know how to parse, I wasn't able to check specifics of IP addresses listed in there, but I believe I have a workaround to prevent this kind of thing from happening. Exactly how easy or difficult it will be to implement this change I don't know.

The "addrman" database is organized into 1024 buckets with "new" addresses (which we haven't tried to connect to), and 256 buckets with "tried" addresses (which we have connected to ourselves). Each bucket consists of 64 positions, and each of those can hold 1 address. Along with the addresses we remember where we originally heard about them (which IP).

Each group of source IPs (/16s etc) selects a subset of just 64 buckets (salted using a host-specific secret key), and inserts the newly received IPs in a position in a bucket in one of those, if certain criteria are met (the position was empty, or it held an IP address that also occurs elsewhere in the table already). This limits the impact an attacker can have, because they cannot under any circumstances affect IPs in buckets outside of the 64 their group maps to.

This database structure is a design from 2012, which was significantly improved following recommendations in the Eclipse Attacks paper (https://cs-people.bu.edu/heilman/eclipse/).

> - Change the AddrDb updating functionality so that it does not add nodes that are unreachable. Not unreachable by timeout, but "connection refused" kind of errors.

In a way we have that; there are separate tables in peers.dat for new and tried addresses. I don't think it's feasible to not add untried addresses at all, as our ability to create connections is far too low to try everything we receive. But I think the existing structure should reasonably protect against spam (in terms of database poisoning; there is certainly a processing cost to it).

Cheers,

--
Pieter

How would I be able to check something like this myself with my own node?

Are you periodically retrieving the data from peers.dat or are you using a better method? If it's the former, then I'll parse the peers.dat later on at fixed intervals and see what I can find.

Yes, they are still coming.

You will only see them in your node's peers database.

I am still not seeing anything out of the ordinary. So either they are hitting specific IPs / Nodes or my SonicWall is blocking them for some reason.
I do have the sonic configured to block botnets, so if the connections are coming from known bad IPs they might never make it in. But other then that I have no idea.

I am still not seeing anything out of the ordinary. So either they are hitting specific IPs / Nodes or my SonicWall is blocking them for some reason.
I do have the sonic configured to block botnets, so if the connections are coming from known bad IPs they might never make it in. But other then that I have no idea.

@piotr_n  are you still seeing the attack?

-Dave