Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: =?iso-8859-1?Q?Michael_Gr=F8nager?= <gronager@ceptacle.com>
In-Reply-To: <CABr1YTdUQeAuw2vwZS=VvDU1dTrN+eqjHRXMsZp2axcxbTsO8A@mail.gmail.com>
Date: Wed, 21 Dec 2011 13:41:51 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <028C9CB5-A7C9-4042-BC00-269046E2DD19@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>
	<CABr1YTdUQeAuw2vwZS=VvDU1dTrN+eqjHRXMsZp2axcxbTsO8A@mail.gmail.com>
To: Eric Lombrozo <elombrozo@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Protocol extensions
Precedence: list

I find it likely that we will at some point have supernodes. If we have =
browser based wallets then the server for these automatically becomes =
supernodes. Further, if we move along that direction, it becomes much =
simpler to use both the scheme I proposed or to use a a lot of other =
schemes for sharing the validation work on a farm constituting the =
supernode.

However, if we want to keep bitcoin in a real p2p setup and enable =
scalability in terms of ensuring both thin and fat client to connect =
then we need to go along the path I propose.

Actually, after thinking a bit more about the possible new attack vector =
I don't find it that alarming - if you still require 7 confirmations of =
any bigger transaction before you, as receiver accepts the transaction =
as payed you will not risk anything. The question is then if it is =
sufficiently easy to fake small transaction to e.g. gain access to =
micropayment based web services. I would again say no - the requirement =
that you have ok from e.g. 8 different A.B nodes will make it extremely =
difficult to cheat, and that would even require you to gain some level =
of control over the network that the service you want to cheat is =
connected through.

This means that you should not divide the hash space more finely than =
you would at all times be able to find 8 different A.B nodes. As the =
number of clients grows you can then divide the hash space further. =
(with 100000 nodes today and a division into 512 parts you would have =
approx 200 nodes to choose from).

Cheers,

M


On 21/12/2011, at 12:42, Eric Lombrozo wrote:

> 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.
>=20
> 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.
>=20
> 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?
>=20
> =
--------------------------------------------------------------------------=
----
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. =
Create=20
> new or port existing apps to sell to consumers worldwide. Explore the=20=

> Intel AppUpSM program developer opportunity. =
appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development