Editing BitTorrent (section)

=== Creating and publishing ===
{{see also|Torrent file}}
{{Update|date=January 2022|reason=Some extensions described in this section as experimental have been standardized. This section is factually incorrect about some aspects of v1 and v2}}

The peer distributing a data file treats the file as a number of identically sized pieces, usually with byte sizes of a power of 2, and typically between 32&nbsp;KB and 16&nbsp;MB each. The peer creates a [[Hash function|hash]] for each piece, using the [[SHA-1]] hash function, and records it in the [[torrent file]]. Pieces with sizes greater than 512&nbsp;KB will reduce the size of a torrent file for a very large payload, but is claimed to reduce the efficiency of the protocol.<ref>{{cite web |url=http://wiki.theory.org/index.php/BitTorrentSpecification |title=BitTorrent Specification |publisher=Wiki.theory.org |access-date=9 July 2012 | archive-url = https://web.archive.org/web/20130626195027/https://wiki.theory.org/index.php/BitTorrentSpecification | archive-date = 26 June 2013| url-status=live}}{{dubious|reason=Wikis are not citable sources – find a better source-Lexein|date=April 2013}}</ref> When another peer later receives a particular piece, the hash of the piece is compared to the recorded hash to test that the piece is error-free.<ref name = "Protocol1.0" /> Peers that provide a complete file are called seeders, and the peer providing the initial copy is called the initial seeder. The exact information contained in the torrent file depends on the version of the BitTorrent protocol.

By convention, the name of a torrent file has the suffix <code>.torrent</code>. Torrent files use the [[Bencode]] file format, and contain an "announce" section, which specifies the [[Uniform Resource Locator|URL]] of the tracker, and an "info" section, containing (suggested) names for the files, their lengths, the piece length used, and a [[SHA-1]] [[hash code]] for each piece, all of which are used by clients to verify the integrity of the data they receive. Though SHA-1 has shown signs of cryptographic weakness, Bram Cohen did not initially consider the risk big enough for a backward incompatible change to, for example, [[SHA-3]]. As of BitTorrent v2 the hash function has been updated to SHA-256.<ref>{{cite web|title=» BitTorrent v2|url=https://blog.libtorrent.org/2020/09/bittorrent-v2/|access-date=2020-09-27|language=en-US|archive-date=27 September 2020|archive-url=https://web.archive.org/web/20200927063545/https://blog.libtorrent.org/2020/09/bittorrent-v2/|url-status=live}}</ref>

In the early days, torrent files were typically published to torrent index websites, and registered with at least one tracker. The tracker maintained lists of the clients currently connected to the swarm.<ref name="Protocol1.0"/> Alternatively, in a ''trackerless system'' (decentralized tracking) every peer acts as a tracker. Azureus was the first<ref name="DHT-turns-10">{{cite web|title=BitTorrent's DHT Turns 10 Years Old|last=Jones|first=Ben|url=https://torrentfreak.com/bittorrents-dht-turns-10-years-old-150607/|date=7 June 2015|access-date=5 July 2015|website=[[TorrentFreak]]|archive-url=https://web.archive.org/web/20150611011335/http://torrentfreak.com/bittorrents-dht-turns-10-years-old-150607/|archive-date=11 June 2015|url-status=live|df=dmy-all}}</ref> BitTorrent client to implement such a system through the [[distributed hash table]] (DHT) method. An alternative and incompatible DHT system, known as [[Mainline DHT]], was released in the Mainline BitTorrent client three weeks later (though it had been in development since 2002)<ref name="DHT-turns-10"/> and subsequently adopted by the [[μTorrent]], [[Transmission (BitTorrent client)|Transmission]], [[rTorrent]], [[KTorrent]], [[BitComet]], and [[Deluge (BitTorrent client)|Deluge]] clients.

After the DHT was adopted, a "private" flag&nbsp;– analogous to the [[broadcast flag]]&nbsp;– was unofficially introduced, telling clients to restrict the use of decentralized tracking regardless of the user's desires.<ref>{{cite web|url=https://wiki.theory.org/index.php/BitTorrentSpecification#Info_Dictionary|title=Unofficial BitTorrent Protocol Specification v1.0|url-status=live|archive-url=https://web.archive.org/web/20061214094732/http://wiki.theory.org/BitTorrentSpecification|archive-date=14 December 2006|access-date=4 October 2009}}{{dubious|reason=Wikis are not citable sources – find a better source-Lexein|date=April 2013}}</ref> The flag is intentionally placed in the info section of the torrent so that it cannot be disabled or removed without changing the identity of the torrent. The purpose of the flag is to prevent torrents from being shared with clients that do not have access to the tracker. The flag was requested for inclusion in the official specification in August 2008, but has not been accepted yet.<ref>{{cite web|url=https://www.bittorrent.org/beps/bep_0027.html|title=Private Torrents|author=Harrison, David|date=3 August 2008|publisher=Bittorrent.org|url-status=live|archive-url=https://web.archive.org/web/20130324181003/http://www.bittorrent.org/beps/bep_0027.html|archive-date=24 March 2013|access-date=4 October 2009}}</ref> Clients that have ignored the private flag were banned by many trackers, discouraging the practice.<ref>{{cite web| url=http://www.slyck.com/news.php?story=1021| title=BitComet Banned From Growing Number of Private Trackers| access-date=4 October 2009 | archive-url = https://web.archive.org/web/20140326093846/http://www.slyck.com/news.php?story=1021 | archive-date = 26 March 2014| url-status=live}}</ref>