From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RdhCf-0000IF-Pv for bitcoin-development@lists.sourceforge.net; Thu, 22 Dec 2011 11:52:53 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.53 as permitted sender) client-ip=74.125.82.53; envelope-from=andyparkins@gmail.com; helo=mail-ww0-f53.google.com; Received: from mail-ww0-f53.google.com ([74.125.82.53]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76) id 1RdhCZ-0001V9-UQ for bitcoin-development@lists.sourceforge.net; Thu, 22 Dec 2011 11:52:53 +0000 Received: by wgbds1 with SMTP id ds1so14386498wgb.10 for ; Thu, 22 Dec 2011 03:52:41 -0800 (PST) Received: by 10.227.208.129 with SMTP id gc1mr12666356wbb.4.1324554761785; Thu, 22 Dec 2011 03:52:41 -0800 (PST) Received: from dvr.localnet (mail.360visiontechnology.com. [92.42.121.178]) by mx.google.com with ESMTPS id w8sm21837275wiz.4.2011.12.22.03.52.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Dec 2011 03:52:40 -0800 (PST) From: Andy Parkins To: Michael =?iso-8859-1?q?Gr=F8nager?= Date: Thu, 22 Dec 2011 11:52:38 +0000 User-Agent: KMail/1.13.6 (Linux/3.0.0-1-686-pae; KDE/4.6.3; i686; ; ) References: <201112221012.55565.andyparkins@gmail.com> <23F92B83-4E96-401B-8A1C-3E6FE9DD8A8B@ceptacle.com> In-Reply-To: <23F92B83-4E96-401B-8A1C-3E6FE9DD8A8B@ceptacle.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1367782.kJgnHEgzSE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201112221152.38639.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: 1RdhCZ-0001V9-UQ 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 11:52:53 -0000 --nextPart1367782.kJgnHEgzSE Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 2011 December 22 Thursday, Michael Gr=F8nager wrote: > But, there is in fact a subtle difference: If anyone can choose to verify > at random, you will see lazy implementations where random means none, and > as it is random you cannot, from the outside, judge if a node is taking > part in the validation work or if it just benefitting from others > announcements. In the hash space part, you can monitor peers and see if > they did not tell you about a failed validation and then disconnect from > them as they are either malicious or lazy. 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 opti= on=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 no= de=20 is incorrectly negative-announcing then it can justifiably be kicked. > Besides from that, I like a setup where we scream about failed > verifications, but keep a low profile on things that actually verifies... Me too. It's important though to distinguish between "you must be verifyin= g"=20 and "if you do verify, you must be honest about it". No node should be for= ced=20 to do any work it doesn't want to; but they should be forced to be truthful= =20 about the work they choose to do. Andy =2D-=20 Dr Andy Parkins andyparkins@gmail.com --nextPart1367782.kJgnHEgzSE 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) iEYEABECAAYFAk7zGgYACgkQwQJ9gE9xL215nACgkdGcnKFc+uit6/wS3f5/BrQy cYkAnjLknl94uKch3USfVz8zFfM6+UKC =AYgO -----END PGP SIGNATURE----- --nextPart1367782.kJgnHEgzSE--