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: <1324556083.30850.13.camel@mei>
Date: Thu, 22 Dec 2011 13:42:08 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <9E0AD741-A670-469D-9F50-5F1564A0E7C6@ceptacle.com>
References: <CABr1YTebhitO4g-SarZ7H=aoG9a8zW1wd0rfR32o8i0vODbLJw@mail.gmail.com>
	<201112221012.55565.andyparkins@gmail.com>
	<23F92B83-4E96-401B-8A1C-3E6FE9DD8A8B@ceptacle.com>
	<201112221152.38639.andyparkins@gmail.com>
	<1324556083.30850.13.camel@mei>
To: Joel Joonatan Kaartinen <joel.kaartinen@gmail.com>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Protocol extensions
Precedence: list

Just adding to Joels comment:

The only one with an incentive to do validations are miners (otherwise =
they could risk having their mined blocks invalidated later by less lazy =
miners) and the ones who are to send and accept a transaction. In a =
distributed stored and validated block chain setup, you would hence need =
to ask some miners if the inputs to a transaction is valid or download =
all the chain yourselves.

The latter is what we do today and will not scale, the former is the =
logical consequence of a non-enforced random validation approach - so =
this will give us super nodes, namely miners, and at some point they =
could choose to also charge for the validations. It might be the =
direction we are moving towards, but then the p2p network is only for =
the miners and the rest of us can connect through https and use json-rpc =
to post transactions etc to them. I do, however, prefer a setup where we =
keep everything really distributed...

/M

On 22/12/2011, at 13:14, Joel Joonatan Kaartinen wrote:

> On Thu, 2011-12-22 at 11:52 +0000, Andy Parkins wrote:
>> Why should they have to?  Joining the network as a node is very low =
cost to=20
>> the other nodes.  You can't force any node not to be lazy, since =
their option=20
>> is to disconnect themselves.  As to maliciousness, that is defended =
against=20
>> because when a node negative announces a transaction, that =
transaction is=20
>> going to be checked (note that there is still no implicit trust) -- =
if a node=20
>> is incorrectly negative-announcing then it can justifiably be kicked.
>=20
> a node that is not doing any checking themselves can not reliably
> forward failed verifications without getting the blame for doing =
faulty
> work. Those nodes would then have the incentive not to relay the =
failed
> verifications. This ends up making it important to know which nodes =
will
> be checking transactions or not so you don't isolate yourself from =
other
> nodes that are also checking transactions.
>=20
> - Joel
>=20

Michael Gronager, PhD
Owner Ceptacle / NDGF Director, NORDUnet A/S
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 62 14 01
E-mail: gronager@ceptacle.com