path: root/15/59ef109e6ffbb78caefa686096f65ffb66c3b4

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <decker.christian@gmail.com>) id 1QW5e4-0000YD-EY
	for bitcoin-development@lists.sourceforge.net;
	Mon, 13 Jun 2011 11:49:28 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.47 as permitted sender)
	client-ip=209.85.216.47;
	envelope-from=decker.christian@gmail.com;
	helo=mail-qw0-f47.google.com; 
Received: from mail-qw0-f47.google.com ([209.85.216.47])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1QW5e0-0004y7-MW
	for bitcoin-development@lists.sourceforge.net;
	Mon, 13 Jun 2011 11:49:28 +0000
Received: by qwh5 with SMTP id 5so2827698qwh.34
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 13 Jun 2011 04:49:19 -0700 (PDT)
Received: by 10.229.17.200 with SMTP id t8mr2250969qca.295.1307965758173; Mon,
	13 Jun 2011 04:49:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.247.6 with HTTP; Mon, 13 Jun 2011 04:48:38 -0700 (PDT)
In-Reply-To: <BANLkTi=X4vZn_Oe6iYirp9++jwfXHJaqwg@mail.gmail.com>
References: <BANLkTin_qs4bDabnu+b3K1hTzLzr4JKHsg@mail.gmail.com>
	<BANLkTimDGr-yX9zgS3qWPZALprWCsFieXg@mail.gmail.com>
	<BANLkTi=oYjydw7sT=sqSN3sHMhM+pq=c6w@mail.gmail.com>
	<BANLkTikNd6rqssQ1bHGhPURc7tiXLkBGwQ@mail.gmail.com>
	<BANLkTi=X4vZn_Oe6iYirp9++jwfXHJaqwg@mail.gmail.com>
From: Christian Decker <decker.christian@gmail.com>
Date: Mon, 13 Jun 2011 13:48:38 +0200
Message-ID: <BANLkTikbQpU8+NMT_-f2mVNe-cGLY-ZeuQ@mail.gmail.com>
To: Vladimir Marchenko <vladimir@marchenko.co.uk>
Content-Type: multipart/alternative; boundary=0015175d00fe64f40d04a5968291
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: 1QW5e0-0004y7-MW
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 13 Jun 2011 11:49:28 -0000

--0015175d00fe64f40d04a5968291
Content-Type: text/plain; charset=ISO-8859-1

Yes, those trackers would be hard coded, just like the IRC servers and
channels are hardcoded right now.

The advantages over IRC and DNS Seeds are:
 - sporadic HTTP requests to a tracker, as opposed to keeping an IRC
connection open at all times
 - no virus/botnet like behaviour (automatically join IRC channel with
cryptic name), ISPs tend to bother network admins (like myself) with alerts
when they see this...
 - adapts faster than DNS Seeds which require configuration changes on seed
should the nodes become unreachable
 - we already use HTTP to determine our external IP, so it would be a
consolidation of transports
 - more peers than DNS Seeds (better load balancing)

As for Vladimirs proposal, seems like an extreme measure, that is not really
practical. Also it leads to network partitions since nodes will prefer their
own /8 and /16 networks. IPv6 will also soon be a problem for this method.

On Mon, Jun 13, 2011 at 12:54 PM, Vladimir Marchenko <
vladimir@marchenko.co.uk> wrote:

> one possible bootstrap method of last resort,
>
> 1. create a convention of bitcoind listening on a specific last octest
> of IPv4 address, let's say, .14 when possible. Those of us who have
> access to IP space would use .14's.
>
> 2. if no other bootstrap method works, client could start scanning
> x.x.x.14 addresses, perhaps in some semi-intelligent order (starting
> from more pobable /8's and /16's), if enough people place bitcoind on
> x.x.x.14 than after a 10-100 thousand checks it bound to find a
> bitcoind peer.
>
> It's messy, with all the excessive scanning etc... but it does not
> depend on anything except a bunch of bitcoind by convention preferring
> listening on x.x.x.14's.
>
> Given that this is a method of last resort in bootrap chain it whould
> hopefully not lead to DDOS on those unlucky to own *.14 and not
> running bitcoind there. Also the more people are running bitcoind on
> .14, the quicker it would find a peer, the less scanning to do. It is
> kind of self-regualting.
>
> For whatever it worth...
>
>
> On 13 June 2011 10:56, Jeff Garzik <jgarzik@exmulti.com> wrote:
> > On Mon, Jun 13, 2011 at 5:38 AM, Christian Decker
> > <decker.christian@gmail.com> wrote:
> >> 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.
> >
> > And how does the client discover HTTP trackers?  You're either
> > hardcoding -those- into the client, or adding an additional bootstrap
> > step to discover them.  Either way, it has the same problems as other
> > current methods.
> >
> > The history and experience of gnutella's web caches vs. UDP host
> > caches seems highly relevant here.
> >
> > --
> > Jeff Garzik
> > exMULTI, Inc.
> > jgarzik@exmulti.com
> >
> >
> ------------------------------------------------------------------------------
> > EditLive Enterprise is the world's most technically advanced content
> > authoring tool. Experience the power of Track Changes, Inline Image
> > Editing and ensure content is compliant with Accessibility Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--0015175d00fe64f40d04a5968291
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Yes, those trackers would be hard coded, just like the IRC servers and chan=
nels are hardcoded right now.<br><br>The advantages over IRC and DNS Seeds =
are:<br>=A0- sporadic HTTP requests to a tracker, as opposed to keeping an =
IRC connection open at all times<br>


