[Question] How to parse the truncated v2 hash for the future in announcer?

[Cønstantine Kovalensky]

libtorrent version (or branch):
2.0.9
platform/architecture:
windows/64
compiler and compiler version:
1.82.0

We are currently developing BitTorrent v2 support in TorrentPier tracker engine.

Support is almost ready, we allowed only hybrids for now, made a small check in announcer with length assumptions to check the hash in corresponding database.

Then we faced that v2 hash is still being sent truncated to 20 bytes.

Could there be more chance of collisions while checking truncated info_hash_v2 in both v1 and v2 hash databases, or is it slim to none?

Will libtorrent send the full v2 hash in the next releases?

[Cønstantine Kovalensky]

There's an efficient check now, which will work with full length hash for future, and it will check truncated hash in both v1 and v2 columns (which is not that performant as we hoped), but there are still questions with collision possibilities, maybe @the8472 could assist on this matter too?

[the8472]

Could there be more chance of collisions while checking truncated info_hash_v2 in both v1 and v2 hash databases, or is it slim to none?

The collision probability still is vanishingly small. A required property of cryptographic hashes is that the bit probabilities are independent, so removing some bits does not increase correlation. So collision probability of two randomly chosen hashes is the same as before (2^-80), doubling the amount of hashes shaves off 1 bit, which still leaves you with astronomically small numbers.

[Cønstantine Kovalensky]

The collision probability still is vanishingly small. A required property of cryptographic hashes is that the bit probabilities are independent, so removing some bits does not increase correlation...

Thanks for clarification 💚