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-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Rdhya-0002oA-2n for bitcoin-development@lists.sourceforge.net; Thu, 22 Dec 2011 12:42:24 +0000 X-ACL-Warn: Received: from backup-server.nordu.net ([193.10.252.66]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1RdhyV-000581-SW for bitcoin-development@lists.sourceforge.net; Thu, 22 Dec 2011 12:42:24 +0000 Received: from [109.105.106.215] ([109.105.106.215]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pBMCg8Qf021163 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Dec 2011 13:42:09 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_Gr=F8nager?= 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: <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 X-Mailer: Apple Mail (2.1251.1) X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1RdhyV-000581-SW 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:42:24 -0000 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