qbittorrent / qBittorrent

qBittorrent BitTorrent client
https://www.qbittorrent.org
Other
28.08k stars 3.96k forks source link

Add column in content tab for torrent showing torrent file hashes #20980

Open memoryhash opened 4 months ago

memoryhash commented 4 months ago

Suggestion

I would like to see end result file hashes of each file I am downloading. I guess there would be 2 columns, one showing hash type and the other showing the hash, since this would need to account for SHA-1 and SHA-256 between Bittorrent v1 and v2.

Use case

Know what on earth I'm downloading ahead of time.

Extra info/examples/attachments

image

something like this highly detailed mspaint mockup

glassez commented 4 months ago

I would like to see end result file hashes of each file I am downloading. I guess there would be 2 columns, one showing hash type and the other showing the hash, since this would need to account for SHA-1 and SHA-256 between Bittorrent v1 and v2.

BitTorrent has nothing to do with file hashes. You can calculate the hash only after downloading the entire file. Am I wrong?

HanabishiRecca commented 4 months ago

BitTorrent has nothing to do with file hashes. You can calculate the hash only after downloading the entire file. Am I wrong?

BitTorrent v2 does store hashes of individual files. For v1, yeah, it's impossible to know the checksum of a file before you download it.

glassez commented 4 months ago

BitTorrent v2 does store hashes of individual files.

If you mean "pieces root" hashes then yes.

HanabishiRecca commented 4 months ago

If you mean "pieces root" hashes then yes.

Yes. Although, it's not clear for me from the spec, if it corresponds to actual file content, or just stores "hash of hashes". If it's the latter, the OP's idea is impossible completely.

glassez commented 4 months ago

Although, it's not clear for me from the spec, if it corresponds to actual file content, or just stores "hash of hashes".

In short, yes - a "hash of hashes".

If it's the latter, the OP's idea is impossible completely.

We can display such "pieces root" hashes. But what is the benefit of seeing them?

HanabishiRecca commented 4 months ago

In short, yes - a "hash of hashes". We can display such "pieces root" hashes. But what is the benefit of seeing them?

In that case, there is no practical benefit, I think. As you don't have any reference to compare it with. Also the resulting hash is different for torrents with different piece sizes, despite the actual content being identical. Which makes the whole thing pointless.

But all that has nothing to do with OP's idea of showing actual file checksums anyway. I.e. sorry @memoryhash, but your idea is impossible to implement with current BitTorrent v1 and v2 protocols.

glassez commented 4 months ago

Also the resulting hash is different for torrents with different piece sizes, despite the actual content being identical

These hashes are independent of the piece size.

mirh commented 3 weeks ago

This is apparently possible with v2 (and some torrents supposedly can come with a md5sum field).

These hashes are independent of the piece size.

Aren't hashes per-piece?

HanabishiRecca commented 3 weeks ago

This is apparently possible with v2

It is possible of course. But users usually want to know an actual hash of the file content, not the internal hash of the tree.

Aren't hashes per-piece?

Apparently not. From the spec:

pieces root For non-empty files this is the the root hash of a merkle tree with a branching factor of 2, constructed from 16KiB blocks of the file.

I.e. the hashes appear to be always calculated from fixed 16KiB blocks, regardless of the piece length.