Michael Hendricks [ARCHIVE] on Nostr: 📅 Original date posted:2012-01-31 📝 Original message:On Mon, Jan 30, 2012 at ...
📅 Original date posted:2012-01-31
📝 Original message:On Mon, Jan 30, 2012 at 7:05 PM, Gavin Andresen <gavinandresen at gmail.com> wrote:
> Given the randomness in Pieter's design, that seems extremely unlikely
> / difficult to do. Is it possible to do a back-of-the-envelope
> calculation to figure out what percentage of nodes on the network an
> attacker would have to control to have a (say) 1% chance of a
> successful Sybil attack?
The randomness prevents finely crafted attacks since an attacker can't
predict which bucket his address ends up in. I don't think it helps
against brute force attacks though. If 60% of the network's nodes are
controlled by an evil botnet, 60% of the nodes we pull out of the
address manager point to the attacker. If a client has 8 connections
to the network, a Sybil attack would succeed 1.7% of the time. At
current network size, 60% of listening nodes is 2,800; only 2-5% of a
decent botnet.
Nodes that accept incoming connections are far less vulnerable, since
the probability of success decreases exponentially with the number of
connections. 95% botnet control with 125 connections has 10^-6 chance
of success.
Perhaps we could add a command-line option for increasing the maximum
number of outbound connections. That way, nodes unable to accept
incoming connections can easily decrease their susceptibility to Sybil
attack.
> I've also been wondering if it is time to remove the IRC bootstrapping
> mechanism; it would remove a fair bit of code and we'd stop getting
> reports that various ISPs tag bitcoin as malware. When testing the
> list of built-in bootstrapping IP addresses I always connect fairly
> quickly, and the DNS seeding hosts seems to be working nicely, too.
I think it should be disabled by default one release after the new
address manager is released. That way, we're not changing too many
parts of the bootstrapping process at once.
As an aside, I can't help but wonder whether ISPs blocking IRC traffic
filters some botnets out of the IRC bootstrapping channels; keeping
them more "pure".
--
Michael
📝 Original message:On Mon, Jan 30, 2012 at 7:05 PM, Gavin Andresen <gavinandresen at gmail.com> wrote:
> Given the randomness in Pieter's design, that seems extremely unlikely
> / difficult to do. Is it possible to do a back-of-the-envelope
> calculation to figure out what percentage of nodes on the network an
> attacker would have to control to have a (say) 1% chance of a
> successful Sybil attack?
The randomness prevents finely crafted attacks since an attacker can't
predict which bucket his address ends up in. I don't think it helps
against brute force attacks though. If 60% of the network's nodes are
controlled by an evil botnet, 60% of the nodes we pull out of the
address manager point to the attacker. If a client has 8 connections
to the network, a Sybil attack would succeed 1.7% of the time. At
current network size, 60% of listening nodes is 2,800; only 2-5% of a
decent botnet.
Nodes that accept incoming connections are far less vulnerable, since
the probability of success decreases exponentially with the number of
connections. 95% botnet control with 125 connections has 10^-6 chance
of success.
Perhaps we could add a command-line option for increasing the maximum
number of outbound connections. That way, nodes unable to accept
incoming connections can easily decrease their susceptibility to Sybil
attack.
> I've also been wondering if it is time to remove the IRC bootstrapping
> mechanism; it would remove a fair bit of code and we'd stop getting
> reports that various ISPs tag bitcoin as malware. When testing the
> list of built-in bootstrapping IP addresses I always connect fairly
> quickly, and the DNS seeding hosts seems to be working nicely, too.
I think it should be disabled by default one release after the new
address manager is released. That way, we're not changing too many
parts of the bootstrapping process at once.
As an aside, I can't help but wonder whether ISPs blocking IRC traffic
filters some botnets out of the IRC bootstrapping channels; keeping
them more "pure".
--
Michael