On 01/30/2012 11:33 PM, Michael Hendricks wrote:
> On Mon, Jan 30, 2012 at 7:05 PM, Gavin Andresen <gavinandresen@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".
>
If the number of outbound connections is increased the delay of
transaction broadcast code needs to be improved to avoid a broadcast storm.