Re: [Grapevine-devel] Re: Grapevine commentary

[Anthony J. <aj...@cl...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 31 October 2003 11:40, Stephen Blackheath wrote:
> > Joining nodes are not assigned a place... why not?
>
> Because I couldn't think of a satisfactory way of doing it.  The
> grapevine.pdf document describes an alternative approach, and SAHP seemed
> preferable.

In short they are assigned a random place, which they automatically generate 
for themselves. SAHP makes it computationally intensive to allocate yourself 
a non-random place.

> > Can you allow a shortcut for that?  Like, can the administrators of each
> > node decide they want to connect no matter what anyone else says?
>
> One possible short-cut (Anthony's idea) would be for someone to send an
> "invitation" to a friend which contains an already-calculated location, as
> well as a list of seed nodes.  That would allow a new person to join
> immediately on the recommendation of a friend.  The disadvantage is that it
> would also need to contain a private key (on account of the way SAHP
> works). Normally you don't let private keys travel around the network.

The SAHP need not be all that good. Even a time constant of 2 minutes for a 
top of the line machine (which is likely to be closer to 20 minutes for an 
old clunker) would offer a reasonable level of security. I don't really see 
it as a big issue. If you're serious about running Grapevine then you'll just 
start it up and leave it running.

> > Would it be possible to have file sponsors who keep the whole file
> > (like Bittorrent seeds)?  If someone wants to keep the file on the
> > network they have to commit to keeping a seed running.
>
> That is technically possible and would be a far easier way to solve the
> problem, but it would prevent anonymous publishing, which is one of the
> most important goals of this system.

My suggestion is this:

When you give someone a reference to a file you give them only a reference to 
the root of that file. The root would look something like this:

<file>
  <data location="43b129daskjn189y#!2hb"/>
  <data location="kj321897@123jhgsdads"/>
  <data location="dasbn21,mnasi;31h2313"/>
  <data location="sanmbdkhb3kaksjhda/;j3"/>
  <data location=":3:!312kj$kjh1hj23hk132"/>
</file>

This is an example of a root file which points to five data blocks. These are 
redundant blocks so only four out of the five are required to reconstruct the 
data. If a client wants to download this file then they would download four 
out of the five blocks. If one of the blocks is missing then it will download 
the fifth block and then automatically re-create and re-insert the missing 
block.

If the node can't be reconstructed then the client will notify the node which 
stores the root file. This node will then check (without downloading) all the 
data and verify for itself whether it is broken or not. If the file is 
correctly identified as being broken then that node will sign the root file 
as being broken. From then on it is easy for a client to check whether the 
file is broken without having to actually download it or find all the pieces.

If the file is large then it would be a hierarchy of root files but the basic 
principle still applies. Rather than each node checking the data of it's 
children it will check the root nodes of it's children. They'll either be 
signed as broken or as working.

Anthony
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/oelHd+IOCdhCut8RAgtuAJsEz1vXCqANV8duf0dY5pHg8c/4awCfV93j
J9/vWm9A387j4ZSoqKj69bQ=
=9RWS
-----END PGP SIGNATURE-----