Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QW3zW-0008DC-SC for bitcoin-development@lists.sourceforge.net; Mon, 13 Jun 2011 10:03:30 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.182 as permitted sender) client-ip=209.85.216.182; envelope-from=decker.christian@gmail.com; helo=mail-qy0-f182.google.com; Received: from mail-qy0-f182.google.com ([209.85.216.182]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1QW3zR-00012s-F1 for bitcoin-development@lists.sourceforge.net; Mon, 13 Jun 2011 10:03:30 +0000 Received: by qyk27 with SMTP id 27so3007281qyk.13 for ; Mon, 13 Jun 2011 03:03:20 -0700 (PDT) Received: by 10.229.29.20 with SMTP id o20mr3598879qcc.181.1307957933122; Mon, 13 Jun 2011 02:38:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.247.6 with HTTP; Mon, 13 Jun 2011 02:38:13 -0700 (PDT) In-Reply-To: References: From: Christian Decker Date: Mon, 13 Jun 2011 11:38:13 +0200 Message-ID: To: Jeff Garzik Content-Type: multipart/alternative; boundary=0016364271d6fc244e04a594af4f X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is freemail (decker.christian[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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 0.0 RFC_ABUSE_POST Both abuse and postmaster missing on sender domain 0.0 AWL AWL: From: address is in the auto white-list X-Headers-End: 1QW3zR-00012s-F1 Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Bootstrapping via BitTorrent trackers 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: Mon, 13 Jun 2011 10:03:31 -0000 --0016364271d6fc244e04a594af4f Content-Type: text/plain; charset=ISO-8859-1 Don't get me wrong, DNS Seeding is an excellent way to bootstrap via trusted nodes, I'm not trying to replace it. What I'm trying to get rid of is the IRC bootstrapping and the hardcoded nodes in the client, they're easy targets. BitTorrent trackers are used to handle several thousands of requests, so they would probably scale well enough. I'm not even talking about using the DHT trackers, but using old fashioned HTTP based trackers. The fact that each bitcoin client would contact the tracker would make it very hard for an attacker to get bootstrapping clients to exclusively connect to his compromised clients. I would say that using a tracker such as OpenBittorrent provides the same advantages as using an IRC channel. On Mon, Jun 13, 2011 at 11:09 AM, Jeff Garzik wrote: > On Mon, Jun 13, 2011 at 4:55 AM, Christian Decker > wrote: > > We have quite a few bootstrapping mechanisms, starting with the overly > > complex (IMHO) IRC bootstrapping, which is often suspected as > bot-activity. > > Then we have a few hardcoded nodes and some fallback nodes. I was > wondering > > why we didn't adopt BitTorrent tracker bootstrapping until now? It's > > basically all it does. Given a hash (SHA1 hash of the genesis bloc would > be > > nice ^^) it gives you a list of other nodes with the same hash. > > It seems to offer few benefits over DNS seeding, while potentially > potentially creating a vulnerable hot spot in the DHT. Sybil attacks > on DHTs are well documented. > > -- > Jeff Garzik > exMULTI, Inc. > jgarzik@exmulti.com > --0016364271d6fc244e04a594af4f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Don't get me wrong, DNS Seeding is an excellent way to bootstrap via tr= usted nodes, I'm not trying to replace it.
What I'm trying to ge= t rid of is the IRC bootstrapping and the hardcoded nodes in the client, th= ey're easy targets.

BitTorrent trackers are used to handle several thousands of requests, s= o they would probably scale well enough. I'm not even talking about usi= ng the DHT trackers, but using old fashioned HTTP based trackers. The fact = that each bitcoin client would contact the tracker would make it very hard = for an attacker to get bootstrapping clients to exclusively connect to his = compromised clients. I would say that using a tracker such as OpenBittorren= t provides the same advantages as using an IRC channel.

On Mon, Jun 13, 2011 at 11:09 AM, Jeff Garzi= k <jgarzik@exmu= lti.com> wrote:
On Mon, Jun 13, 2011 at 4:55 AM, Christian Decker
<decker.christian@gmail.co= m> wrote:
> We have quite a few bootstrapping mechanisms, starting with the overly=
> complex (IMHO) IRC bootstrapping, which is often suspected as bot-acti= vity.
> Then we have a few hardcoded nodes and some fallback nodes. I was wond= ering
> why we didn't adopt BitTorrent tracker bootstrapping until now? It= 's
> basically all it does. Given a hash (SHA1 hash of the genesis bloc wou= ld be
> nice ^^) it gives you a list of other nodes with the same hash.

It seems to offer few benefits over DNS seeding, while potentially potentially creating a vulnerable hot spot in the DHT. =A0Sybil attacks
on DHTs are well documented.

--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com

--0016364271d6fc244e04a594af4f--