Home > Specs > BitTorrent
Protocol Version 3.1
Written by Kevin Hearn (kh@tixati.com)
Last update October 7, 2025

The goal of this update is to fully retire SHA-1, and to provide privacy from DHT scraper bots.

There are minor modifications to the torrent info map, and an additional key in the peer extended handshake.  The format of magnet links has also been changed slightly to add a hash algorithm specifier.


The pieces key has been removed from the info.  It had contained the SHA-1 piece hashes.  There is also no need for the info_pow key from the v3.0 protocol.

The following two keys are added to the v1 info:

piece_hashes

The value of this key is a map.  The map's keys are hash algorithm specification strings.  Each corresponding map value is a string that is the hash of each piece, concatenated, much like the old pieces hash field.

The algorithm specifiers currently in use are SHA2-256 and SHA3-256.  When checking specifiers, do so in a case-insensitive manner.  Both of these are 32 bytes (256 bits) per piece.

index_method

This specifies the hash algorithm that is used to calculate the info hash, which serves the same purposes as before (trackers, DHT, peer connection, etc).  To calculate the info hash, the BEncoded torrent info map is double hashed using the specified algorithm, and then truncated to 20 bytes.

This key also specifies the algorithm that is used for magnet links, except that the hash is applied only once to the BEncoded torrent info map, and it is not truncated.


The format of magnet links is the same as old torrents, except that the btih is followed by a hyphen and then a magnet link algorithm specifier derived from the index_method key in the torrent info map.  Following that is a colon, and then the base-32 hash of the BEncoded torrent info map.  The hash is not doubled and not truncated like it is for the internal info hash used for trackers, peers and DHT.

The magnet link algorithm specifier is the same as the one in the info index_method key, converted to lower case, with no hyphens and no width specification.  If there are multiple widths of the same algorithm in common use, they can be differentiated by the width of the hash contained in the link.

Example: magnet:?xt=urn:btih-sha3:hkgkj2kv6g5kjmps66ec3tqbeekuojlrnlig3bifqmsuyxmw64ua&dn=somefilename.jpg&xl=1079349&fc=1


A new key, info_check, has been added to the extended handshake sent during connection setup.  If any subsequent extended handshakes are sent (eg. to update other parameters), this key should not be included.

If the torrent is v3.1, indicated by the index_method in the info or deduced from the magnet link, then the first regular message upon peer connection must be the extended handshake with an info_check key.  If not, the peer connection must be immediately dropped.  No messages except the initial extended handshake should be sent until the remote peer's initial extended handshake has been received.

The info_check key's corresponding value is a map.

The map contains the key r, which has a string value that is a random nonce chosen by the sender, which should be at least 16 and no more than 64 bytes.

The remainder of the keys in the map are algorithm specifiers, for example SHA3-256 or SHA2-256.  There must be at least one of these keys.

Each algorithm key's corresponding value is a string that is a final hash calculated (using the specified algorithm) in the following way:

Inputs:
strRNonce = random nonce in r key
strSecret = the shared secret from this encrypted peer connection
strTorHash = hash of BEncoded torrent info map
Output:
Hash( Hash(strRNonce) + Hash(strSecret) + strTorHash )

If any of the known algorithm keys have a hash mismatch, drop the connection immediately.  If there are no known algorithm keys, drop the connection immediately.

Torrents that are v3.1 must not initiate or accept connections that are not using peer connection encryption.