<p>A sybil attack is prevented by using proof of work. Overwhelming the network with nodes cannot substitute for the hash power required to create the proof of work that must be presented in order to get the network to accept a new block.</p>

<p>An eclipse attack is more difficult to prevent:</p>

<blockquote>
  <p>Bitcoin Core only makes an outbound connection to one IP address per
  /16 (x.y.0.0). Incoming connections are unlimited and unregulated, but
  this is generally only a problem in the anonymity case where you're
  probably already unable to accept incoming connections. See
  <a href="https://en.bitcoin.it/wiki/Weaknesses#Sybil_attack" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/Weaknesses#Sybil_attack</a>.</p>
</blockquote>

<p>As far as I'm aware there is no such logic implemented to equalize the network resources between nodes.</p>

CC BY-SA 4.0
2019-07-27T21:31:49.183Z
I understand PoW, but that's not the type of Sybil attack I'm talking about. The Sybil attack I'm talking about is about an entity creating many bitcoin network nodes and doing nefarious things to the network, like slowing down traffic or eating up connections. The eclipse prevention mechanism you mention helps for certain things, but not for others. For example, it doesn't prevent a Sybil attacker from matching transactions to IP addresses.
B T
CC BY-SA 4.0
2019-07-27T21:44:28.530Z
nodes can be run anonymously to prevent IP address matching.
JBaczuk
CC BY-SA 4.0
2019-07-27T23:38:41.477Z
Incoming connections are actually also regulated, but only once the max connections limit is reached. After that, new connections are still allowed, but subject to certain scoring conditions (including IP range based), and if the new connection is better than an existing one, the existing one is disconnected; otherwise, the new one is.
Pieter Wuille
CC BY-SA 4.0
2019-07-31T17:32:30.500Z
Interesting. @PieterWuille what other scoring conditions are there? Is there a good concise list somewhere (maybe in a source file)?
B T
CC BY-SA 4.0
2019-07-27T21:03:56.683Z
2019-07-27T21:03:56.683Z
JBaczuk
<p>What countermeasures does Bitcoin currently have in place to limit Sybil attacks (ie of full nodes [not miners]) and eclipse attacks? </p>

<p>In particular, it seems like an important countermeasure would be to attempt to give your connections only about as much resources (bandwidth/processing/etc) as they're giving back to you, so as to ensure that a sybil attacker must cost approximately the same amount as an honest node. But I get the feeling this doesn't exist. Does it? </p>

<p>Are there other countermeasures in place currently?</p>

<sybil-attack><eclipse-attack>
How does Bitcoin currently mitigate Sybil and Eclipse attacks?
B T
# How does Bitcoin currently mitigate Sybil and Eclipse attacks?

(Asked by: username_0 on 2019-07-27)

What countermeasures does Bitcoin currently have in place to limit Sybil attacks (ie of full nodes [not miners]) and eclipse attacks?

In particular, it seems like an important countermeasure would be to attempt to give your connections only about as much resources (bandwidth/processing/etc) as they're giving back to you, so as to ensure that a sybil attacker must cost approximately the same amount as an honest node. But I get the feeling this doesn't exist. Does it?

Are there other countermeasures in place currently?

**Tags:** sybil-attack, eclipse-attack


---

## 1 answers

### Answer by username_1 on 2019-07-27. Score: 1

A sybil attack is prevented by using proof of work. Overwhelming the network with nodes cannot substitute for the hash power required to create the proof of work that must be presented in order to get the network to accept a new block.

An eclipse attack is more difficult to prevent:

> Bitcoin Core only makes an outbound connection to one IP address per
> /16 (x.y.0.0). Incoming connections are unlimited and unregulated, but
> this is generally only a problem in the anonymity case where you're
> probably already unable to accept incoming connections. See
> <https://en.bitcoin.it/wiki/Weaknesses#Sybil_attack>.

As far as I'm aware there is no such logic implemented to equalize the network resources between nodes.

> **Comments:**
> **username_0**: I understand PoW, but that's not the type of Sybil attack I'm talking about. The Sybil attack I'm talking about is about an entity creating many bitcoin network nodes and doing nefarious things to the network, like slowing down traffic or eating up connections. The eclipse prevention mechanism you mention helps for certain things, but not for others. For example, it doesn't prevent a Sybil attacker from matching transactions to IP addresses.  
> **username_1**: nodes can be run anonymously to prevent IP address matching.  
> **username_2**: Incoming connections are actually also regulated, but only once the max connections limit is reached. After that, new connections are still allowed, but subject to certain scoring conditions (including IP range based), and if the new connection is better than an existing one, the existing one is disconnected; otherwise, the new one is.  
> **username_0**: Interesting. @username_2 what other scoring conditions are there? Is there a good concise list somewhere (maybe in a source file)?  

---

