BitTorrent Enhancement Proposals

The BitTorrent Community Forum coordinates the development of the BitTorrent protocol suite and its reference implementation. It is the wish of Bram Cohen that the BitTorrent mainline python implementation remain open source and that the protocol development process be modelled after the Python Enhancement Proposal (PEP) process [#python]_.

#0

What is a BEP

#1

This BEP provides a boilerplate or sample template for creating your own reStructuredText BEPs. In conjunction with the content guidelines in BEP 1 [#BEP-1]_, this should make it easy for you to conform your own BEPs to the format outlined below. Note: if you are reading this BEP via the web, you should first grab the text (reStructuredText) source of this BEP in order to complete the steps belo

#2

BitTorrent is a protocol for distributing files. It identifies content by URL and is designed to integrate seamlessly with the web. Its advantage over plain HTTP is that when multiple downloads of the same file happen concurrently, the downloaders upload to each other, making it possible for the file source to support very large numbers of downloaders with only a modest increase in its load.

#3

This document describes the known bit allocations and message IDs for the BitTorrent protocol. To request a bit allocation contact editor@bittorrent.org. Contact the same address if you are aware of any omissions.

#4

BitTorrent uses a "distributed sloppy hash table" (DHT) for storing peer contact information for "trackerless" torrents. In effect, each peer becomes a tracker. The protocol is based on Kademila [#Kademlia]_ and is implemented over UDP.

#5

The Fast Extension packages several extensions: *Have None/Have All*, *Reject Requests*, *Suggestions* and *Allowed Fast.* These are enabled by setting the third least significant bit of the last reserved byte in the BitTorrent handshake:

#6

This extension extends the tracker response to better support IPv6 peers as well as defines a way for multi homed machines to announce multiple addresses at the same time. This proposal addresses the use case where peers are either on an IPv4 network running Teredo_ or peers are on an IPv6 network with an IPv4 tunnel interface.

#7

This extends the tracker protocol to support simple obfuscation of the peers it returns, using the infohash as a shared secret between the peer and the tracker. The obfuscation does not provide any security against eavesdroppers that know the infohash of the torrent. The goal is to prevent internet service providers and other network administrators from blocking or disrupting bittorrent traffic c

#8

The purpose of this extension is to allow clients to join a swarm and complete a download without the need of downloading a .torrent file first. This extension instead allows clients to download the metadata from peers. It makes it possible to support *magnet links*, a link on a web page only containing enough information to join the swarm (the info hash).

#9

The intention of this protocol is to provide a simple and thin transport for extensions to the bittorrent protocol. Supporting this protocol makes it easy to add new extensions without interfering with the standard bittorrent protocol or clients that don't support this extension or the one you want to add.

#10

Peer Exchange (PEX) provides an alternative peer discovery mechanism for swarms once peers have bootstrapped via other mechanisms such as DHT or Tracker announces.

#11

Metadata Extension

#12

Local Service Discovery (LSD) provides a SSDP-like (http over udp-multicast) mechanism to announce the presence in specific swarms to local neighbors.

#14

Introduction

#15

The super-seed feature in S-5.5 and on is a new seeding algorithm designed to help a torrent initiator with limited bandwidth "pump up" a large torrent, reducing the amount of data it needs to upload in order to spawn new seeds in the torrent.

#16

Metadata Extension

#17

Rationale

#18

Using HTTP or FTP servers as seeds for BitTorrent downloads.

#19

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.

#20

The purpose of this extension is to allow further optimizations of bittorrent swarms when peers are *partial seeds*. A partial seed is a peer that is incomplete without downloading anything more. This happens for multi file torrents where users only download some of the files.

#21

Motivation

#22

To reduce the size of tracker responses and to reduce memory and computational requirements in trackers, trackers may return peers as a packed string rather than as a bencoded list. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in IETF RFC 2119 [#RFC-2119]_.

#23

So that peers may easily determine their IP address. A BitTorrent tracker may return the requesting peer's public IP address.

#24

Motivation

#25

Abstract

#26

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in IETF RFC 2119 [#RFC-2119]_.

#27

Tracker exchange extension

#28

uTorrent Transport Protocol

#29

BitTorrent requires a torrent file containing a cryptographic digest of every piece of the content to allow the verification of pieces during the download. Large torrent files put a strain on the Web servers distributing them, and cannot be directly included in RSS feeds or gossiped around. A related problem is the use of large piece sizes. To keep the size of a torrent file small (as to not over

#30

This BEP provides a simple backward compatible extension for the BitTorrent Tracker Protocol (`BEP 0003`_) to provide a client with more details on a failure, specifying if a failure is permanent or temporary and when the request can be repeated.

#31

This document describes a set of extensions to the BitTorrent DHT [#BEP-5]_ to allow operation over IPv6.

#32

Abstract

#33

Sometimes when users create torrents they mistakingly add website URLs as trackers. This results in those websites getting flooded with unwanted HTTP traffic. To prevent this flooding, trackers and websites can declare via DNS TXT record which ports (if any) on which they are running trackers. If a torrent contains a URL that according to this record does not have a tracker running on it, the cl

#34

When users open torrents, they normally receive a warning to alert them of the fact that the contents may be dangerous. If we can be confident that the torrent came from a trusted source, we can forego this unnecessary hassle and users can feel safer about downloading these files. To identify the source of a torrent, RSA signatures can be embedded into the .torrent file. These signatures can veri

#35

It has become common practice to publish RSS feeds linking to content by using torrent files. This BEP attempts to document and standardize how to format such RSS feeds.

#36

This BEP aims to provide recommendations for BitTorrent clients using proxies for the purpose of obfuscating the origin of its traffic. It primarily focuses on ways to inadvertantly leak information that could aid an adversary in discovering the origin.

#37

Often content providers distribute torrents that share some of the same files. This is most frequently done with episodic content or content that recieves periodic updates. Currently, when downloading a torrent, users must download all files within that torrent regardless of whether or not they have already downloaded them using a different torrent. This extension adds the ability for content prov

#38

With episodic content or content that recieves periodic updates, it's often useful for users to be able to subscribe to subsequent episodes or revisions. This BEP aims to provide a convenient way for users to do so by allowing content providers to embed a feed URL into a torrent file.

#39

The aim of this bep is to solve two problems with BitTorrent: 1. The barrier of entry to a swarm may be high when most peers (or at least most early peers with most of the data) are all fully connected at all times, never having a connection slot for new incoming connections. Peers are likely to attempt a new outgoing connection immediately when a peer is dropped, to reach the connection limit. T

#40

Since its initial inception, the UDP Tracker Protocol has seen widespread adoption by the BitTorrent ecosystem. It is by far the dominant tracker protocol in use, dwarfing the earlier HTTP-based protocol. However, the current version of the UDP protocol used to today does not include any method of adding extensions or additional features. Worse, previous versions of the protocol have described

#41

DHT Security Extension

#42

This extension introduces the concept of a 'read-only' DHT node for devices which are behind a restrictive NAT where hole punching has failed and the node is essentially uncontactable or for devices where additional network traffic can affect device users monetarily, when devices have a fixed data plan, and in usability, where traffic adversely affects battery life.

#43

This extension enables storing and retrieving of arbitrary data in the BitTorrent DHT [#BEP-5]_. It supports both storing immutable items, where the key is the SHA-1 hash of the data itself, and mutable items, where the key is the public key of the key pair used to sign the data.

#44

Multiple-address operation for the BitTorrent DHT

#45

This extension enables torrents to update based on data stored in the BitTorrent DHT [#BEP-44]_, rather than an HTTP server. The publisher has control over when the torrent is updated, and which content it contains, via mutable DHT items. It is similar to BEP 39 [#BEP-39]_, with the difference being that it uses the DHT to notify and be notified about updates of a torrent, hence should provide mor

#46

Padding files and extended file attributes

#47

The original BitTorrent Protocol Specification [#BEP_003]_ defines one exchange between a client and a tracker referred to as an announce. In order to build responsive user interfaces, clients desired an additional way to query metadata about swarms in bulk. The exchange that fetches this metadata for the clients is referred to as a scrape. It should be noted that scrape exchanges have no effect o

#48

This document specifies conventions for content feeds represented as torrents within torrents, i.e. metadata files which in turn list metadata files describing the actual content. The goal is to provide functionality comparable to RSS Feeds [#BEP-36]_ but in a distributed fashion by using the bittorrent protocol itself.

#49

This BEP defines a modification of the DHT protocol [#BEP-5]_ to provide a topic based publish/subscribe service rather than a key/value store. Each topic is associated with a mutable item [#BEP-44]_. Messages are published as new values for the mutable item. A separate overlay network is maintained for each topic.

#50