Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Michael_Gr=F8nager?= <gronager@ceptacle.com>
In-Reply-To: <CALxbBHW4v2FohtaFi0MRey5RoBQodEK5kPsGCAv5xVmmDOOjZQ@mail.gmail.com>
Date: Thu, 22 Dec 2011 10:18:52 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <84C7327F-4149-4F69-8D7A-F5B3BBE96FA4@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>
	<028C9CB5-A7C9-4042-BC00-269046E2DD19@ceptacle.com>
	<CALxbBHW4v2FohtaFi0MRey5RoBQodEK5kPsGCAv5xVmmDOOjZQ@mail.gmail.com>
To: Christian Decker <decker.christian@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Protocol extensions
Precedence: list

>=20
> As for the DHT we had a few brainstorming sessions a while back on the =
forum http://bit.ly/sc2RLZ (gmaxwell didn't like it then either :D)
> Forcing someone to participate in a fixed position in the block =
storage network is a good way to reduce the risk of a sybil attack as =
Michael said. The hash should include only information that cannot be =
changed by the user, so IP can be used, but including the port is risky.

Agree, that is why we need to keep the different A.B segment requirement =
as is also imposed in the client today.

>=20
> Broadcasting the transactions would not need to be done, since miners =
fetch them from their storage place, alternatively we could use the inv =
broadcast to notify peers about a new block/transaction and let it =
retrieve them from the permanent storage (DHT or block storage network). =
If we route traffic internally in the DHT we could even start caching at =
nodes leading to the real location, since announcements would lead to =
flashcrowds, putting heavy load on the responsible nodes. Caching is not =
a risk since the hash of the object to be retrieved is already known.

I agree that in practice the thinner nodes would most likely just serve =
as cache, but they need notification on tx'es involving some of their tx =
outs or involving some of theirs bitcoin addresses. Today there are some =
designs that operate with a thin client that connects to a (web)server =
and subscribe to listen for transactions involving a specific bitcoin =
address. By letting that be a part of the hash space including that =
address you would not reveal your address to the server and we would =
keep a true p2p setup.

Best regards,

Michael

>=20
> Regards,
> Chris
>=20
> On Wed, Dec 21, 2011 at 1:41 PM, Michael Gr=F8nager =
<gronager@ceptacle.com> wrote:
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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).
>=20
> Cheers,
>=20
> M
>=20
>=20
>=20
> On 21/12/2011, at 12:42, Eric Lombrozo wrote:
>=20
>> 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
>> new or port existing apps to sell to consumers worldwide. Explore the
>> 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
>=20
>=20
>=20
>=20
>=20
> =
--------------------------------------------------------------------------=
----
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. =
Create
> new or port existing apps to sell to consumers worldwide. Explore the
> 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
>=20