BT9G LABS / DHT 詳解 #04
InfoHash徹底解説:BitTorrent v1・v2、Magnet、BTIH、BTMH
BitTorrent のコンテンツ ID がどう計算され、v1/v2 のハッシュが Magnet link でどう表現されるかを解説します。
BT9G Labs / DHT Deep Dive #04.
infodictionary を起点に、SHA-1 の v1 と SHA-256 の v2、hybrid torrent まで整理します。
クイックサマリー
- テーマ: InfoHash徹底解説:BitTorrent v1・v2、Magnet、BTIH、BTMH
- 主要キーワード: InfoHash, BitTorrent v1, BitTorrent v2, BTIH, BTMH
- 対象読者: バックエンドエンジニア、プロトコル研究者、検索エンジニア、BitTorrent 実装者
- 目的: DHT と BitTorrent の仕組みを、実際のクローラ・インデックス・検索基盤の設計判断に使える精度で説明すること。
システム構成
identity の境界は info dictionary
BitTorrent v1 の InfoHash は .torrent 全体のハッシュではなく、元の bencoded info dictionary の SHA-1 です。コメントや Tracker list など info 外のフィールドが変わっても、info のバイト列が同じなら InfoHash は変わりません。
解析後に再エンコードしてからハッシュを取り直すと、元のバイト表現を変えてしまう可能性があるため注意が必要です。
v1/BTIH と v2/BTMH
v1 は 20-byte SHA-1 を使い、Magnet では通常 urn:btih で表現されます。v2 は BEP 52 で SHA-256 と Merkle tree を導入し、Magnet 側では multihash ベースの urn:btmh が使われます。v1 と v2 を両方持つ hybrid torrent も存在します。
そのため「InfoHash は常に 40 文字の hex」という前提は将来性がありません。
インデックス設計への影響
Content identity は deduplication、Metadata validation、detail URL、複数ソース統合の基準です。protocol version、hash algorithm、raw digest、canonical text representation を明示的に分けると、v1/v2/hybrid を安全に扱えます。
DHT activity、Tracker、Peer endpoints は identity そのものではなく、identity に紐づく観測データとして保存するのが適切です。
実装スケッチ
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()
BT9G Labs エンジニアリングノート
BT9G のようなインデックス基盤では、イベント件数そのものより、コンテンツ ID、短命なネットワーク観測、取得状態、検索用ドキュメントを分離することが重要です。DHT や Peer から得た値には取得元と時刻を持たせ、discovery、接続、handshake、拡張対応、Metadata 取得、検証、保存、検索反映を段階別に計測すると、実際のボトルネックを特定しやすくなります。
よくある誤解
- v1 で
.torrent全体をハッシュする。 - hex の大文字小文字を別コンテンツ扱いする。
- InfoHash を常に 20-byte SHA-1 と決めつける。
- v2/hybrid を考えずスキーマを固定する。
関連する BT9G Labs 記事
- Kademliaを解説:XOR距離、ルーティング、BitTorrent DHTがスケールする理由
- BitTorrent DHTはどうPeerを見つける?Bootstrapからget_peers・announce_peerまで
- BEP 5 DHTメッセージ解説:ping、find_node、get_peers、announce_peer
- DHT Routing Tableの内部:k-Bucket、Node Churn、連絡先選択
参考資料
- BEP 3 - The BitTorrent Protocol Specification
- BEP 52 - The BitTorrent Protocol Specification v2
- BEP 9 - Extension for Peers to Send Metadata Files
次の記事: BEP 5 DHTメッセージ解説:ping、find_node、get_peers、announce_peer →
本記事は公開 BitTorrent プロトコルの挙動を技術・研究目的で解説するものであり、観測されたすべての Swarm が利用可能、正当、または再配布を許可されていることを意味しません。