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 andypark...@gmail.com
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
