rich1.0npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynhttps://nostr.ae/npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynnjumphttps://nostr.ae📅 Original date posted:2011-12-17 🗒️ Summary of this message: Chris proposed a hypercube network structure to reduce network load, but Gregory advised presenting a working implementation to solve attack resistance problems. 📝 Original message: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 at gmail.com> wrote: > On Sat, Dec 17, 2011 at 8:37 AM, Christian Decker > <decker.christian at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111217/6edf419e/attachment.html>