[bittorrent] Short secure file identifiers

Elliott Mitchell ehem at m5p.com
Tue Jul 5 20:09:55 EDT 2005


>From: Edward Walker <walker.edward at gmail.com>
> There are multiple ways to solve both problems, for example, the
> controversial Merkle hash trees. I propose a different solution based on

What is controversial are the precise details of /how/ they're
implemented, not the choice to use them.

> simple recursion. The solution is to distribute the .torrent via BitTorrent
> as well and use one (or more) digest of the .torrent as identifier, as follows.
> 

This is the exact same idea as Merkle trees.


> 3. The short, secure file identifier SSFID of file F is now formed by the
>    concatenation of the digests found in meta torrent M. 

Why, when you're trying to stay similar to pure BitTorrent, are you
introducing this ridiculous "SSFID" from nowhere? This doesn't gain you
anything, and adds complexity.

> The advantage of this solution is that it does not require any changes to
> the BitTorrent protocol. A disadvantage is that it increases load on the
> trackers somewhat.

You've introduced this "SSFID", a very significant protocol change. Given
the lack of anything to gain from this, why? Due to creating this, you
cannot fallback to the strategy of manually telling your normal BT client
to download the metatorrent and then the main torrent.

There is little incentive for peers to keep with the metatorrent. Given
this ordinary peers will download it then disappear from that group. Only
seeds are likely to stick with it, and so it is likely to die

> What I like particularly is that we can use this solution to reduce
> blocksize. Because the .torrent is now in BitTorrent we can make it larger,
> within limits. This means we can start using smaller blocksizes, allowing
> new peers to start bartering more quickly after joining. In addition, DoS
> attacks by malcious peers sending bad data will be detected more quickly.

And this is novel?

> Alternatively, one can first apply recursion again and upload the meta
> torrent M into BitTorrent. The SSFID will then be based on the digests in
> the meta meta torrent X. The number of digest in X will be lower than in M 
> as the meta torrent M is even smaller than .torrent T, resulting in the
> desired small SSFID. Basically this means that a client should recursively
> download files that are torrents until it gets a file with different
> contents.

And this is different from "Merkle" trees?


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         EHeM at gremlin.m5p.com PGP 8881EF59         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
    \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/





More information about the BitTorrent mailing list