On Thursday 31 January 2008 17:29, Matthew Toseland wrote: > On Thursday 31 January 2008 17:13, Michael Rogers wrote: > > On Jan 31 2008, Matthew Toseland wrote: > > > It might be possible to do some stats, although I dunno exactly how; the > > > second request would be routed differently with per-node failure tables. > > > > Right, but until failure tables are implemented an attacker can guess the > > distance based on how many of the 3 retries reach him. Still, I suppose > > it's an improvement over nearestLoc. > > I'm assuming we make the choice once per peer per startup, for the sake of > minimising the code changes. So it would go the same way - subject to backoff > etc. Maybe he can do stats based on that? > > > > > Well for inserts subject to FEC, weighted coin might work. The concern is > > > that not all inserts are subject to FEC - for example the top block of a > > > splitfile. > > > > You could use a salted hash function to store redundant copies of the top > > block under different keys (all derivable from the "main" key, eg the salt > > values could be 1, 2, 3). But then even single-block inserts would be > > vulnerable to predecessor attacks... > > It's an interesting tradeoff yeah...
You could make an argument on reliability grounds for such a scheme though.. > > > > > Also means that if there's a lot of load we visit fewer nodes per > > > request. > > > > True - in that case toss the coin before visiting each peer, unless the > > previous peer gave us a RejectedOverload, in which case don't count it. But > > I take your point, it is messy. :-) > > > > Cheers, > > Michael > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080131/2d099bc7/attachment.pgp>
