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.
> 
> 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 
what work to do, and should have a way of forwarding the results of that work 
to other nodes.  Transaction verifification is the main one.

Once a negative-announce message exists, it wouldn't be hard to have the other 
two you need as well: positive-announce and neutral-announce.  At present we 
have only neutral-announce.  However, as the need for super nodes and 
distributed verification gets bigger, having the forwarder able to offer an 
opinion on the quality of a transaction seems ideal to me.  Dishonesty will 
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 of 
connections.  The only way to gain an advantage from this classified 
forwarding is if you have some way of assigning enough trust so that you can 
forward a classified transaction _without_ checking it yourself.  That doesn't 
sound like an easy problem though.



Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com