Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Rs5P3-0006e6-Gf for bitcoin-development@lists.sourceforge.net; Tue, 31 Jan 2012 04:33:09 +0000 X-ACL-Warn: Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Rs5P2-0003CM-I4 for bitcoin-development@lists.sourceforge.net; Tue, 31 Jan 2012 04:33:09 +0000 Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D112220F6A for ; Mon, 30 Jan 2012 23:33:02 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 30 Jan 2012 23:33:02 -0500 X-Sasl-enc: o7iC7JBRu7C237LGhOcfFt0jeIpFElMoHTuXbCcdY9cP 1327984382 Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mail.messagingengine.com (Postfix) with ESMTPSA id A34668E0169 for ; Mon, 30 Jan 2012 23:33:02 -0500 (EST) Received: by qaea17 with SMTP id a17so3449360qae.13 for ; Mon, 30 Jan 2012 20:33:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.174.76 with SMTP id s12mr25371476qaz.11.1327984382467; Mon, 30 Jan 2012 20:33:02 -0800 (PST) Received: by 10.229.238.147 with HTTP; Mon, 30 Jan 2012 20:33:02 -0800 (PST) In-Reply-To: References: Date: Mon, 30 Jan 2012 21:33:02 -0700 Message-ID: From: Michael Hendricks To: Gavin Andresen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Rs5P2-0003CM-I4 Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] CAddrMan: Stochastic IP address manager X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 04:33:09 -0000 On Mon, Jan 30, 2012 at 7:05 PM, Gavin Andresen w= rote: > 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. =C2=A0When 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". --=20 Michael