Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.47 as permitted sender)
	client-ip=209.85.215.47; envelope-from=joel.kaartinen@gmail.com;
	helo=mail-lpp01m010-f47.google.com; 
From: Joel Joonatan Kaartinen <joel.kaartinen@gmail.com>
To: Andy Parkins <andyparkins@gmail.com>
In-Reply-To: <201112221152.38639.andyparkins@gmail.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>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 22 Dec 2011 14:14:43 +0200
Message-ID: <1324556083.30850.13.camel@mei>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Protocol extensions
Precedence: list

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 
> the other nodes.  You can't force any node not to be lazy, since their option 
> is to disconnect themselves.  As to maliciousness, that is defended against 
> because when a node negative announces a transaction, that transaction is 
> going to be checked (note that there is still no implicit trust) -- if a node 
> is incorrectly negative-announcing then it can justifiably be kicked.

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.

- Joel