InfoHash a fondo: BitTorrent v1, v2, Magnet, BTIH y BTMH

BT9G Labs / DHT Deep Dive #04. Desde el info dictionary hasta SHA-1, SHA-256 y los torrents híbridos, con implicaciones para un índice moderno.

Resumen rápido

• Tema: InfoHash a fondo: BitTorrent v1, v2, Magnet, BTIH y BTMH
• Palabras clave: InfoHash, BitTorrent v1, BitTorrent v2, BTIH, BTMH
• Audiencia: ingenieros backend, investigadores de protocolos, ingenieros de búsqueda e implementadores de BitTorrent
• Objetivo: Explicar el mecanismo con suficiente precisión como para apoyar decisiones reales de arquitectura de crawling, indexación y búsqueda.

Vista del sistema

El límite de identidad es el info dictionary

En BitTorrent v1 el InfoHash es SHA-1 de los bytes bencoded originales del info dictionary, no de todo el archivo .torrent. Campos externos como comentarios o la lista de Tracker pueden cambiar sin modificar la identidad.

Un indexador debe evitar reserializar el info de forma descuidada: cambiar los bytes originales puede producir un hash distinto incluso si la estructura parece equivalente.

v1/BTIH y v2/BTMH

v1 utiliza un SHA-1 de 20 bytes y suele expresarse en Magnet mediante urn:btih. v2, definido en BEP 52, introduce SHA-256, Merkle trees y urn:btmh basado en multihash. También existen hybrid torrents compatibles con ambas generaciones.

Por ello no conviene asumir que todo InfoHash es simplemente una cadena hexadecimal de 40 caracteres.

Consecuencias para la indexación

La identidad del contenido sirve para deduplication, validación de Metadata, rutas de detalle y fusión de señales. Una buena base de datos separa versión de protocolo, algoritmo, digest binario y representación textual normalizada.

DHT activity, Tracker y Peer endpoints deben asociarse como observaciones de esa identidad, no modificarla.

Esquema de implementación

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()

Notas de ingeniería de BT9G Labs

En un indexador como BT9G importa más separar correctamente la identidad del contenido, las observaciones de red de corta duración, el estado de adquisición y los documentos de búsqueda que maximizar el número bruto de eventos. Cada campo derivado de DHT o de un Peer debería conservar su fuente y marca temporal, y las métricas deberían dividirse por etapas: discovery, conexión, handshake, soporte de extensiones, obtención de Metadata, validación, almacenamiento e indexación.

Errores comunes

• Calcular v1 sobre todo el .torrent.
• Tratar mayúsculas/minúsculas hex como contenidos distintos.
• Suponer que todo InfoHash es SHA-1 de 20 bytes.
• No preparar el esquema para v2 e híbridos.

Artículos relacionados de BT9G Labs

• Kademlia explicado: distancia XOR, routing y por qué BitTorrent DHT escala
• Cómo BitTorrent DHT encuentra Peer: de bootstrap a get_peers y announce_peer
• Mensajes DHT de BEP 5: ping, find_node, get_peers y announce_peer
• Dentro de una DHT Routing Table: k-Bucket, Node Churn y selección de contactos

Referencias

• BEP 3 - The BitTorrent Protocol Specification
• BEP 52 - The BitTorrent Protocol Specification v2
• BEP 9 - Extension for Peers to Send Metadata Files

Siguiente artículo: Mensajes DHT de BEP 5: ping, find_node, get_peers y announce_peer →

Este artículo describe el comportamiento de protocolos públicos de BitTorrent con fines de ingeniería e investigación; no implica que todo Swarm observado esté disponible, sea válido o esté autorizado para su redistribución.