From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RdhZS-0000xK-53 for bitcoin-development@lists.sourceforge.net; Thu, 22 Dec 2011 12:16:26 +0000 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; Received: from mail-lpp01m010-f47.google.com ([209.85.215.47]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1RdhZO-00044l-77 for bitcoin-development@lists.sourceforge.net; Thu, 22 Dec 2011 12:16:26 +0000 Received: by lami14 with SMTP id i14so4735938lam.34 for ; Thu, 22 Dec 2011 04:16:15 -0800 (PST) Received: by 10.152.145.71 with SMTP id ss7mr7109522lab.28.1324556175644; Thu, 22 Dec 2011 04:16:15 -0800 (PST) Received: from [193.199.8.205] (GGZYMMMCCCV.gprs.sl-laajakaista.fi. [193.199.8.205]) by mx.google.com with ESMTPS id lr3sm7382890lab.17.2011.12.22.04.16.13 (version=SSLv3 cipher=OTHER); Thu, 22 Dec 2011 04:16:14 -0800 (PST) From: Joel Joonatan Kaartinen To: Andy Parkins In-Reply-To: <201112221152.38639.andyparkins@gmail.com> References: <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 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (joel.kaartinen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1RdhZO-00044l-77 Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Protocol extensions X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 12:16:26 -0000 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