Developing Trust in the system

--===============0530184631070052953==
Content-Type: multipart/alternative; 
	boundary="----=_Part_19033_32802229.1210251533205"

------=_Part_19033_32802229.1210251533205
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hey

I was just thinking about how to develop trust in the Gnutella System and a
thought crossed my mind.

Developing trust in the presence of a central server is a pretty standard
problem and there exist a lot of research on it. Companies like eBay are
already using it with a lot of sucess. So, how about we have a central
server which manages the global reputation of all the peers. Now the problem
is how to diseminate this trust into the system whenever required without
having to put *too much load on the central serve*r.

To solve this problem let us assume a peer A needs to know about the
reputation of say Peer B. Peer A will send a reputation query to its
neigbors and these neighbors to their neighbors and so on till it reaches a
peer which can answer this query. Now say Peer C has the answer to this
reputation query. Peer C will send the Reputation Query Reply back from the
same path it got the Reputation Query. Hence, Peer A will end up getting the
reputation score of Peer B.

Now, in case no peer replies with an answer, Peer A will after a certain
timeout, will request the central server  for the reputation. The central
server will reply will an answer to this query. This answer will contain the
reputation score *signed by the Central Server's private key*.

An important thing to be noted here is that the answer is signed by the
central server's private key. Hence, whenever A gets the request for say B's
reputation score, A will reply with the same answer(signed with central
server's private key). This will make sure that A hasn't made any changed to
the reputation score.

Another way could be, if peer A needs reputation of Peer B then it can ask B
itself for the answer. B will then have to reply with an answer which is
signed by the central server's private key.

Comments invited!

Regards
Lapsy

------=_Part_19033_32802229.1210251533205
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hey<br><br>I was just thinking about how to develop trust in the Gnutella System and a thought crossed my mind. <br><br>Developing trust in the presence of a central server is a pretty standard problem and there exist a lot of research on it. Companies like eBay are already using it with a lot of sucess. So, how about we have a central server which manages the global reputation of all the peers. Now the problem is how to diseminate this trust into the system whenever required without having to put <b>too much load on the central serve</b>r. <br>
<br>To solve this problem let us assume a peer A needs to know about the reputation of say Peer B. Peer A will send a reputation query to its neigbors and these neighbors to their neighbors and so on till it reaches a peer which can answer this query. Now say Peer C has the answer to this reputation query. Peer C will send the Reputation Query Reply back from the same path it got the Reputation Query. Hence, Peer A will end up getting the reputation score of Peer B. <br>
<br>Now, in case no peer replies with an answer, Peer A will after a certain timeout, will request the central server&nbsp; for the reputation. The central server will reply will an answer to this query. This answer will contain the reputation score <b>signed by the Central Server&#39;s private key</b>.<br>
<br>An important thing to be noted here is that the answer is signed by the central server&#39;s private key. Hence, whenever A gets the request for say B&#39;s reputation score, A will reply with the same answer(signed with central server&#39;s private key). This will make sure that A hasn&#39;t made any changed to the reputation score.<br>
<br>Another way could be, if peer A needs reputation of Peer B then it can ask B itself for the answer. B will then have to reply with an answer which is signed by the central server&#39;s private key.<br><br>Comments invited!<br>
<br>Regards<br>Lapsy<br>

------=_Part_19033_32802229.1210251533205--

--===============0530184631070052953==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
core-dev mailing list
[email protected]
http://lists.limewire.org/mailman/listinfo/core-dev

--===============0530184631070052953==--