RE: Query Hit bitprint

After reverification, I have seen that bitprints use TigerTree root, not
just Tiger; this makes it more useful for the intended purpose with secure
swarmed downloads.
My memory failed here, sorry.

So a good question, is now: why aren't bitprints generated, given its
advantage (its presence instead of just SHA1 means that TigerTree data will
be available, it may be computed in parallel with SHA1 when parsing the
files library to share, with minimal cost: with the same shared file data
reading, you compute the Tiger tree data, while computing the SHA1 file
digest and you end up with the TigerTree root, producing the bitprint in one
pass.

So sending results should favour bitprints instead of just SHA1, allowing
downloaders to immediately locate those securely swarmable locations that
can be immediately used, and allowing to download the TigerTree data in
parallel from one source, while still using the other responding sources: no
need to perform another query to see if TigerTree is available from those
parallel sources. Once you have the TigerTree data, all sources can be
checked against each other, but they will still have to match the same
TigerTree root which is already displayed in the bitprint.

With thatr information, swarmed downloads will initiate faster, and
corrupted fragments could be isolated on the fly during downloads from any
source.

For now LieWire onlky uses the TigerTree data when the download completes,
to detect corrupted fragments, but this could be anticipated, saving
bandwidth from both the swarming downloader and the sources.

Also another improvement for Gnutella apps would be to mark at each start
those files whose hash and tigertree has not been computed since long, so
that they can be queued for verification (by slowly recomputing their
hashes, if those shared files have been corrupted, something that is not
always visible from the filesystem's file info if it is cached in the cache
of precomputed hashes.)

We know that we can force recomputing the hashes, but it may be quite
lengthy to rehash a complete library. Fast hashing of a new shared directory
is still good, but slow background verification and updates of those hashes

We could also possibly signal such changes to users, if the change was
unexpected, could be a good option, allowing users to run a
antivirus/antirootkit check on those files when in doubt: this could help
users keeping their shared library clean of malwares, as we all know that so
many PCs are infected and malwares are attempting to locate P2P programs to
locate shared files and infect them as a way to propagate themselves.

The file could be placed in a suspect section of the shared library,
unshared by default (or shown with a yellow warning sign for suspect
change), until the users scans this folder and shares it again explicitly
after verification, or looks on Gnutella for the undamaged file: many users
check the files they have just downloaded from remote sources, but few will
check regularly their existing files that may have been corrupted by
malwares.

> -----Message d'origine-----
> De : [email protected] [mailto:[email protected]] De la part
> de Arne Babenhauserheide
> Envoyé : mercredi 12 septembre 2007 14:21
> À : [email protected]
> Objet : Re: [the_gdf] Query Hit bitprint
> 
> Thanks for the correction!
> 
> Best wishes,
> Arne
> 
> Am Mittwoch, 12 de September de 2007 14:08:18 schrieb Philippe Verdy:
> > No "MD5" sum, this is a "Tiger" digest instead (not to be confused with
> the
> > "Tiger tree root" which is another related but distinct value, computed
> > differently using sets of Tiger hashes computed on separated small
> blocks
> > and then organized in Merkle trees where branching nodes are given a
> > separate Tiger hash computed from a small block consisting of the Tiger
> > hashes of each sub-branch and a fixed prefix for each branch)...
> --
> Unpolitisch sein
> Heißt politisch sein
> Ohne es zu merken.
> - Arne Babenhauserheide ( http://draketo.de )
> -- Weblog: http://blog.draketo.de
> 
> -- Mein öffentlicher Schlüssel (PGP/GnuPG):
> http://draketo.de/inhalt/ich/pubkey.txt
> 
> 
> [Non-text portions of this message have been removed]
> 
> 
> 
> 
> Yahoo! Groups Links
> 
> 
> 
>