Re: [GNUnet-developers] Re: [Help-gnunet] GNUnet CVS branched

[Christian Grothoff]

On Wednesday 24 November 2004 13:27, Ludovic Courtès wrote:
> Hi Christian,
>
> One day, 18 hours, 2 minutes, 4 seconds ago,
>
> Christian Grothoff wrote:
> > I've just added a branch to GNUnet CVS for continued development of the
> > 0.6.* codebase.  The HEAD will move on towards 0.7.0, breaking
> > compatibility and being highly, highly unstable.  In fact, it is likely
> > not to compile for a while.  If it compiles, it'll probably crash, if it
> > does not crash, it will definitively not connect to the existing network.
> >  You get the idea.  I'll post a note once it is safe to try things, until
> > then CVS HEAD will only be useful for people that want to get their hands
> > dirty (i.e., code).
>
> Is there a place where we can learn more about the current plans for
> 0.7?

CVS! :-)  Ok, to be honest, I've not had the time to write up much of the 
details, but the list of recently resolved bugs in Mantis might give you some 
hints. Also, there will finally be KBlocks (see ERCS paper) and I plan on 
having 64-bit filesize support. One of the bigger changes is to break the 
system into smaller pieces with clear interfaces to make it more flexible.  
If you look in CVS, the GNUnet core (src/server/) is down from 12.400 lines 
of C code to 5600 lines of C code. 

> BTW, did you read the criticisms of GNUnet's economic model in [1]?

Yes, well, it's only one sentence really.  The key question here is, how often 
and how dramatically will a node change the set of connected peers, which 
depends on how long peers stay on-line, how large the network is, and how 
direct the impact experienced by the user is supposed to be. Now, if you 
assume you have peers that stay on-line almost all the time (to maximize 
anonymity (and availability)), then you presumably get stable connections and 
the problem goes away.  Sure, there will be peers that are only on-line for 5 
minutes, but those won't have much of a chance (and in fact should not) to 
earn trust whichever way you put it, so no issue there.

As for having peers change their 'neighborhood' over time even if they (and 
the other good guys) stay on-line for a long time, that may become an issue 
if you have a huge network and relatively few connections for each peer (say 
100.000 peers and 20 connections, so even if you've established a good record 
with 500 peers you only have a 1:10 chance to be connected to one of those 
should you ever drop out and find yourself back at a totally different 
location the next time).

But this should not happen with GNUnet: even if you drop out for a while, 
you're likely to reconnect to a similar set of peers, just because of your 
local data/hosts cache.  Also I somehow doubt that we will have 100.000 
(good) peers on-line at the same time anytime soon (especially since we 
should only count peers that stay on-line for long periods here).  If you 
have a network of say 10.000 peers and each peer has 50 connections (which is 
more what I would expect a GNUnet network of that size would look like), 
you're also likely to earn the trust of more peers at the same time (because 
you have more connections).  So by the time you do some significant shifts in 
your location (which, as I said should only happen very slowly anyway), 
you're likely to have had the chance to establish some trust with a 
significant fraction of the network which means it doesn't matter.

To summarize, their criticism is valid if you make the right assumptions about 
what your p2p network looks like, but I don't think it applies at this point 
to GNUnet AFS.

C