1

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?

B T
  • 1,569
  • 13
  • 27

1 Answers1

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.

JBaczuk
  • 7,278
  • 1
  • 11
  • 32
  • 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 Jul 27 '19 at 21:31
  • nodes can be run anonymously to prevent IP address matching. – JBaczuk Jul 27 '19 at 21:44
  • 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. – Pieter Wuille Jul 27 '19 at 23:38
  • 1
    Interesting. @PieterWuille what other scoring conditions are there? Is there a good concise list somewhere (maybe in a source file)? – B T Jul 31 '19 at 17:32