Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.53 as permitted sender)
	client-ip=74.125.82.53; envelope-from=decker.christian@gmail.com;
	helo=mail-ww0-f53.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAAS2fgRqabDpXBZ7M8BAdzDAsRwFED4BPzoQJkLkwLOeURuXLA@mail.gmail.com>
References: <CABr1YTebhitO4g-SarZ7H=aoG9a8zW1wd0rfR32o8i0vODbLJw@mail.gmail.com>
	<82659F61-0449-47BB-88DC-497E0D02F8A1@ceptacle.com>
	<CALxbBHUXEJLRDZ=RS1vuvkm7rDjFUPir0sU__f6TJXiTTQxWzA@mail.gmail.com>
	<CAAS2fgRqabDpXBZ7M8BAdzDAsRwFED4BPzoQJkLkwLOeURuXLA@mail.gmail.com>
From: Christian Decker <decker.christian@gmail.com>
Date: Sat, 17 Dec 2011 21:34:14 +0100
Message-ID: <CALxbBHWvJwOvnpGjN+A3MpzxrvzFGuJ0JBv6z_zz99Hvs0T+yg@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=0015174c103669976804b44fa66d
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Protocol extensions
Precedence: list

--0015174c103669976804b44fa66d
Content-Type: text/plain; charset=ISO-8859-1

Criticism accepted, although I'd appreciate it if you supply some reasons
about why it's such a bad idea :-)
The idea was never really popular and before starting work on a real
implementation I wanted to test the water, and should it turn out it's
complete non-sense I'm happy to accept that.

I don't want to have a DHT for the DHTs sake, I was more interested in
reducing the number of messages that need to be sent around the network,
since network load is going to be a major problem if we ever grow beyond a
certain point.

Just wanting to brainstorm.

Regards,
Chris
On Sat, Dec 17, 2011 at 8:28 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:

> On Sat, Dec 17, 2011 at 8:37 AM, Christian Decker
> <decker.christian@gmail.com> wrote:
> > My idea was to structure the network in a hypercube and use prefixes to
> > address different parts of the network, and use those prefixes also to
> find
> > the location where an item (transaction, block, ...) should be stored.
> Each
> > vertex in the hypercube is a small, highly connected, cluster of nodes.
>
> I strongly advise people who are not me to use this sort of scheme, so
> that I may enjoy the benefits of robbing you blind.
>
>
> .... But really, saying "some sort of DHT" without basically
> presenting a working implementation that demonstrates the feasibility
> of solving the very difficulty attack resistance problems these
> schemes have basically triggers my time-wasting-idiot filter.  (Or
> likewise, presenting a fixed network structure that would have a nice
> small and easily identifiable min-cut...)
>
> I don't doubt I'm completely alone in this,  though perhaps I'm more
> of a jerk about it.   Even if your actual proposal might have some
> merit you should be aware that every fool who has operated a
> bittorrent client has heard of "DHT" and, although they may not even
> understand what a hash table is, many have no reservation going around
> suggesting them for _every_ distributed systems problem. Want to scale
> matrix multiples? DHT! Want to validate bitcoin blocks? DHT! Network
> syncup slow (because It's bound on validation related local IO)? DHT!
> I suggest people solve the real problems first, then worry what name
> to give the solutions. ;)
>
> To address gavin's tragedy of the commons concern, one useful feature
> would being able to mutually authenticate a peer... then full nodes
> could pick and choose which lite nodes they're willing to do (a lot
> of) hard work for. This would also be valuable because some modes of
> lite operation require non-zero trust of the full node being queried.
>

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

Criticism accepted, although I&#39;d appreciate it if you supply some reaso=
ns about why it&#39;s such a bad idea :-)<br>The idea was never really popu=
lar and before starting work on a real implementation I wanted to test the =
water, and should it turn out it&#39;s complete non-sense I&#39;m happy to =
accept that.<br>

<br>I don&#39;t want to have a DHT for the DHTs sake, I was more interested=
 in reducing the number of messages that need to be sent around the network=
, since network load is going to be a major problem if we ever grow beyond =
a certain point.<br>

<br>Just wanting to brainstorm.<br><br>Regards,<br>Chris<br><div class=3D"g=
mail_quote">On Sat, Dec 17, 2011 at 8:28 PM, Gregory Maxwell <span dir=3D"l=
tr">&lt;<a href=3D"mailto:gmaxwell@gmail.com">gmaxwell@gmail.com</a>&gt;</s=
pan> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Sat, Dec 17, 2011 at 8:=
37 AM, Christian Decker<br>
&lt;<a href=3D"mailto:decker.christian@gmail.com">decker.christian@gmail.co=
m</a>&gt; wrote:<br>
&gt; My idea was to structure the network in a hypercube and use prefixes t=
o<br>
&gt; address different parts of the network, and use those prefixes also to=
 find<br>
&gt; the location where an item (transaction, block, ...) should be stored.=
 Each<br>
&gt; vertex in the hypercube is a small, highly connected, cluster of nodes=
.<br>
<br>
</div>I strongly advise people who are not me to use this sort of scheme, s=
o<br>
that I may enjoy the benefits of robbing you blind.<br>
<br>
<br>
.... But really, saying &quot;some sort of DHT&quot; without basically<br>
presenting a working implementation that demonstrates the feasibility<br>
of solving the very difficulty attack resistance problems these<br>
schemes have basically triggers my time-wasting-idiot filter. =A0(Or<br>
likewise, presenting a fixed network structure that would have a nice<br>
small and easily identifiable min-cut...)<br>
<br>
I don&#39;t doubt I&#39;m completely alone in this, =A0though perhaps I&#39=
;m more<br>
of a jerk about it. =A0 Even if your actual proposal might have some<br>
merit you should be aware that every fool who has operated a<br>
bittorrent client has heard of &quot;DHT&quot; and, although they may not e=
ven<br>
understand what a hash table is, many have no reservation going around<br>
suggesting them for _every_ distributed systems problem. Want to scale<br>
matrix multiples? DHT! Want to validate bitcoin blocks? DHT! Network<br>
syncup slow (because It&#39;s bound on validation related local IO)? DHT!<b=
r>
I suggest people solve the real problems first, then worry what name<br>
to give the solutions. ;)<br>
<br>
To address gavin&#39;s tragedy of the commons concern, one useful feature<b=
r>
would being able to mutually authenticate a peer... then full nodes<br>
could pick and choose which lite nodes they&#39;re willing to do (a lot<br>
of) hard work for. This would also be valuable because some modes of<br>
lite operation require non-zero trust of the full node being queried.<br>
</blockquote></div><br>

--0015174c103669976804b44fa66d--