{"type":"rich","version":"1.0","author_name":"npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn","author_url":"https://nostr.ae/npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2011-12-17\n🗒️ 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.\n📝 Original message:Criticism accepted, although I'd appreciate it if you supply some reasons\nabout why it's such a bad idea :-)\nThe idea was never really popular and before starting work on a real\nimplementation I wanted to test the water, and should it turn out it's\ncomplete non-sense I'm happy to accept that.\n\nI don't want to have a DHT for the DHTs sake, I was more interested in\nreducing the number of messages that need to be sent around the network,\nsince network load is going to be a major problem if we ever grow beyond a\ncertain point.\n\nJust wanting to brainstorm.\n\nRegards,\nChris\nOn Sat, Dec 17, 2011 at 8:28 PM, Gregory Maxwell \u003cgmaxwell at gmail.com\u003e wrote:\n\n\u003e On Sat, Dec 17, 2011 at 8:37 AM, Christian Decker\n\u003e \u003cdecker.christian at gmail.com\u003e wrote:\n\u003e \u003e My idea was to structure the network in a hypercube and use prefixes to\n\u003e \u003e address different parts of the network, and use those prefixes also to\n\u003e find\n\u003e \u003e the location where an item (transaction, block, ...) should be stored.\n\u003e Each\n\u003e \u003e vertex in the hypercube is a small, highly connected, cluster of nodes.\n\u003e\n\u003e I strongly advise people who are not me to use this sort of scheme, so\n\u003e that I may enjoy the benefits of robbing you blind.\n\u003e\n\u003e\n\u003e .... But really, saying \"some sort of DHT\" without basically\n\u003e presenting a working implementation that demonstrates the feasibility\n\u003e of solving the very difficulty attack resistance problems these\n\u003e schemes have basically triggers my time-wasting-idiot filter.  (Or\n\u003e likewise, presenting a fixed network structure that would have a nice\n\u003e small and easily identifiable min-cut...)\n\u003e\n\u003e I don't doubt I'm completely alone in this,  though perhaps I'm more\n\u003e of a jerk about it.   Even if your actual proposal might have some\n\u003e merit you should be aware that every fool who has operated a\n\u003e bittorrent client has heard of \"DHT\" and, although they may not even\n\u003e understand what a hash table is, many have no reservation going around\n\u003e suggesting them for _every_ distributed systems problem. Want to scale\n\u003e matrix multiples? DHT! Want to validate bitcoin blocks? DHT! Network\n\u003e syncup slow (because It's bound on validation related local IO)? DHT!\n\u003e I suggest people solve the real problems first, then worry what name\n\u003e to give the solutions. ;)\n\u003e\n\u003e To address gavin's tragedy of the commons concern, one useful feature\n\u003e would being able to mutually authenticate a peer... then full nodes\n\u003e could pick and choose which lite nodes they're willing to do (a lot\n\u003e of) hard work for. This would also be valuable because some modes of\n\u003e lite operation require non-zero trust of the full node being queried.\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111217/6edf419e/attachment.html\u003e"}