BT9G LABS / DHT Deep Dive #04

InfoHash Deep Dive: BitTorrent v1, v2, Magnet Links, BTIH, and BTMH

Understand how BitTorrent content identifiers are calculated and how v1 and v2 hashes appear in magnet links.

BT9G LabsPublished 4 min read

BT9G Labs / DHT Deep Dive #04. Understand how BitTorrent content identifiers are calculated and how v1 and v2 hashes appear in magnet links.

InfoHash Deep Dive: BitTorrent v1, v2, Magnet Links, BTIH, and BTMH

Quick summary

  • Topic: InfoHash Deep Dive: BitTorrent v1, v2, Magnet Links, BTIH, and BTMH
  • Core keywords: infohash, BTIH, BTMH, magnet link, BitTorrent v2, SHA-1, SHA-256
  • Audience: backend engineers, protocol researchers, search engineers, and BitTorrent implementers
  • Goal: explain the mechanism accurately enough to support real crawler and indexing architecture decisions

System view

The info dictionary is the identity boundary

A torrent metainfo file is a bencoded dictionary. For BitTorrent v1, the canonical torrent identifier is derived from the exact bencoded bytes of the info dictionary. That detail matters: implementations cannot casually parse malformed bencoding and re-encode it in a different representation and expect the same hash.

The infohash identifies a content description, not a URL and not a storage server. Peers, trackers, and DHT lookups use that identifier to agree on which swarm they are discussing.

v1 and the BTIH namespace

BitTorrent v1 uses SHA-1 for the infohash. Magnet links commonly carry it in the xt=urn:btih: parameter, using hexadecimal or base32-style representations depending on the producer. The underlying identifier used in the protocol is the binary hash.

Because a magnet URI can contain the infohash without carrying the complete torrent metadata, a client can start by discovering peers and then obtain the metadata through the extension protocol.

v2 and SHA-256

BitTorrent v2 changes the hashing model and uses SHA-256 for the v2 infohash. BEP 52 also introduces Merkle-tree-based piece verification and other format changes. Some protocol contexts use a truncated form, so implementations must distinguish the full v2 identifier from the representation required by a specific wire operation.

Hybrid torrents can contain both v1-compatible and v2 structures. Indexing systems should therefore model identifiers explicitly rather than forcing every torrent into one 40-character hexadecimal field forever.

Indexing implications

For BT9G-scale ingestion, the infohash should be an immutable content key. Metadata, crawl observations, peer counts, tracker results, and search documents can all be updated around that key without changing its identity.

A future-proof schema stores the hash algorithm or torrent version alongside the binary identifier. It also separates presentation strings from the canonical bytes used for equality and deduplication.

Implementation sketch

import hashlib

def v1_infohash(raw_bencoded_info: bytes) -> bytes:
    return hashlib.sha1(raw_bencoded_info).digest()

def v2_infohash(raw_bencoded_info: bytes) -> bytes:
    return hashlib.sha256(raw_bencoded_info).digest()

Engineering notes for BT9G Labs

For an indexing system, protocol correctness and data semantics matter more than raw event volume. Keep durable content identity separate from volatile peer observations, retain timestamps on measurements, and make every network-derived field explicit about its source. This prevents the search layer from turning a short-lived observation into a permanent factual claim.

Where possible, record stage-level metrics rather than only total success or failure. That makes it possible to see whether the bottleneck is DHT lookup quality, peer reachability, extension support, metadata transfer, validation, storage, or search indexing.

Common mistakes

  • Hashing the entire .torrent file instead of the info dictionary.
  • Re-encoding invalid bencoded data before hashing.
  • Assuming every magnet identifier is v1 BTIH.
  • Storing only human-readable hash strings and losing algorithm context.

References

← Previous: How BitTorrent DHT Finds Peers: From Bootstrap to get_peers and announce_peer Next: BEP 5 DHT Messages Explained: ping, find_node, get_peers, and announce_peer →

This article explains public BitTorrent protocol behavior for engineering and research purposes. It does not imply that every observed swarm is available, valid, or authorized for redistribution.