BT9G LABS / DHT em profundidade #04
InfoHash em detalhes: BitTorrent v1, v2, Magnet, BTIH e BTMH
Como os identificadores de conteúdo BitTorrent são calculados e como v1/v2 aparecem em Magnet links.
BT9G Labs / DHT Deep Dive #04. Do
infodictionary ao SHA-1, SHA-256 e torrents híbridos, com foco em modelagem correta para indexadores.
Resumo rápido
- Tema: InfoHash em detalhes: BitTorrent v1, v2, Magnet, BTIH e BTMH
- Palavras-chave: InfoHash, BitTorrent v1, BitTorrent v2, BTIH, BTMH
- Público: engenheiros backend, pesquisadores de protocolos, engenheiros de busca e implementadores de BitTorrent
- Objetivo: Explicar o mecanismo com precisão suficiente para orientar decisões reais de arquitetura de crawling, indexação e busca.
Visão do sistema
O limite de identidade é o info dictionary
No BitTorrent v1, o InfoHash é SHA-1 dos bytes bencoded originais do info dictionary, não do arquivo .torrent inteiro. Campos externos como comentários ou Tracker list podem mudar sem alterar a identidade.
Um indexador deve ter cuidado ao reserializar o info: mudar a representação de bytes pode produzir outro hash mesmo que a estrutura pareça equivalente.
v1/BTIH e v2/BTMH
v1 usa SHA-1 de 20 bytes e normalmente aparece em Magnet como urn:btih. v2, definido no BEP 52, usa SHA-256, Merkle trees e urn:btmh baseado em multihash. Há ainda hybrid torrents compatíveis com as duas gerações.
Por isso não é seguro assumir que todo InfoHash é apenas uma string hex de 40 caracteres.
Impacto na arquitetura do índice
A identidade do conteúdo orienta deduplication, Metadata validation, rotas de detalhe e fusão de sinais. É melhor armazenar explicitamente versão do protocolo, algoritmo, digest binário e representação textual normalizada.
DHT activity, Tracker e Peer endpoints devem ser observações ligadas à identidade, não parte da própria identidade.
Esboço de implementação
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 engenharia do BT9G Labs
Em um indexador como o BT9G, é mais importante separar corretamente a identidade do conteúdo, observações de rede de curta duração, estado de aquisição e documentos de busca do que maximizar o número bruto de eventos. Campos derivados de DHT ou de um Peer devem manter origem e timestamp, e as métricas devem ser divididas por etapas: discovery, conexão, handshake, suporte a extensões, obtenção de Metadata, validação, armazenamento e indexação.
Erros comuns
- Calcular v1 sobre o
.torrentinteiro. - Tratar caixa alta/baixa do hex como conteúdo diferente.
- Assumir apenas SHA-1 de 20 bytes.
- Não preparar o schema para v2 e hybrid torrent.
Artigos relacionados do BT9G Labs
- Kademlia explicado: distância XOR, routing e por que o BitTorrent DHT escala
- Como o BitTorrent DHT encontra Peer: do bootstrap a get_peers e announce_peer
- Mensagens DHT do BEP 5: ping, find_node, get_peers e announce_peer
- Por dentro de uma DHT Routing Table: k-Bucket, Node Churn e seleção de contatos
Referências
- BEP 3 - The BitTorrent Protocol Specification
- BEP 52 - The BitTorrent Protocol Specification v2
- BEP 9 - Extension for Peers to Send Metadata Files
Próximo artigo: Mensagens DHT do BEP 5: ping, find_node, get_peers e announce_peer →
Este artigo descreve o comportamento de protocolos públicos do BitTorrent para fins de engenharia e pesquisa; não implica que todo Swarm observado esteja disponível, seja válido ou autorizado para redistribuição.