public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Michael Hendricks <michael@ndrix.org>
To: Gavin Andresen <gavinandresen@gmail.com>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] CAddrMan: Stochastic IP address manager
Date: Mon, 30 Jan 2012 21:33:02 -0700	[thread overview]
Message-ID: <CAFHuXuZ78y3nHfuKBgjO1j+bNsdnbngDee_Xii4xGhUshJqtZQ@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T0avsrL3134WaA3boG-cdx2NcgEH1mQG7Cef78ZV5UNkw@mail.gmail.com>

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".

-- 
Michael



  parent reply	other threads:[~2012-01-31  4:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-30  2:31 [Bitcoin-development] CAddrMan: Stochastic IP address manager 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 [this message]
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

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=CAFHuXuZ78y3nHfuKBgjO1j+bNsdnbngDee_Xii4xGhUshJqtZQ@mail.gmail.com \
    --to=michael@ndrix.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=gavinandresen@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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