Storing Arbitrary Data in BitTorrent DHT with BEP 44

BitTorrent Enhancement Proposal 44 (BEP 44) extends the standard Mainline Distributed Hash Table (DHT) to allow participants to store and retrieve arbitrary data items instead of merely tracking peer IP addresses for torrent info-hashes. By introducing new RPC messages, cryptographic signatures, and sequencing mechanisms, BEP 44 transforms the Kademlia-based DHT into a decentralized key-value store capable of handling both static and dynamically updatable data.

Extending the DHT Protocol

The standard BitTorrent DHT operates on the Kademlia routing algorithm, mapping 160-bit info-hashes to lists of peer contact addresses. BEP 44 extends the DHT’s Remote Procedure Call (KRPC) protocol by adding two core primitives: get and put.

• get: Queries DHT nodes closest to a specific target key to retrieve the stored value along with associated metadata.
• put: Stores a value on the closest nodes after obtaining a write token through a prior get query to protect against IP spoofing and write-amplification attacks.

The payload size in BEP 44 is typically constrained to 1000 bytes (Bencoded) to fit within standard UDP packet size limits and minimize network overhead.

Immutable Data Storage

Immutable items represent content-addressed, static data that cannot be changed once stored.

1. Key Generation: The storage key is the 20-byte SHA-1 hash of the Bencoded raw data payload (v).
2. Verification: Any node that stores or queries an immutable item verifies integrity by hashing the received value v and ensuring it matches the requested target key.
3. Immutability: Because the address is tied directly to the payload’s hash, the content cannot be altered without changing its DHT location.

Mutable Data Storage

Mutable items allow publishers to update data at the same DHT key over time. This enables dynamic use cases like mutable feeds, decentralized identity records, and updatable torrent metadata.

1. Identity and Keys: Mutable data is bound to an asymmetric cryptographic key pair, typically using Ed25519. The DHT target key is derived from the SHA-1 hash of the public key (k), optionally combined with an arbitrary salt string.
2. Cryptographic Signatures: The publisher signs the payload (v), a sequence number (seq), and the optional salt using their private key. The resulting signature (sig) is submitted alongside the data.
3. Sequence Numbers: To prevent replay attacks and determine the latest state, each update must include a monotonically increasing 64-bit integer (seq). Nodes accept a new put request only if the sequence number is strictly greater than the one currently stored.
4. Validation: Any DHT node receiving a put or get request validates that the signature matches the public key and that the signature covers the provided payload and sequence number.

Data Expiration and Maintenance

Because DHT nodes frequently join and leave the network (churn), stored items are ephemeral. Nodes do not permanently store values on disk. Instead, publishers and interested peers must periodically re-announce and refresh data—typically every two hours—by executing put operations on the nodes currently closest to the target key. This ensures the data persists across the distributed network without requiring centralized infrastructure.