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; 
MIME-Version: 1.0
In-Reply-To: <67FAA76C-1734-471D-A3D8-31E5216DD512@ceptacle.com>
References: <CABr1YTebhitO4g-SarZ7H=aoG9a8zW1wd0rfR32o8i0vODbLJw@mail.gmail.com>
	<82659F61-0449-47BB-88DC-497E0D02F8A1@ceptacle.com>
	<CALxbBHUXEJLRDZ=RS1vuvkm7rDjFUPir0sU__f6TJXiTTQxWzA@mail.gmail.com>
	<4EEE58CA.5090902@justmoon.de>
	<67FAA76C-1734-471D-A3D8-31E5216DD512@ceptacle.com>
Date: Wed, 21 Dec 2011 03:42:40 -0800
Message-ID: <CABr1YTdUQeAuw2vwZS=VvDU1dTrN+eqjHRXMsZp2axcxbTsO8A@mail.gmail.com>
From: Eric Lombrozo <elombrozo@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [Bitcoin-development] Protocol extensions
Precedence: list

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?