<p>There are multiple different lines of defense against the scenario you describe.</p>
<p>When nodes connect to each other, they exchange information about the best chaintips they know about. Nodes will then aim to catch up with the one that has the most work in total accumulated difficulty. Low-work chains will be easy to dismiss in comparison. This means that when a node has a single peer that has the best chain, it'll end up on the best chain.</p>
<p>When nodes connect to the network, they first try finding the peers they knew about already from their previous connections. If they have no previous connections, to find the first nodes on the network, they reach out to a DNS seed. These DNS seeds provide long lists of potential peers from nodes they've seen on the network themselves. The node then makes outbound connections to eight of them. The DNS seeds are run by community members and have been reliable. The node will ask for further peers and continuously check whether there are actual Bitcoin nodes associated with the addresses it hears about to build up a list of potential peers.</p>
<p>If however the attacker operated a DNS seed, they could eclipse new node victims by only providing IPs of their own nodes. If this attack were aimed at everyone that connects to this DNS seed, such an attack would probably be noticed quickly and the DNS seed fixed/removed. If it were targeted against a specific individual it would be extremely unlikely that the victim connects specifically to the attacker's DNS seed, and the attacker would need to know the victim's IP address in advance. Also, node operators subject to the eclipse attack could easily break out by manually connecting to a single honest node. If the node operator notices that something is weird (e.g. the latest blocks don't correspond to the publicly documented blokchain), the node operator could find an IP address of a honest node either on one of the many forums or a site that tracks Bitcoin node population like <a href="https://bitnodes.io/" rel="nofollow noreferrer">https://bitnodes.io/</a> and manually connect to it. Once they have a single honest connection, this connection will gossip more peers to them.</p>
<p>Nodes actively manage their peers. They prefer to stay connected to nodes that have provided them useful information. When they connect to a new peer, they drop the peer that hasn't provided new useful information for the longest time. If a peer has both honest peers and low-POW attacker peers, the attacker peers would get dropped first. This would cause the attacker nodes to be practically expelled from the network: nobody would gossip about them, they'd not be on DNS seed lists, nobody would ever connect to them.</p>
<p>There are a few more things that Bitcoin does, like picking peers from different IP spaces, block-only connections, feeler connections, etc., but that might go a bit too deep into the weeds.</p>

CC BY-SA 4.0
2022-01-02T02:52:02.917Z
Thanks this is very helpful. Deep in the weeds is exactly what I'm looking for as I'm implementing a full crypto currency from the ground up. If you have any links to the source code for peer management that'd be super helpful. I've looked through the bitcoin source but it's quite a large project, difficult to find these nuances portions.
user491880
CC BY-SA 4.0
2022-01-01T14:58:01.723Z
2022-01-01T14:58:01.723Z
Murch
<p>I'm interested in the exact specifics of how Bitcoin rejects a &quot;false&quot; chain. Suppose I create thousands of arbitrary low POW chains and launch peers on the BTC network that clients will (with some probability) connect to. If I make enough of these fake peers the probability will be quite high (perhaps even enough that many clients would get all 8 random peers that are fake).</p>
<p>How do the clients that receive data from these fake peers determine that the chains being provided are fake?</p>

<sybil-attack>
How does bitcoin determine whether or not a peer is lying about having a valid chain?
user491880
# How does bitcoin determine whether or not a peer is lying about having a valid chain?

(Asked by: username_0 on 2022-01-01)

I'm interested in the exact specifics of how Bitcoin rejects a "false" chain. Suppose I create thousands of arbitrary low POW chains and launch peers on the BTC network that clients will (with some probability) connect to. If I make enough of these fake peers the probability will be quite high (perhaps even enough that many clients would get all 8 random peers that are fake).

How do the clients that receive data from these fake peers determine that the chains being provided are fake?

**Tags:** sybil-attack


---

## 1 answers

### Answer by username_1 on 2022-01-01. Score: 2 | Accepted answer

There are multiple different lines of defense against the scenario you describe.

When nodes connect to each other, they exchange information about the best chaintips they know about. Nodes will then aim to catch up with the one that has the most work in total accumulated difficulty. Low-work chains will be easy to dismiss in comparison. This means that when a node has a single peer that has the best chain, it'll end up on the best chain.

When nodes connect to the network, they first try finding the peers they knew about already from their previous connections. If they have no previous connections, to find the first nodes on the network, they reach out to a DNS seed. These DNS seeds provide long lists of potential peers from nodes they've seen on the network themselves. The node then makes outbound connections to eight of them. The DNS seeds are run by community members and have been reliable. The node will ask for further peers and continuously check whether there are actual Bitcoin nodes associated with the addresses it hears about to build up a list of potential peers.

If however the attacker operated a DNS seed, they could eclipse new node victims by only providing IPs of their own nodes. If this attack were aimed at everyone that connects to this DNS seed, such an attack would probably be noticed quickly and the DNS seed fixed/removed. If it were targeted against a specific individual it would be extremely unlikely that the victim connects specifically to the attacker's DNS seed, and the attacker would need to know the victim's IP address in advance. Also, node operators subject to the eclipse attack could easily break out by manually connecting to a single honest node. If the node operator notices that something is weird (e.g. the latest blocks don't correspond to the publicly documented blokchain), the node operator could find an IP address of a honest node either on one of the many forums or a site that tracks Bitcoin node population like <https://bitnodes.io/> and manually connect to it. Once they have a single honest connection, this connection will gossip more peers to them.

Nodes actively manage their peers. They prefer to stay connected to nodes that have provided them useful information. When they connect to a new peer, they drop the peer that hasn't provided new useful information for the longest time. If a peer has both honest peers and low-POW attacker peers, the attacker peers would get dropped first. This would cause the attacker nodes to be practically expelled from the network: nobody would gossip about them, they'd not be on DNS seed lists, nobody would ever connect to them.

There are a few more things that Bitcoin does, like picking peers from different IP spaces, block-only connections, feeler connections, etc., but that might go a bit too deep into the weeds.

> **Comments:**
> **username_0**: Thanks this is very helpful. Deep in the weeds is exactly what I'm looking for as I'm implementing a full crypto currency from the ground up. If you have any links to the source code for peer management that'd be super helpful. I've looked through the bitcoin source but it's quite a large project, difficult to find these nuances portions.  

---

