From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RdjvL-0005TR-1X for bitcoin-development@lists.sourceforge.net; Thu, 22 Dec 2011 14:47:11 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.175 as permitted sender) client-ip=74.125.82.175; envelope-from=andyparkins@gmail.com; helo=mail-we0-f175.google.com; Received: from mail-we0-f175.google.com ([74.125.82.175]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1RdjvF-0008IP-JL for bitcoin-development@lists.sourceforge.net; Thu, 22 Dec 2011 14:47:11 +0000 Received: by werm13 with SMTP id m13so5094882wer.34 for ; Thu, 22 Dec 2011 06:46:59 -0800 (PST) Received: by 10.216.144.138 with SMTP id n10mr5947668wej.57.1324565219427; Thu, 22 Dec 2011 06:46:59 -0800 (PST) Received: from dvr.localnet (mail.360visiontechnology.com. [92.42.121.178]) by mx.google.com with ESMTPS id fi6sm16082397wib.2.2011.12.22.06.46.55 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Dec 2011 06:46:57 -0800 (PST) From: Andy Parkins To: Joel Joonatan Kaartinen Date: Thu, 22 Dec 2011 14:46:54 +0000 User-Agent: KMail/1.13.6 (Linux/3.0.0-1-686-pae; KDE/4.6.3; i686; ; ) References: <201112221152.38639.andyparkins@gmail.com> <1324556083.30850.13.camel@mei> In-Reply-To: <1324556083.30850.13.camel@mei> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2248693.vH8KXUA5LC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201112221446.54526.andyparkins@gmail.com> 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 (andyparkins[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 0.0 AWL AWL: From: address is in the auto white-list X-Headers-End: 1RdjvF-0008IP-JL 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 14:47:11 -0000 --nextPart2248693.vH8KXUA5LC Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2011 December 22 Thursday, 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 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. >=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. Yes; I appreciate that. It's the very point I'm making. A node can choose= =20 what work to do, and should have a way of forwarding the results of that wo= rk=20 to other nodes. Transaction verifification is the main one. Once a negative-announce message exists, it wouldn't be hard to have the ot= her=20 two you need as well: positive-announce and neutral-announce. At present w= e=20 have only neutral-announce. However, as the need for super nodes and=20 distributed verification gets bigger, having the forwarder able to offer an= =20 opinion on the quality of a transaction seems ideal to me. Dishonesty will= =20 get you isolated pretty quickly if you use positive-announce and negative- announce to lie. The problem with this is that it requires a web of trust as well as a web o= f=20 connections. The only way to gain an advantage from this classified=20 forwarding is if you have some way of assigning enough trust so that you ca= n=20 forward a classified transaction _without_ checking it yourself. That does= n't=20 sound like an easy problem though. Andy =2D-=20 Dr Andy Parkins andyparkins@gmail.com --nextPart2248693.vH8KXUA5LC Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk7zQt4ACgkQwQJ9gE9xL21b9wCfZNWbZFNNjLNVgB5Rv5PROeLN rZUAn0s/aI9FCdP2fCWN/3Sx8TZOp8BP =HJ/i -----END PGP SIGNATURE----- --nextPart2248693.vH8KXUA5LC--