Re: [freehaven-dev] Some possible weaknesses?

[dmolnar <dmolnar@hcs.harvard.edu>]

> In your example of a few high-bandwidth nodes and the remainder
> low-bandwidth nodes, did you mean that reconstruction would only look
> to the 'backup' nodes if the main ones went down? How would it know?
> Doesn't this add extra rules -- extra complexity -- to the system?
> Does it really buy us anything?

I'm sorry. I should have been more clear. 

As I understand it, to reconstruct a file F, we post or multicast 
a request for all shares of file F. A client can do this by posting a
request for all shares signed by the public key corresponding to F. 

Now the request goes to all the servnet nodes holding shares via the
mix-net. These nodes then send back the shares they hold to the client.

Reconstruction on the client's part can and should take place as soon
as he has enough shares. This is independent of how many shares each 
servnet node holds -- as soon as we get T shares, we're golden. 

It's just that if more shares arrive over the same, lower-latency link, we
get to T faster. No extra complexity needed, _assuming_ we have this
distribution of shares (acheiving that distribution may add more
complexity, but that seems to me a separate topic). 

The other shares will arrive anyway, but I think that's OK. As Roger has
pointed out, trying to _stop them_ by notifying the mixnet or the servnet
nodes that the client already has enough is not worth the hassle! 

When I wrote that the reconstruction would "look for the backup nodes",
what I meant and should have written was that I assumed that the backup
nodes would have smaller shares and lower bandwidth. So reconstruction
would tend to occur BEFORE the shares of such nodes have a chance to reach
the client. 

So if the main nodes go down, then those "backup" shares, which before
arrived too late to help in reconstructing, will now arrive at the
client and reconstruct the file. At which point the client, if he  
wants, can find some new high-bandwidth nodes and reshare the file. 

Is this more clear? 

Thanks, 
-David