Re: [Grapevine-devel] Re: Grapevine commentary

[Stephen B. <st...@bl...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 31 Oct 2003 17:47, Anthony Jones wrote:
> 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 seem=
ed
> > 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 s=
ee
> 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=3D"43b129daskjn189y#!2hb"/>
>   <data location=3D"kj321897@123jhgsdads"/>
>   <data location=3D"dasbn21,mnasi;31h2313"/>
>   <data location=3D"sanmbdkhb3kaksjhda/;j3"/>
>   <data location=3D":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 missi=
ng
> 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 downloadin=
g)
> all the data and verify for itself whether it is broken or not. If the fi=
le
> 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 wheth=
er
> 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 eith=
er
> be signed as broken or as working.
>
> Anthony

Thanks for all that.  How can the client check the signature?  What prevent=
s=20
the node with the root file from lying, since this information can't be=20
protected by a CHK?

Another idea I had was this:  Let's say the file contains 100 blocks.  You =
do=20
a random sample to see what proportion of those blocks can be fetched=20
(without downloading - it would be good find a way to cryptographically=20
prevent cancer nodes lying).  A statistical analysis will give you a=20
reasonably accurate indication of the probability of retrieving the entire=
=20
file, with only a small sample.

Your plan has an efficiency advantage, though the signing would consume CPU=
=20
time.  The idea I just mentioned has the advantage of simplicity - a very=20
important thing to me at the moment.

I would also have - as you said - the client replace any blocks they found =
to=20
be missing in order to make the file get bolstered each time someone=20
downloads it.  The CHKs mean that the system is protected against cancer=20
clients inserting wrong data.


Steve
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/ohmiODO5z8eA7sQRAoXNAJ9SI+cVGzJq4MSHseawUuu9MklFzACdG5/D
dOxbYF0eppGljNEEi9zHm/8=3D
=3DFNgU
=2D----END PGP SIGNATURE-----