=A0- no virus/botnet like behaviour (automatically join IRC channel with cr=
yptic name), ISPs tend to bother network admins (like myself) with alerts w=
hen they see this...<br>=A0- adapts faster than DNS Seeds which require con=
figuration changes on seed should the nodes become unreachable<br>

=A0- we already use HTTP to determine our external IP, so it would be a con=
solidation of transports<br>=A0- more peers than DNS Seeds (better load bal=
ancing)<br><br>As for Vladimirs proposal, seems like an extreme measure, th=
at is not really practical. Also it leads to network partitions since nodes=
 will prefer their own /8 and /16 networks. IPv6 will also soon be a proble=
m for this method.<br>

<br><div class=3D"gmail_quote">On Mon, Jun 13, 2011 at 12:54 PM, Vladimir M=
archenko <span dir=3D"ltr">&lt;<a href=3D"mailto:vladimir@marchenko.co.uk">=
vladimir@marchenko.co.uk</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex;">

one possible bootstrap method of last resort,<br>
<br>
1. create a convention of bitcoind listening on a specific last octest<br>
of IPv4 address, let&#39;s say, .14 when possible. Those of us who have<br>
access to IP space would use .14&#39;s.<br>
<br>
2. if no other bootstrap method works, client could start scanning<br>
x.x.x.14 addresses, perhaps in some semi-intelligent order (starting<br>
from more pobable /8&#39;s and /16&#39;s), if enough people place bitcoind =
on<br>
x.x.x.14 than after a 10-100 thousand checks it bound to find a<br>
bitcoind peer.<br>
<br>
It&#39;s messy, with all the excessive scanning etc... but it does not<br>
depend on anything except a bunch of bitcoind by convention preferring<br>
listening on x.x.x.14&#39;s.<br>
<br>
Given that this is a method of last resort in bootrap chain it whould<br>
hopefully not lead to DDOS on those unlucky to own *.14 and not<br>
running bitcoind there. Also the more people are running bitcoind on<br>
.14, the quicker it would find a peer, the less scanning to do. It is<br>
kind of self-regualting.<br>
<br>
For whatever it worth...<br>
<div><div></div><div class=3D"h5"><br>
<br>
On 13 June 2011 10:56, Jeff Garzik &lt;<a href=3D"mailto:jgarzik@exmulti.co=
m">jgarzik@exmulti.com</a>&gt; wrote:<br>
&gt; On Mon, Jun 13, 2011 at 5:38 AM, Christian Decker<br>
&gt; &lt;<a href=3D"mailto:decker.christian@gmail.com">decker.christian@gma=
il.com</a>&gt; wrote:<br>
&gt;&gt; BitTorrent trackers are used to handle several thousands of reques=
ts, so<br>
&gt;&gt; they would probably scale well enough. I&#39;m not even talking ab=
out using the<br>
&gt;&gt; DHT trackers, but using old fashioned HTTP based trackers. The fac=
t that<br>
&gt;&gt; each bitcoin client would contact the tracker would make it very h=
ard for an<br>
&gt;&gt; attacker to get bootstrapping clients to exclusively connect to hi=
s<br>
&gt;&gt; compromised clients. I would say that using a tracker such as Open=
Bittorrent<br>
&gt;&gt; provides the same advantages as using an IRC channel.<br>
&gt;<br>
&gt; And how does the client discover HTTP trackers? =A0You&#39;re either<b=
r>
&gt; hardcoding -those- into the client, or adding an additional bootstrap<=
br>
&gt; step to discover them. =A0Either way, it has the same problems as othe=
r<br>
&gt; current methods.<br>
&gt;<br>
&gt; The history and experience of gnutella&#39;s web caches vs. UDP host<b=
r>
&gt; caches seems highly relevant here.<br>
&gt;<br>
&gt; --<br>
&gt; Jeff Garzik<br>
&gt; exMULTI, Inc.<br>
&gt; <a href=3D"mailto:jgarzik@exmulti.com">jgarzik@exmulti.com</a><br>
&gt;<br>
</div></div>&gt; ----------------------------------------------------------=
--------------------<br>
&gt; EditLive Enterprise is the world&#39;s most technically advanced conte=
nt<br>
&gt; authoring tool. Experience the power of Track Changes, Inline Image<br=
>
&gt; Editing and ensure content is compliant with Accessibility Checking.<b=
r>
&gt; <a href=3D"http://p.sf.net/sfu/ephox-dev2dev" target=3D"_blank">http:/=
/p.sf.net/sfu/ephox-dev2dev</a><br>
&gt; _______________________________________________<br>
&gt; Bitcoin-development mailing list<br>
&gt; <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d=
evelopment@lists.sourceforge.net</a><br>
&gt; <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo=
pment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitco=
in-development</a><br>
&gt;<br>
<br>
---------------------------------------------------------------------------=
---<br>
EditLive Enterprise is the world&#39;s most technically advanced content<br=
>
authoring tool. Experience the power of Track Changes, Inline Image<br>
Editing and ensure content is compliant with Accessibility Checking.<br>
<a href=3D"http://p.sf.net/sfu/ephox-dev2dev" target=3D"_blank">http://p.sf=
.net/sfu/ephox-dev2dev</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br>

--0015175d00fe64f40d04a5968291--