Peer ID Conventions

BEP:	20
Title:	Peer ID Conventions
Version:	11031
Last-Modified:	2008-02-28 16:43:58 -0800 (Thu, 28 Feb 2008)
Author:	David Harrison <dave at bittorrent.com>
Status:	Active
Type:	Process
Created:	Feb-27-2008
Post-History:

http://www.bittorrent.org/beps/bep_0020.html

 

---

Contents

• References
• Copyright

The 20-byte peer id field sent in tracker requests and in the peer handshake has traditionally been used not only to identify peers but also to identify the client implementation and version.

The mainline client sets the first character in the peer-id to M followed by version number represented by ascii digits with major, minor and tiny versions separated by dashes. Examples include M4-3-6-- or M4-20-8- for versions 4.3.6 and 4.20.8. The remaining bytes in the peer id are random. The following list was originally derived from [1].

A number of clients begin the peer id with a dash followed by two characters to identify the client implementation, four ascii digits to denote version number, and a dash. As with mainline, the remaining bytes are random. An example is -AZ2060-.

Known clients that use this encoding style are

'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
'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
'VG' - Vagaa
'WT' - BitLet
'WY' - FireTorrent
'XL' - Xunlei
'XT' - XanTorrent
'XX' - Xtorrent
'ZT' - ZipTorrent

The following clients have been seen in the wild and need to be identified:

'BD' (example: -BD0300-)
'NP' (example: -NP0201-)
'wF' (example: -wF2200-)

Shad0w with his experimental BitTorrent implementation and BitTornado introduced peer ids that begin with a character which is``T`` in the case of BitTornado followed by up to five ascii characters for version number, padded with dashes if less than 5, followed by ---. The ascii characters denoting version are limited to the following characters:

0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz.-

For example: 'S58B-----'... for Shadow's 5.8.11

As with other peer id formats, the remanining bytes are random. There are significant deviations from this explained here [2].

Known clients that uses this encoding style are:

'A' - ABC
'O' - Osprey Permaseed
'Q' - BTQueue
'R' - Tribler
'S' - Shadow's client
'T' - BitTornado
'U' - UPnP NAT Bit Torrent

BitComet produces peer ids that consists of four ASCII characters exbc, followed by two bytes x and y, followed by random characters. The version number is x in decimal before the decimal point and y as two decimal digits after the decimal point. BitLord uses the same scheme, but adds LORD after the version bytes. An unofficial patch for BitComet once replaced exbc with FUTB. The encoding for BitComet Peer IDs changed to Azureus-style as of BitComet version 0.59.

XBT Client has its own style too. Its peer_id consists of the three uppercase characters XBT followed by three ASCII digits representing the version number. If the client is a debug build, the seventh byte is the lowercase character d, otherwise it is a -. Following that is a - then random digits, uppercase and lowercase letters. Example: XBT054d- at the beginning would indicate a debug build of version 0.5.4.

Opera 8 previews and Opera 9.x releases use the following peer_id scheme: The first two characters are OP and the next four digits equal the build number. All following characters are random lowercase hexdecimal digits.

MLdonkey use the following peer_id scheme: the first characters are -ML followed by a dotted version then a - followed by randomness. e.g. -ML2.7.2-kgjjfkd

Bits on Wheels uses the pattern -BOWxxx-yyyyyyyyyyyy, where y is random (uppercase letters) and x depends on the version. Version 1.0.6 has xxx = A0C.

Queen Bee uses Bram``s new style: Q1-0-0-- or Q1-10-0- followed by random bytes.

BitTyrant is an Azureus fork and simply uses AZ2500BT + random bytes as peer ID in its 1.1 version. Note the missing dashes.

TorrenTopia version 1.90 pretends to be or is derived from Mainline 3.4.6. Its peer ID starts with 346------.

BitSpirit has several modes for its peer ID. In one mode it reads the ID of its peer and reconnects using the first eight bytes as a basis for its own ID. Its real ID appears to use \\0\\3BS (C notation) as the first four bytes for version 3.x and \\0\\2BS for version 2.x. In all modes the ID may end in UDP0.

Rufus uses its version as decimal ASCII values for the first two bytes. The third and fourth bytes are RS. What then follows is the nickname of the user and some random bytes.

G3 Torrent starts its peer ID with -G3 and appends up to 9 characters of the nickname of the user.

FlashGet uses Azureus style with FG but without the trailing -. Version 1.82.1002 still uses the version digits 0180.

AllPeers takes the sha1 hash of a user dependent string and replaces the first few characters with "AP" + version string + "-".

References

[1]	http://wiki.theory.org/BitTorrentSpecification

[2]	http://forums.degreez.net/viewtopic.php?t=7070

Copyright

This document has been placed in the public domain.