From: Phantomcircuit <phantomcircuit@covertinferno•org>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] CAddrMan: Stochastic IP address manager
Date: Tue, 31 Jan 2012 04:21:09 -0500 [thread overview]
Message-ID: <4F27B285.6060105@covertinferno.org> (raw)
In-Reply-To: <CAFHuXuZ78y3nHfuKBgjO1j+bNsdnbngDee_Xii4xGhUshJqtZQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2305 bytes --]
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.
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4515 bytes --]
prev parent reply other threads:[~2012-01-31 9:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-30 2:31 Pieter Wuille
2012-01-30 2:37 ` Luke-Jr
2012-01-30 16:53 ` Michael Hendricks
2012-01-31 2:05 ` Gavin Andresen
2012-01-31 2:07 ` Luke-Jr
2012-01-31 2:57 ` Gregory Maxwell
2012-01-31 8:19 ` grarpamp
2012-01-31 13:50 ` solar
2012-01-31 4:33 ` Michael Hendricks
2012-01-31 7:17 ` Gregory Maxwell
2012-01-31 15:06 ` Michael Hendricks
2012-01-31 15:07 ` Michael Hendricks
2012-01-31 9:21 ` Phantomcircuit [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F27B285.6060105@covertinferno.org \
--to=phantomcircuit@covertinferno$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox