Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RbzwL-00071z-9n for bitcoin-development@lists.sourceforge.net; Sat, 17 Dec 2011 19:29:01 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.47 as permitted sender) client-ip=209.85.212.47; envelope-from=gmaxwell@gmail.com; helo=mail-vw0-f47.google.com; Received: from mail-vw0-f47.google.com ([209.85.212.47]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1RbzwK-0006X0-Ne for bitcoin-development@lists.sourceforge.net; Sat, 17 Dec 2011 19:29:01 +0000 Received: by vbbfc21 with SMTP id fc21so4567081vbb.34 for ; Sat, 17 Dec 2011 11:28:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.172.196 with SMTP id be4mr8575181vdc.80.1324150135349; Sat, 17 Dec 2011 11:28:55 -0800 (PST) Received: by 10.220.4.68 with HTTP; Sat, 17 Dec 2011 11:28:55 -0800 (PST) In-Reply-To: References: <82659F61-0449-47BB-88DC-497E0D02F8A1@ceptacle.com> Date: Sat, 17 Dec 2011 14:28:55 -0500 Message-ID: From: Gregory Maxwell To: Christian Decker Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.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 commonly abused enduser mail provider (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -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 AWL AWL: From: address is in the auto white-list X-Headers-End: 1RbzwK-0006X0-Ne Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Protocol extensions X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 19:29:01 -0000 On Sat, Dec 17, 2011 at 8:37 AM, Christian Decker 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.