Better way to handle hashfails

[NegativeIQ]

I think there may be a good way to deal with poisoned torrents: Suppose you had several hashfails for a single piece. It can be very annoying having to download the same piece over again and again.

However, instead of throwing away all the hashfailed data, you can keep it temporarily and after you've downloaded the piece for let's say, 5 times, compare all the pieces byte-by-byte. If for a single byte of the piece, you got the same byte in 3 attempts, and other bytes in the other 2 attempts, then the byte you got 3 times is probably the correct one. Do that for the entire piece, calculate the hash once more and there's a good chance you'll have the correct piece.

Any thoughts?

[DreadWingKnight]

D4 makes this not work.

[NegativeIQ]

Excuse me for the newbie question but what's D4?

[DreadWingKnight]

DLink DMZ Download Destroyer.

Basically you'll get 3 hashfails with 100% identical failures caused by the broken DMZ code in some routers (most notoriously DLinks)

[NegativeIQ]

All right, I agree that it won't work 100% of the times, however I believe that when the torrent is indeed poisoned this could help.

[Smoovious]

There already is a different hashfail handling method being worked on. Range-banning. Should have better success against poisoners, as well as being K.I.S.S.-friendlier than your suggestion.

Note, that no hashfail-detection method, is going to help against .torrents which were created on corrupt data to begin with.

-- Smoovious

[diddl14]

Just searching the forum for known problems/solutions on hashfails. Actually like the original request as it goes a step beyond hashfail detection and banning. If I understand correctly this method would actually try to recreate the correct data by combining a certain number of blocks that had a hash-fail.

Sounds like a pretty simple algorithm:

- temporary store all the blocks with a hash-fail

- in a separate threat, do a byte-by-byte compare of all failed blocks with same block# and different hash

- dynamically create a new block based on statistical outcome of comparison

- check the hash of the new dynamic created block

Sounds like a K.I.S.S method and should be completely independent of D4.

To go a small step further, byte-by-byte comparison and dynamic block-creation only makes sense if the hash of the blocks are different. If the same corrupted block is downloaded multiple times from different peers (=same wrong hash), its likely that the whole torrent is corrupted. In that event, it would be nice if the download could automatically stop/pause (for example after n download attempts of same block).

Thoughts?

[jewelisheaven]

His point is that DMZ is inherently broken on said class / model / brand of routers. You can also check out the 1.8 product line being tested out in this thread for some of the new hash checking code.

Regarding your second post, the torrent is byte-for-byte a coy of the source. A "bad" torrent need not be all 100% "invalid" data for what you are looking for. There are multiple ways poisoners and subterfuge is used to keep you from getting your content. uTorrent doesn't care what content you want, it handles the connection and peer transfer... it's up to the user to find what they are looking for.