On 25 May 2006, at 02:20, 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. > > 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.
Even if we can't find a way to incorporate inserts into the "tit-for- tat" mechanism, there is still much value in implementing such a mechanism for requests. > 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. Note that it is B's choice as to whether to send the request to C in the first place. Even if C is faking responses, that will only lead to B incurring a debt to C, which will make B less likely to forward requests to C in future. Essentially I think the question is whether it is really such a bad thing if C can mislead its neighbors into thinking that it is inserting when it really isn't. What is the worst case scenario here? Ian.
