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; 
From: Andy Parkins <andyparkins@gmail.com>
To: Joel Joonatan Kaartinen <joel.kaartinen@gmail.com>
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: <CABr1YTebhitO4g-SarZ7H=aoG9a8zW1wd0rfR32o8i0vODbLJw@mail.gmail.com>
	<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>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Protocol extensions
Precedence: list

--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--