Perhaps by requesting the data from another node? On Thu, May 25, 2006 at 10:20:51AM +0100, Michael Rogers wrote: > Ian Clarke wrote: > >I can see how this distributes bandwidth among relatively equal peers, > >but I'm not seeing a "tit for tat" component here that would reward > >peers for storing and transferring data - which was the goal of my > >suggestion at the start of this thread. Please correct me if I have > >overlooked something. > > No you're right, there's no reciprocal component. Unfortunately I can't > see how to incorporate tit for tat without being able to measure each > peer's level of cooperation. Imagine the following scenario: > > A---B---C > > A generates a request, B forwards it, C responds to it, B forwards the > response back to A. > > B wants to measure C's level of cooperation. It needs to know whether C > provided a valid response, because C might be sending forged responses > in order to get more cooperation from B. In the case of CHKs the request > contains the hash of the expected response, so B can verify the > response. But in the case of inserts there's no way for B to verify the > response. B can't possibly tell (as far as I can see) whether C > forwarded the data or just dropped the data and faked a response. > > I've been working on exactly this problem for my PhD, and unfortunately > the solution I've come up allows unlinkable communication but not > anonymous communication: A and C have to know one another's identities. > B doesn't know whether A is the originator of the request or C is the > originator of the response, but it can still verify that the response > matches the request, so it can measure C's level of cooperation and > adjust its own level of cooperation accordingly. This is fine for > point-to-point communication across an untrusted network, but it's not > suitable for Freenet-style anonymous publishing and retrieval. > > If you can think of a way to verify responses to inserts then I'd be > very happy to work on a reciprocation mechanism, but until then I think > fair resource allocation might be the best we can do. > > Cheers, > Michael > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech >
-- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20060525/5fc11dc9/attachment.pgp>
