From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RdKZN-0006Jp-K0 for bitcoin-development@lists.sourceforge.net; Wed, 21 Dec 2011 11:42:49 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.47 as permitted sender) client-ip=209.85.212.47; envelope-from=elombrozo@gmail.com; helo=mail-vw0-f47.google.com; Received: from mail-vw0-f47.google.com ([209.85.212.47]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1RdKZJ-0007Oq-Vh for bitcoin-development@lists.sourceforge.net; Wed, 21 Dec 2011 11:42:49 +0000 Received: by vbbfc21 with SMTP id fc21so7946325vbb.34 for ; Wed, 21 Dec 2011 03:42:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.240.144 with SMTP id wa16mr3453265vdc.33.1324467760452; Wed, 21 Dec 2011 03:42:40 -0800 (PST) Received: by 10.52.162.6 with HTTP; Wed, 21 Dec 2011 03:42:40 -0800 (PST) In-Reply-To: <67FAA76C-1734-471D-A3D8-31E5216DD512@ceptacle.com> References: <82659F61-0449-47BB-88DC-497E0D02F8A1@ceptacle.com> <4EEE58CA.5090902@justmoon.de> <67FAA76C-1734-471D-A3D8-31E5216DD512@ceptacle.com> Date: Wed, 21 Dec 2011 03:42:40 -0800 Message-ID: From: Eric Lombrozo To: Bitcoin Dev Content-Type: text/plain; charset=ISO-8859-1 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 (elombrozo[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 X-Headers-End: 1RdKZJ-0007Oq-Vh 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: Wed, 21 Dec 2011 11:42:49 -0000 Is it just me or does it seem inevitable that at some point supernodes will emerge that other nodes trust to validate transactions for them? Supernodes needn't even store the entire block chain and transaction pool...it would be sufficient that they keep lists of IP addresses of other trustworthy nodes and partition them into a hashspace. Anonymous peers have no reputation to defend...but a trusted supernode would, which could provide just enough incentive for the supernode to do its best to ensure the nodes it vouches for are indeed legit. Of course, unless the supernode is validating the entire block chain and transaction pool itself, it could only assess the trustworthiness of other nodes by performing random sampling. Michael, I really like your ideas and the clarity you bring to the issue. Regarding the potential attack vector you mention, would it be possible to partition the hashspace to minimize the risk that an attacker can manage to disproportionately gain control over a part of the hashspace?