Criticism accepted, although I&#39;d appreciate it if you supply some reasons about why it&#39;s such a bad idea :-)<br>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&#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="gmail_quote">On Sat, Dec 17, 2011 at 8:28 PM, Gregory Maxwell <span dir="ltr">&lt;<a href="mailto:gmaxwell@gmail.com">gmaxwell@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Sat, Dec 17, 2011 at 8:37 AM, Christian Decker<br>
&lt;<a href="mailto:decker.christian@gmail.com">decker.christian@gmail.com</a>&gt; wrote:<br>
&gt; My idea was to structure the network in a hypercube and use prefixes to<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, so<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.  (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,  though perhaps I&#39;m more<br>
of a jerk about it.   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 even<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!<br>
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<br>
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>