How BitTorrent Verifies Block and Piece Checksums

BitTorrent clients ensure downloaded data is free from corruption and malicious tampering by using cryptographic hash functions specified in the torrent’s metadata. Files are split into small chunks, and the client compares the computed hash of each fully assembled chunk against a pre-verified list of checksums. This article explains the exact step-by-step process of how torrent clients request sub-piece blocks, assemble them, and validate them against expected piece hashes.

Pieces vs. Blocks

To understand how validation works, it is essential to distinguish between a “piece” and a “block”:

• Piece: The primary unit of data defined in the .torrent metadata file, typically ranging from 256 KB to 16 MB in size. The metadata contains a cryptographic hash for every piece.
• Block (or Sub-piece): The actual transmission unit sent across the network, typically 16 KB in size. Because pieces are too large to transfer efficiently in a single network packet, clients request pieces in multiple smaller blocks.

The Metadata Blueprint

When a torrent is created, the creator’s software splits the target file (or files) into uniform pieces, generates a cryptographic hash for each piece, and stores these hashes in the .torrent file or magnet link metadata.

In standard BitTorrent (v1), the metadata contains a continuous string of 20-byte SHA-1 hashes—one for each piece. In BitTorrent v2, 32-byte SHA-256 hashes are arranged in a Merkle tree structure, allowing for even more granular data validation.

Step-by-Step Verification Process

1. Requesting Blocks: The client requests individual 16 KB blocks from multiple peers simultaneously to assemble a specific piece.
2. Buffering in Memory: Because the standard .torrent file only contains checksums for full pieces, individual 16 KB blocks cannot be verified in isolation upon arrival in BitTorrent v1. The client stores the incoming blocks in a temporary memory buffer or a cache.
3. Piece Assembly: Once every block belonging to a specific piece has been received, the client concatenates the blocks in their correct sequential order to reconstruct the complete piece.
4. Hashing the Piece: The client runs the cryptographic hash function (SHA-1 in v1, SHA-256 in v2) over the reconstructed piece data to produce a new hash digest.
5. Checksum Comparison: The client compares this newly calculated hash with the corresponding piece hash originally extracted from the torrent metadata.

Handling the Verification Result

• Successful Match: If the computed hash matches the metadata checksum, the piece is verified as authentic and uncorrupted. The client writes the piece to the permanent storage disk and broadcasts a HAVE message to connected peers, indicating that it is now ready to upload that piece to others.
• Hash Fail (Mismatch): If the hashes do not match, the entire piece is deemed corrupted or tampered with and is discarded from memory. The client then re-requests all blocks for that piece. Most clients track which peers supplied the bad blocks; if a peer repeatedly sends invalid data, the client will throttle, penalize, or permanently ban that peer to protect the integrity of the swarm.

Block-Level Verification in BitTorrent v2

While BitTorrent v1 requires assembling the entire piece before running a hash check, BitTorrent v2 utilizes Merkle trees (hash trees). In v2, each 16 KB block forms a leaf node in the Merkle tree. This allows clients to verify individual 16 KB blocks as soon as they arrive over the network using intermediate hashes, eliminating the need to discard an entire piece if only a single block is corrupted.