Overview#
Traditionally, in the BitTorrent network, a 20-byte Peer ID field is used to identify clients and usually contains information such as client implementation and version number. This field is sent in tracker requests and peer handshakes to inform other nodes and the tracker about the client and its version number.
In a peer-to-peer network, the leading character of the peer ID for the mainline client is set to M, followed by ASCII digits to represent the version number, with major, minor, and tiny versions separated by hyphens. For example, the peer IDs for version numbers 4.3.6 and 4.20.8 could be M4-3-6- and M4-20-8-, respectively. The remaining bytes of the peer ID are random. This list originally came from the BitTorrent Specification.
The peer ID is a unique identifier used to identify a specific BitTorrent client implementation and version. In this case, the peer ID starts with a hyphen (-), followed by two characters to identify the client implementation, followed by four ASCII digits to represent the version number, and then another hyphen (-). Like the mainline, the remaining bytes are random. For example, "-AZ2060-" is an example of such a peer ID.
Known clients that use this encoding style include:
'AG' - Ares
'A~' - Ares
'AR' - Arctic
'AV' - Avicora
'AX' - BitPump
'AZ' - Azureus
'BB' - BitBuddy
'BC' - BitComet
'BF' - Bitflu
'BG' - BTG (uses Rasterbar libtorrent)
'BR' - BitRocket
'BS' - BTSlave
'BX' - ~Bittorrent X
'CD' - Enhanced CTorrent
'CT' - CTorrent
'DE' - DelugeTorrent
'DP' - Propagate Data Client
'EB' - EBit
'ES' - electric sheep
'FT' - FoxTorrent
'FW' - FrostWire
'FX' - Freebox BitTorrent
'GS' - GSTorrent
'HL' - Halite
'HN' - Hydranode
'KG' - KGet
'KT' - KTorrent
'LH' - LH-ABC
'LP' - Lphant
'LT' - libtorrent
'lt' - libTorrent
'LW' - LimeWire
'MO' - MonoTorrent
'MP' - MooPolice
'MR' - Miro
'MT' - MoonlightTorrent
'NX' - Net Transport
'PD' - Pando
'qB' - qBittorrent
'QD' - QQDownload
'QT' - Qt 4 Torrent example
'RT' - Retriever
'S~' - Shareaza alpha/beta
'SB' - ~Swiftbit
'SS' - SwarmScope
'ST' - SymTorrent
'st' - sharktorrent
'SZ' - Shareaza
'TN' - TorrentDotNET
'TR' - Transmission
'TS' - Torrentstorm
'TT' - TuoTu
'UL' - uLeecher!
'UT' - µTorrent
'UW' - µTorrent Web
'VG' - Vagaa
'WD' - WebTorrent Desktop
'WT' - BitLet
'WW' - WebTorrent
'WY' - FireTorrent
'XL' - Xunlei
'XT' - XanTorrent
'XX' - Xtorrent
'ZT' - ZipTorrent
When using BitTornado and its experimental BitTorrent implementation, a node ID starting with a character was introduced. In BitTornado, this character is "T", followed by a version number of up to five ASCII characters, filled with hyphens if less than five characters, and finally three hyphens (---).
The ASCII characters representing versions in the version number are limited to the following characters:
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz.-
For example, 'S58B---'... represents 5.8.11
Other clients known to use this encoding style include:
'A' - ABC
'O' - Osprey Permaseed
'Q' - BTQueue
'R' - Tribler
'S' - Shadow's client
'T' - BitTornado
'U' - UPnP NAT Bit Torrent
BitComet and BitLord generate node IDs using their own methods. The node ID is a unique ID used to identify a BitTorrent client. In BitComet, the node ID consists of four ASCII characters "exbc", followed by two bytes "x" and "y", and random characters. The version number is the "x" before the decimal point, and the digits after the decimal point are the "y". BitLord uses the same scheme but adds "LORD" after the version byte. However, an unofficial patch for BitComet once used "FUTB" instead of "exbc". Starting from BitComet version 0.59, the encoding of the node ID was changed to the Azureus style.
The XBT Client has a specific format where the peer ID consists of three uppercase characters "XBT" followed by a version number represented by three ASCII digits. If the client is a debug build, the seventh byte is a lowercase "d"; otherwise, it is a hyphen "-". This is followed by a hyphen "-", and then random digits, uppercase letters, and lowercase letters. For example, a peer ID starting with XBT054d- represents version 0.5.4 of a debug build.
The peer ID scheme used by Opera 8 preview and Opera 9.x releases is as follows: the first two characters are "OP", followed by four digits equal to the build version. All subsequent characters are random lowercase hexadecimal digits. Therefore, a typical peer ID might look like a string such as "OP1234abcdefg", where "1234" represents the build version and "abcdefg" represents random lowercase hexadecimal digits. In simple terms, the peer ID is a naming convention used by the Opera browser to identify itself, including the build version and randomly generated hexadecimal digits.
MLdonkey uses a peer ID scheme where it starts with "-ML", followed by a version number with a decimal point, a hyphen "-", and some random characters. For example, in "-ML2.7.2-kgjjfkd", "2.7.2" is the version number, and "kgjjfkd" is random characters.
Bits on Wheels uses a peer ID scheme where it starts with "-BOW", followed by three characters "xxx" representing version-related information, a hyphen "-", and a string of random uppercase letters "y". For the Bits on Wheels client with version number 1.0.6, the xxx value is A0C.
Queen Bee uses a peer ID scheme where it starts with "Q1-", followed by two digits representing the version number, one or two hyphens "-", and some random characters. For the Queen Bee client, there may be two version numbers: Q1-0-0- and Q1-10-0-, followed by randomly generated bytes.
BitTyrant uses a peer ID scheme in its 1.1 version. In fact, BitTyrant is a branch of Azureus, and its peer ID naming is basically the same as Azureus with some additional random characters. Specifically, in its 1.1 version, BitTyrant uses "AZ2500BT" as a prefix, followed by randomly generated bytes. Unlike other naming schemes, BitTyrant's naming does not include hyphens.
In version 1.90 of TorrenTopia, when communicating online with other clients, it identifies itself as "Mainline 3.4.6" and uses a node ID starting with "346---".
BitSpirit uses several different patterns to generate node IDs. In one pattern, it reads the ID of the other party and reconnects based on the first 8 bytes of the other party's ID. Its real ID seems to use \0\3BS (C notation) as the first 4 bytes in version 3.x and \0\2BS in version 2.x. In all patterns, the ID may end with UDP0.
Rufus uses its version number as the decimal ASCII value of the first two bytes. The third and fourth bytes are RS. This is followed by the user's nickname and some random bytes.
G3 Torrent's user ID starts with -G3 and can have up to 9 characters for the user's nickname.
FlashGet uses the Azureus style without a trailing hyphen. Version 1.82.1002 still uses the version number 0180.
AllPeers uses a user ID generation scheme based on the SHA1 hash value of a user-related string. The first few characters of the hash value are then replaced with "AP" + the version string + "-".
Summary#
BitTorrent Peer ID Conventions is a specification for standardizing the generation and parsing of node IDs for BitTorrent clients. In the BitTorrent network, each client needs to generate its own node ID according to this convention and be able to parse node IDs from other clients. By following this convention, different clients can recognize each other, enabling them to effectively share files.
According to this convention, a standard BitTorrent node ID should include parts such as the software name, version number, random string, and optional extension information, with the following format:
Software name: A string represented by 2 bytes of ASCII characters indicating the BitTorrent client software name used.
Version number: A string represented by 4 bytes of ASCII characters indicating the version number of the client software.
Random string: A randomly generated string of 20 bytes used to make each node ID unique.
Extension information: An optional string of 8 bytes in length used to include additional metadata or identifiers.
Since BitTorrent Peer ID Conventions is a recognized standard, most BitTorrent clients follow this specification to generate and parse node IDs. This helps ensure interoperability and compatibility among clients in the BitTorrent network.
References#
http://www.bittorrent.org/beps/bep_0020.html
https://wiki.theory.org/BitTorrentSpecification