Urgently Overdue Changes Needed to Make BitTorrent Clients (and Protocol Families) Function
in the Overall Best Interests of its Varied User Groups


These are BitTorrent modifications are primarily for client program user interfaces, but secondarily for BT Protocol interaction over the Internet.

The BitTorrent protocol should (in the long run) be communally overseen by the International Telecommunications Union (ITU), in the capacity of providing "a framework for documenting the protocol state machines" (Protocol Client to Client, Protocol Client to Tracker, Protocol Client to DHT,  Torrent File Syntax and minimal expected client state machine behaviours).

The ITU should in no way interfere with the evolution of distributed file transfer protocols, but assist where possible to make these networks as compatible and interoperable with IP and Non-IP networks as possible.

There is an older version of this document archived at :

[ 1: Version 2016 ]
[ 2: (PDF, TBA)  ]


There are deep security problems, in Protocol as much as Usability...

Overall, the long term trend in the evolution of the BitTorrent protocol is towards higher levels of security at all layers of the protocol's functionality.

The security problem is compounded by User Interfaces (UIs) that fail to self document themselves correctly.

BT Client UIs still do not provide users an adequate idea of what the program is doing "in real time" or "has done statically" in the recent past.

However, every aspect of BitTorrent's use is affected by ongoing security concerns and problems.

Notably : the era of randomly blindly trusting any and all BitTorrent clients is history
BT Client Verification and BT Protocol Encryption are part of a bigger picture of protocol and application change for security oriented reasons. BitTorrent protocol and systems are beginning to intersect with Onion Routing protocols and systems, out of practicality for their users. BitTorrent users in the Western sphere are in as much danger as Tor users are in other nations.

The need for real (but mainly functional) security. There has to be "security in transmission" from the OSI "Link Layer" into the "Application Layer" for a BitTorrent user to be safe from the extreme civil rights abuses that have taken place due to the pretext of copyright law being wrongfully applied to binary objects as opposed to physical objects.

Multiple levels of BT protocol encryption are mandatory as of 2015. However due to design mistakes only single layer encryption is available to clients not using a VPN, Secure Meshnet or IP Tunnel of some kind. Note that using the existing BT protocol single layer encryption has practically been mandatory since 2009, but its ability to cloak BT protocol transmissions is nearing its functional end. No other outbound transmission option is safe at the moment.

BitTorrent client applications continually fail to warn a person of insecure transmission or usability settings as well.

Many Internet users have Wifi modems (and 'free access' local networks) in their homes and flats.

Many Internet users run Tor as well, and Virtual Private Networking (in a mesh or web) is evolving into a functionality of many Internet applications.

To associate an IP address with a physical address and the behaviour of people at that physical address is legally nebulous. There is simply too much room for abuse and corruption in private sector and government in this area.

DHTs, Torrent Archives, and Torrent Website Multihosting

The era of depending on dedicated websites (even as Tor hidden services in the .onion domain, but mostly not) to provide .torrent file hosting (including Torrent Rating Services as to if a file is a fake or not), and Distributed Hash Trees (DHTs) so that BT clients can find the right hash of the right file [and the file itself] are partially on their way out like Torrent Client Trackers (and the BT Tracker <-- --> BT Client Protocols).

The "Centralization of BT Protocol Client Communications Systems" has to come to an end.

There is no reason why every BT Client can't possess its own local copy of a nearly current DHT, and the database of .torrent files that go with it.

An average DHT is about 2.2 Gigabytes in size, and by removing fake torrent hashes and not recently used hashes (40 hours?) it would be possible to get a local DHT to be a tame 1.5 Gigabytes in size.

An average database of validated .torrent files [that have been active in the past 168 hours & are not Fake] might be no more than 5 Gigabytes on any drive, but this is file system dependant ("bytes used for files" and "bytes used on a local hard or flash drive's file system" do not correspond well because of the way file system have to match a file's "used bytes" by a sector's "free bytes").

For file system efficiency, both DHT databases and torrent file databases (and files) can be held in file containers that use compression (like ZIP or BZ) or not (like ISO and IMG). Including (and accounting for) the issue of compartmentalized backup redundancy -- there is no reason why no more than 5 Gigabytes total can't be dedicated for each Torrent Client to use for the storage of a compete up to date DHT and the corresponding .torrent files that go with it. Both the DHT and Torrent File Database should be encrypted by default, by the client applications that render these services. Because hashsums are used universally in both places, segmentation can be done by hashsum value alone ... so that each partial database file should hopefully be no bigger than 100mb so as to reduce strain on the file systems.

There needs to be 6 new innovations to increase DHT privacy and Torrent File Database hosting security
  1. DHTs need to have their state frozen every 2 hours (but in future ~40 minutes), and that frozen state signed off by an authentication mechanism. This is to allow entire DHT directories to be updated on local networks in large file transfers, possibly using Secure FTP (or https, etc...) with Hashsum content enforcement. Signed snapshot information should be propagatable to the DHT client, so it can verify (sign) and propagate the current DHT. Torrent snapshots of DHTs should be tried as an option. 
  2. DHT Snapshots should expire after 168 hours by default (and must be completely deleted after 60 days). The "cleaning out" deletion rate should not exceed {10 expired inactive hashes per second} as over 40 days most DHTs only have a net rate of change of around  (+/-) 12% nominal. In order to do this each DHT hashsum will need to have a 64 bit Modified IRIG Timestamp or Unix Timestamp.
  3. DHT Protocol : The DHT needs to announce the IP locations of other DHTs (securely) to the local DHT client. Updating a local DHT from a local network is much more convenient and faster than doing it over the Internet (at speeds ~50kbs). Current DHT protocols don't keep track of other (verified or known) DHTs -- so if the primary hash trees BT clients depend on today are shut down there will be no place to go until people program in manually new DHTs to use. There should be about 100k DHTs for p2p on the Internet, to make the DHT hierarchy reliable.
  4. Local BT Client DHTs and Torrent File Databases need to be run "Out of Process" ... that is to say these should be separate applications exicuted separatly from the main BT client application. BT Clients should call upon [either as part of its own installation, or as shared application (Linux) or as as shared Service (Windows 10 or Minix3)] local DHTs and Torrent File Databases, so as to externalize the complexity and increase the robustness of the BT application. BT applications should only converse with these external applications at a rate of 32kbs or less as that is all that is needed to transfer any number of DHT clients or Torrent Files.
  5. DHT and Torrent File Database Traffic should be secured by 2 layers of encryption by default (as the update rate should never exceed 100kbs to reduce stress on local and global IP networks). The same principals of cloaking BT traffic should apply. The databases should be locally encrypted, at least to make DHT or Torrent File Database recovery inconvenient and bothersome.
  6. Local DHT databases and Torrent File Databases should be able to talk to each other for the purposes of self synchronization (outside the influence of any local BT client), so that about every 5 to 15 seconds of every minute each can do "Janitorial Work" ... mainly downloading new DHT entries and Torrent Files and alternately (and perhaps more importantly) deleting stale or no longer valid entries or files. Each one should do some kind of stateful backup between 5 and 12 minutes (with 5% random variation to avoid mutual conflict with respect to local file system usage).

Its a MESHNET, not a series of VPN pipes to the so called Plain Old Ordinary Internet!

All P2P systems including

What this means is that for P2P systems to exist peacefully, they must be as ordinary in their traffic's appearance as possible, yet be a separate secure layer that does not otherwise openly interact with the rest of the ordinary internet.


For Torrents that contain multiple files

1. File Prioritization must be made mandatory for torrents that contain more than one file. Perusing any other file treatment policy will lead to "dead torrents" being created that can not be usable by anyone.

Most BitTorrent clients support the capability of File Prioritization, so very little code will need to be changed. In some cases only the "Default" settings will have to be changed -- and the data type of prioritization level. It is recommendable that 16 bit unsigned ints be used to encode File Priority. There will be almost no impact on the memory footprint for this change.

File Prioritization must be made program's default setting, if the client application default setting is for no file prioritization.

The reason for File Prioritization being mandatory is that it allows the user to choose what parts of a multi-file Torrent deserve more urgency in downloading.

This ability to choose downloading priority helps keep multi-file Torrents more active and less subject to unavailability or incompleteness.

For files that have been successfully downloaded and verified, the file priority should be reset to "0".

There should be no file upload priority -- EXCEPT FOR CLIENTS THAT SUPPORT "Initial Seeding".

The "rarest piece has highest priority" protocol for content availability regime take care of this.

User Interface Impact

Granularity of File Prioritization
[ ] Base 100 (recommended)
[ ] Base "Number of Files" in Torrent (memory efficient)
[ ] Base "Number of Files" x 3 in Torrent (priority efficient)
[ ] Set completed files to Normal Priority [ ] 2 minutes or [ ] 5 minutes after completion.
[ ] Give smaller files higher priority
[ ] Each file must have a unique priority
[ ] Use 5% Timer Variation for Completed Files set to "Nominal" 

Italics : Not mandatory to display in user interface if forced to be True.

2. Downloading the "FIRST SECTOR" and "LAST SECTOR" of a Torrent file must be made mandatory at the file and Torrent level.
This issue was created by multimedia files that contain vital [or at least important information] at the end of the file (as almost all files [except for saved packet streams, like DVB television datastreams] contain vital information about the file at the beginning).
3. The meaning of "Endgame Mode" must be up to the user, not the default settings of the client.

The maths behind "Endgame Mode" has always been somewhat unrealistic for a decade. At a bare minimum Endgame Mode is out of touch with reality with respect to keeping torrents alive.

The reason is simple : Torrents have variable numbers of sectors -- very often above 1000 to 10000. THEREFORE waiting for the last 1 to 5 sectors to go into Endgame Mode is almost meaningless. One has to think in terms of "Percent Completion" not "Remaining Sectors".

As all BT clients universally track "Percent Complete" the programming impact (and increase in complexity) is not great. These changes could be made on most clients with only an increase in the binary payload of the client of 4kb, but for completely safe code 8kb to 12kb.

In normal operations :

It is not (nor has it ever been) the last 1 or 5 sectors that need high priority in downloading.

As a rule the last 3% to 5% of a Torrent needs Endgame priority.

This "Endgame Mode" MUST BE applied to the level of the Individual File by Default, not the Torrent as a whole. However, for some compact BT clients applying Endgame Mode for the torrent as a whole is OK ... the outcome being that it is suboptimal.

The database monitoring the torrent should not need an update to its structure to do this, as there really are only 3 states for a torrent transmission "Downloading" + "Endgame Mode" + "Seeing" ...

Endgame Mode must always be local to a file, not a Torrent. [Unless it is a single Torrent file.]

The cost for this change in traffic (and wastage) terms is not great, if the Endgame request state machine is made aware and tracks its goal.

This change in the Endgame 'state machine' should only produce 1% to 2% wastage on less popular Torrents. Having a permissible wastage of 1% [per session, per user] of a Torrent is tolerable, if it keeps the Torrent alive.

The User Interface changes would look like this

Endgame Mode
Should start at [ ] 95% [ ] 96% [ ] 97% or
[ ] When a file has [ ] 10 to 25 or [ ] 25 to 50 remaining sectors or
[ ] When a file has under 5% to 10% sectors remaining or
[ ] When a minimal number of available copies exist or are available

4. Downloading Algorithm Flexibility

The following does not change any BitTorrent downloading protocols in any way. The following is merely a change in the bias of the rarest pieces algorithm for the client downloading a torrent. This bias should never be applied to torrents with less than 100 sectors, as Rarest Piece Available functions perfectly for these small torrents, even for dialup or WiFi users.

Currently the BitTorrent downloading algorithm prefers the Rarest Piece Available. Although mathematically "Rarest Piece Available" has proven to be a good choice, when it comes to downloading mulitgegabyte torrents "Rarest Piece" is very poor at being a uniform space filler. Uniform Space Filling will up the overall systematic "signal to noise ratio" of a torrent, with respect to the availability of the rarer sectors.

Provisionally, the Cantor Set is recommendable as a an alternate. The Smith–Volterra–Cantor Set would make a good alternate.

The core Rarest Piece downloading algorithm should only be biased by the Space Filling Algorithm, and this bias should not exceed 66% overall but should be greater than 10% to be effective.

Cantor Set
In mathematics, the Cantor set is a set of points lying on a single line segment that has a number of remarkable and deep properties.
It was discovered in 1874 by Henry John Stephen Smith and introduced by German mathematician Georg Cantor in 1883.

Through consideration of it, Cantor and others helped lay the foundations of modern general topology. Although Cantor himself defined the set in a general, abstract way, the most common modern construction is the Cantor ternary set, built by removing the middle thirds of a line segment.

Cantor himself only mentioned the ternary construction in passing, as an example of a more general idea, that of a perfect set that is nowhere dense.

Smith–Volterra–Cantor Set
In mathematics, the Smith–Volterra–Cantor set (SVC), fat Cantor set, or ε-Cantor set is an example of a set of points on the real line R that is nowhere dense (in particular it contains no intervals), yet has positive measure.

The Smith–Volterra–Cantor set is named after the mathematicians Henry Smith, Vito Volterra and Georg Cantor.

Logistic Map
The logistic map is a polynomial mapping (equivalently, recurrence relation) of degree 2, often cited as an archetypal example of how complex, chaotic behavior can arise from very simple non-linear dynamical equations.

The map was popularized in a seminal 1976 paper by the biologist Robert May, in part as a discrete-time demographic model analogous to the logistic equation first created by Pierre François Verhulst.

The bifurcation diagram of a Logistic Map is self-similar. The same is true for all other non-chaotic points. This is an example of the deep and ubiquitous connection between chaos and fractals.

User Interface Impact

Downloading Algorithm
[ ] Just use rarest piece (default)
[ ] Use 1D Cantor Set
[ ] Use 1D Smith-Cantor-Volterra Set
[ ] Use 1D Logistic Map
Bias from Rarest Piece Available
[ ] 20% [ ] 40% [ ] 60%

Issues relating to Tracker handling

1. Remove all duplicated Trackers no matter their type, for each Torrent.
Every tracker "string" should be checked for uniqueness using MD5 as a baseline hashsum, or a CRC like CRC40-GSM. Using CRC40-GSM is adequate enough to avoid about 99.997% of possible theoretical ASCII (or UTF-8) string collisions. This is only if one does not want to put to much stress on any MD5() code section. The 'Initial' and 'Final' Values of the Checksum are up to the implementation.
If two or more trackers have the same checksum (and or) hashsum then they are duplicated and redundant. Duplicated Trackers should be automatically deleted. However, the user should be told of the duplication (and or) should be given a chance to give permission for the deletion.

There may be a Torrent database impact if you want to add data fields with the applicable CRCs or hashsums. This is really a runtime garbage collection issue, and that no internal Torrent database changes should be made.
2. A user selectable deletion policy is needed for HTTP, UDP and HTTPS type Trackers is needed.

As a rule, you should be able to choose (by protocol type) if a tracker should be automatically deleted. There is no disadvantage in the automatic deletion of trackers as the "Distributed Hash Tree" and "Peer Exchange" protocols have made public and private trackers less important.

The User Interface changes would look like this

Tracker Management

[ ] Tunnel my DNS requests outside this [ ] network [ ] country
[ ] Tunnel my Tracker requests outside this [ ] network [ ] country
Do [ ] DNS requests for ([ ] Verified and [ ] Unverified) clients outside my [ ] network [ ] country
Do [ ] Tracker requests for ([ ] Verified and [ ] Unverified) clients outside my [ ] network [ ] country

Automatically delete
[ ] duplicated Trackers (recommended) 
[ ] unreachable Trackers (recommended)
[ ] http Trackers (recommended)
[ ] https Trackers (partly recommended)
[ ] udp Trackers
[ ] ask user deletion permission for [ ] http [ ] https [ ] udp

Issues relating to IP4 & IP6 Port use

1. BitTorrent should only use Ephemeral Ports (~32000 to 65000), similar to what FTP has been doing for decades.
The current IP4 and IP6 "Port Use Policy" allows for ports to be used that other applications (or protocols) might be using. This awkward arrangement makes for a nebulous relationship between the protocol and ISPs (and local area Network Managers) that have to manage IP port use.

FTP uses a semi-standardized range of ephemeral ports for its file transfers, and BitTorrent should do this too.
2. IP Ports used should be randomly changed at least once every 90 minutes, or at minimally every 20 minutes. This is somewhat of a privacy issue, but mostly this is prevent any particular port from being overused.

User Interface changes would look like this

Port Utilization
[30000] Preferred start Port [Default]
[60000] Preferred end Port [Default]
[ ] Randomize Port every
    [ ] 30:00 [ ] 60:00 [ ] 80:00
    [ ] (±) 5 minutes

Issues relating to Cryptography

1. More kinds of cryptography need to be made available.

2. The ability to have different Inbound and Outbound cryptography, on a per Torrent basis.

Issues relating to Downloading & Uploading "Mode Control"

1. Currently, the BitTorrent client chooses between "Fast" , "Medium" or "Slow" based on a set of multiple constraints.

Slow mode, for file transfer on DSL or Cable Modem connections can be quite glacial. Slow mode for many high speed connections should be avoided where possible. However, if you are using a modem to do file transfer -- Slow mode is almost the default mode. Slow mode works most reliably for dialup users, and will do so long into the future. Slow mode should be used for slow connections, where its better Error Correction capabilities are best used.

Medium and Fast modes are very similar to each other, but have more highly abbreviated Error Correction and other file segment descriptors. These modes may have emerged after BitTorrent became popular on high speed reliable networks.

There is no "Test Loop Thru" capability to determine the most optimal method for file transfer any particular Inbound or Outbound link. Users need to able to choose the setting that works best for them, but the settings can be found automatically.

Some file transfer modes are more recommended than others for some types of connections. The addition of this feature should not affect the file transfer protocols at all. Preferably, the test loop thru should be done with other clients that the client program is already connected to, although there is some merit for it being done with the client program website.

2. Some sort of user preference for Jumbo file transfer mode needs to exist, as its use is unclear to almost all users and is probably underused on DSL and Cable Modem transmission circuits.

User Interface changes would look like this

Preferred File Transfer modes
[ ] Slow (for dialup users)
[ ] Medium (for WiFi & DSL, or general use)
[ ] Fast (for general high speed use)
[ ] Use Jumbo file transfers (when possible) sized [ ] 64k [ ] 32k [ ] 16k
[ ] Do mode loop-thru test [to be implemented]

Issues relating to DHT and DNS servers

DHT and DNS are vitally important to BitTorrent file transfer operations, and strategic strangulation points. Many "Man in the Middle" attacks are possible, and BitTorrent file transfer networks can easily be disabled or shut down if attacked in these protocol domains.

Distributed Hash Tree (DHT, BitTorrent's and uTorrent's example)

The "BitTorrent Distributed Hash Table (DHT)" has a fundamental dependency on being introduced to some nodes that are already in the network. There are many sources of these nodes. For instance, your client is likely to save nodes on disk to retry them when you start back up again. Any BitTorrent peers are likely to be on the DHT as well, so those are also tried. However, if you just installed a BitTorrent client, and you don’t have any BitTorrent peers, you must rely on a bootstrap server.

The BitTorrent (company) runs <router.bittorrent.com> (on port 8991 + a spare in the uTorrent domain) for the purpose of boostrapping its own products like BitTorrent Sync, uTorrent and the standard BitTorrent client. However, these DHT servers in the 2 domains are subject to "Domain Name Seizure" and could be made unreachable all too quickly. This is no way to run a DHT server system, as the redundancy is almost non-existent.

Each BT protocol client needs to have a pool of about 16 DHT servers accessible to it, but 64 DHT servers would be more optimal
Some BT client programs allow one to add DHT servers, but at best only 1 or 2. Adding DHT servers is an advanced user feature that takes a bit of work to do, if you have access to or run a local DHT server.

Ideally entities like BitTorrent (company) should make a deal with entities like the "Electronic Freedom Foundation" (not just in the US, but in places like Australia where they also exist) to run local DHT servers in their domains. Globally there needs to be about 256 to 512 "dedicated upper level DHT servers" to serve the needs of the BitTorrent protocol and other protocols (and protocol networks) that need to use DHT.
DHT is increasingly being used for a lot of security oriented functions, BitTorrent (company) is developing a Chat network based on DHT

For DHT "Node ID" enforcement reasons, the DHT protocol version and software codebase version need to be accessible in the BT client. This practice must apply to the "Peer Exchange" and "Local Peer Discovery" protocols too.

Node ID enforcement is key in the securing of DHT.

With Node ID enforcement DHT becomes harder to attack (especially with sybils). The idea is that with Node ID enforcement sybil attacks (where one machine pretends to be thousands of nodes) will become if not impossible at least not practicable. The new bootstrap server will still serve nodes with invalid node IDs (in fact, legitimate nodes just joining are not likely to know their external IP yet so this is not necessarily a problem). However, as a rule -- the DHT Server will neither "ping nor add" these nodes to the node list before handing them out.

DHT server stress will keep increasing as DHT use increases. The whole DHT networking concept (and the BT protocol clients that use it) needs overall to become at least 10 times more redundant (or an order of magnitude) than it is in the 2015s.

With increased use of DHT, the protocol will come under increased security attacks. DHT may be compromised as HTTP Trackers were in the 2010s. The DHT servers a BitTorrent client accesses must be authentic! 

Related reading
-- http://engineering.bittorrent.com/2013/12/19/dht-bootstrap-update/ (summary of the BT DHT server, and security issues)
-- http://libtorrent.org/dht_sec.html (the LibTorrent DHT security extensions)
-- https://github.com/bittorrent/bootstrap-dht (DHT Bootstrap Server)

User Interface Impact (I)

Distributed Hash Tree Servers
Update DHT server list every 2 Hours [ ] or every Hour [ ] or Continuously [ ]
Update DHT server list also via Peer Exchange [ ] or Local Peer Discovery [ ]
Update DHT server list also via VPN [ ]

DHT Server Usage
[ ] Randomize DHT Server Each Time
[ ] Prefer Best Performing DHT Servers
[ ] Prefer Nearest Local DHT Servers
[ ] Prefer DHT Servers outside of my network
[ ] Prefer DHT Servers outside my country
[ ] Use DHT Local Server at [ ] or IP [ ]

User Interface Impact (II)


Protocol Version
Update In
Blocked Spoofed

Local Peer Discovery

Peer Exchange

Tracker Exchange 2015aa GTG

{Tracker List}

Countermeasures for DHT Spying (IP4 and IP6)

Content via : https://torrentfreak.com/thousands-of-spies-are-watching-trackerless-torrents-151004/

(some minor alterations have been made for readability, this text is necessary to understand the User Interface modifications needed)

[..] Anti-piracy outfits are known to monitor users through public trackers. However, new research reveals that BitTorrent's DHT is full of "spies" who actively harvest IP-addresses.

The downside of the DHT approach is that anyone can see who’s sharing a particular BT Object. Because of the unusual nature of the protocols BT uses -- it’s not even required for monitoring outfits to actively participate. This security (man in the middle) ‘vulnerability’ is exploited by dozens of tracking companies around the world, some of which send file-sharers warning letters, or worse. However, the “spies” are not just getting info from trackers, but also BitTorrent’s (Mainline) DHT.

Through DHT, BitTorrent users share IP-addresses with other peers.

Thus far, little was known about the volume of monitoring through DHT, but research from Peersm’s Aymeric Vitte shows that it’s rampant.

Through various experiments Vitte consistently ran into hundreds of thousands of IP-addresses that show clear signs of spying behaviour.

The spies are not hard to find and many monitor pretty much all torrents hashes they can find. Blocking them is not straightforward though, as they frequently rotate IP-addresses and pollute swarms.

“The spies are organized to monitor automatically whatever exists in the BitTorrent network, they are easy to find but difficult to follow since they might change their IP addresses and are polluting the DHT with existing peers not related to monitoring activities,” Vitte writes.

The research further found that not all spies are actively monitoring BitTorrent transfers.

Vitte in the body of research accumulated makes a distinction between Level 1 and Level 2 spies, for example.

Level 2 Spies are Data Collectors

According to Vitte, this usage defect could be used by accused pirates as a defence.

“That’s why people who receive settlement demands while using only DHT should challenge this, and ask precisely what proves that they downloaded a file,” he says.

After months of research and several experiments Vitte found that there are ~3000 spies that could be considered dangerous for ordinary BT users. These include known anti-piracy outfits such as Trident Media Guard -- but many unnamed spies that use rotating third party IPs so they are harder to track.

Since many monitoring outfits constantly change their IP-addresses, static blocklists (updated once per day) are structurally and functionally useless.
Vitte believes that the dynamic blocklist he has developed provides adequate protection -- with near real time updates. This (paid) blocklist is part of the Open Source Torrent-Live client which has several built in optimizations to prevent people from monitoring downloads. People can also use it to built and maintain a custom blocklist.

Vitte further proposes in his ongoing research several changes to the BitTorrent protocol which aim to make it somewhat harder to spy on ordinary users. He hopes other developers will pick this up to protect users from excessive monitoring. Another user option (or countermeasure) is to stop the monitoring is to use an anonymous VPN service or proxy, which hides ones actual IP-address.

Torrent-live (http://torrent-live.org/?content; also https://github.com/Ayms/torrent-live) is an open source bittorrent client [...] Most of the Torrent-Live modules are modifications of Peerflix and Webtorrent modules [...] For torrent files formats are not always supported by the web browsers (like .avi or .mkv) -- torrent-live allows you to transcode them real time to a mp4 or webm format that you can stream live too while it is being transcoded.
Torrent-live creates, uses and maintains the dynamic blocklist to block the monitors.

But beside the monitors, anybody can track you inside the bittorrent network, even worse, record your complete torrent history and make it public, should you not believe it just send an email and one might discover what you torrented from your IP [...]

The global method to detect and block the spies [...] could be implemented in any bittorrent client. Alone this is already enough to render the probability to encounter a spy on your way quasi null, but once combined with the dynamic blocklist it becomes quite unlikely that you could be detected by a spy, even by one behaving normally in a torrent or trying to connect to you.

The current design of the user interface is OK [...] but torrent-live is quite efficient and easy to use, it can be installed on Windows, Mac, Linux.

Torrent-live is already working and usable. It is planned to evolve the current version to an user friendly (web interface as shown below) bittorrent client  protecting much more privacy, without ads and intruding stuff.


// TBA //
// TBA //
// TBA //

Issues relating to IP6 Spoofing aka IP6 PEER FLOOD Mitigation

Original source for information on this problem : https://torrentfreak.com/popular-torrents-being-sabotaged-by-ipv6-peer-flood-150619/

Unknown attackers are sabotaging popular TV and movie torrents by flooding swarms with IPv6 peers. The vulnerability, which affects the popular uTorrent client, makes it nearly impossible for torrent users to download files. It's unclear who's orchestrating the attacks but it could be a guerrilla anti-piracy move.

Generally speaking, BitTorrent is a highly robust file-sharing protocol that’s not easily disrupted. However, in recent weeks there have been systematic efforts to prevent large groups of people from sharing popular pirated TV-shows and movies.

The sabotaging technique tries to make it impossible for downloaders to connect to other people by overwhelming BitTorrent swarms with IPv6 peers.

Because of its focus on IPv6, not all users are affected, but those who are sometimes see their download speeds grind to a halt. As a result it can take days to download a file, if at all.

In short the process works as follows. The attacker joins a popular torrent swarm with hundreds, if not thousands of IPv6 addresses. These fake peers request data from real downloaders, quickly filling up their request queues.

The fake peers never exchange any data but keep the client busy until they are banned. 


The attack has been confirmed to affect the popular client uTorrent. After a few minutes uTorrent does ban the malicious peers, but this makes little difference as the attackers use so many different IP-addresses.

Because all the fake peers have filled up the connection slots, real peers can no longer connect. This means that hardly any real data is transferred.

A solution

USE AN IP4 + IP6 Routability Database to verify IP address routability.


The routability database is not an absolute requirement for IP4 addresses, but must be a requirement for IP6 addresses if the IP6 unroutable address flood problem is to be fixed. The BT client needs to look at the database at least 50% of the time to verify if an address is rotatable or not.


The IP routability database feature should be ON by default, but one should be able to turn it OFF for debugging. 


The database should be accessed at least 20% of the time (the default being 50%, step granularity 5%). There should be a user setting to adjust the "probability of access" from 20% to 90%. 





1. 99.9% of IP4 addresses ARE "ROUTABLE" (conservative estimate). Therefore it is only worthwhile storing the individual IP4 addresses that cannot be routed. 


The routability database should store individual IP4 addresses that are not rotatable.  The database should be capable of supporting blocks of unroutable IP4 addresses.


2. 99.996% of IP6 addresses ARE NOT ROUTABLE. Therefore it is only worthwhile to store blocks of IP6 addresses that cannot be routed. 


The routability database should store blocks of IP6 addresses that are not rotatable.  The routability database should be capable of storing individual IP6 addresses that are not routable, as there may be reasons that make it impossible to store some of these addresses in blocks.  


3. The BT client should collect "UNROUTABLE" IP4 and IP6 addresses.


If the BT client encounters more than 500 unroutable addresses, the uploading of the unroutable addresses must be turned on.


This feature should be set up so that it can be turned ON or OFF.

-- The trigger should allow the trigger point to be settable from 100 to 1000. 

-- The unroutable addresses should be uploaded at least once every 3 hours (after being subjected to zip compression and address block merging when the database is frozen some 30 seconds before uploading). 


4. The IP unroutabiliy feature needs to be added to the commonly used DHT Torrent databases primarily as an antispoofing feature. All "real time" IP databases (not just the DHT ones) should have this feature.

User Interface Impact [interface to be created]

Issues relating to the Domain Name System (DNS)

In the current regime, BT clients give the user a choice of 2 DNS servers. This may seem like enough DNS servers, but the sheer lack of redundancy in the DNS systems of most BT clients makes them subject to shutdown (or near total loss of interoperability) at the DNS request level.

The only remedy is for the 10 major players in the BT client business to set up 10 dedicated DNS server networks for exclusive use by their BT client programs.

The server networks should be globally distributed, with at least one dedicated DNS server per major country that uses that particular BT client program.

The DNS solution would work best if this DNS workaround allowed for all of the DNS servers in all of the DNS private networks to be shared reasonably equally. However, limiting these kinds of requests to 10% or 20% of all DNS requests would probably be the fairest and most reasonable DNS practice.

Except for the "fixed" dedicated root DNS server [primary & backup addresses], all DNS server locations should expire after about 123 days after downloading. The expiration dates should be spread out over 2 days, and the client programs should fully update their DNS lists every 100 to 120 days as traffic loads and usage permits.

User Interface Impact
DNS Requests
[ ] Use a pool of [ ] 16 or [ ] 32 global DNS servers
[ ] Use {Client-name} Private DNS servers (recommended)
[ ] Prefer Local Private {Client-name} DNS servers
[ ] Limit other Private DNS server requests to [ ] 10% [ ] 20%
[ ] Limit Public DNS server requests to [ ] 20% [ ] 30%

Issues relating to VPNs (Virtual Private Networks)

VPN use -- for BT protocol use -- has previously (2000 to 2014) been via using Proxies. Every internet application has to support proxies to some extent or other due to the varied networks these programs are used in.

Historically a person had to pay a VPN ISP for access to their VPN network.

The whole arrangement would evolve into a terrible one for both parties.

VPN IPSs are being globally subjected to legal logging requirements, for varied security reasons. With legal VPN logging requirements, traffic privacy vanishes.

The 'central plumbing' arrangement of the 'pay as you go VPN' is becoming too dangerous for any kind of BT protocol use. There is no guarantee of any real privacy with a 'pay per use' VPN, as this seems to have become history as of 2012.

Hope is not lost. VPNs can be configured in a myriad of different ways.

What a VPN is, much less how one is supposed to be structured (or function) are still ongoing debates. There are hundreds of ways to configure how a VPN operates, and AD-HOC VPNs are probably a better long term solution. When the BT protocol first instituted encryption, it almost had the effect of creating a point to point VPN. However, better solutions are needed as even the current encryption solutions used by the BT protocol are showing their age.

uTorrent is one of the first BT clients to go the route of using a VPN, there are others that have used other similar solutions.
Due to the relative obscurity of the update of VPN functionality, there is no user interface to the VPN subsystem to control it.

The slowness of the uptake of the VPN functionality is a testament to the solidness of the current BT protocol encryption practices. Yet, due to the sheer volume of BT traffic the current BT encryption practices are and always have been subject to attacks that could lead to a loss of functionality.

However, if a VPN's settings are not accessible  -- it creates risks equivalent to the current BT protocol encryption settings not being accessible.

There are actually a lot of VPN protocol methods in use. So there is no shortage of protocols to use for a VPN, so it is advisable that more than one kind of VPN should be used (at the same time). Overall, in order to proceed ahead with a VPN for BT protocol use 2 layers of tunnel encryption should be used, one for the outbound data stream and one for the encrypted outbound data stream.

It is an idea worth considering -- creating a psudo-IP6 network (within the ad-hoc VPN networks) to obscure the IP4 or IP6 sources and destinations.

BitTorrent AD-HOC VPN types that should be supported
The primary ad-hoc VPN configuration issues are

Issues relating to client initalization (VPNs)

Because it is becoming more "strategically necessary" to attach to a VPN before sending any BT traffic, the fundamental methods of how a BT client attaches to a network will probably have to go thru some evolutionary change. The current networking attachment models do pose many privacy and security risks. 

An initial model for network attachment for BT clients capable of VPN capability
  1. Attach to DNS Servers
  2. Attach to DHT Servers
  3. Initialize "Peer Exchange" AND "Local Peer Discovery" 
  4. Get DHT Nodes
  5. Attach to DHT Server for VPNs
  6. Initialize limited VPN "Debug Logging"
  7. Get VPN Nodes
  8. Initialize VPN Nodes, Single Layer Encryption
  9. Initialize VPN Nodes, Double Layer Encryption 
  10. Initialize VPN Nodes, Pass Thru Networking (with or without extra encryption)
  11. Initialize VPN vs Non-VPN link management subsystem (VPN "keep alive" timers, Add or Drop Nodes Supervisor, VPN Policy Manager...) 
  12. Resume normal network operation (VPNs, open IP4 or IP6)

User Interface Impact I

Ad-Hoc VPN Settings
Send Keep Alive every [ ] 15 or [ ] 30 seconds with [ ] 5% variation
Rekey every [ ] 15 or [ ] 30 minutes with [ ] 5% or [ ] 10% variation
Insert [ ] 1% [ ] 2% dummy traffic into outgoing [ ] traffic & [ ] encrypted traffic
[ ] Forbid Symmetrical Keys (recommended)
Limit Outbound VPN links to [ ] 5 (dialup) or [ ] 10 (dsl, WiFi) or [ ] 20 (cable)

User Interface Impact II (VPN Tab)

[Ad-Hoc VPNs]

VPN Type
Connected Nodes
Overhead Up
Overhead Down
Dummy Traffic Bad Packets
Rekey Events

User Interface Impact III (Control Panel : Protocol Encryption Settings)

Some programs have already taken alternate approaches to these suggestions, so there is room for flexibility. Tribler nominally uses ad-hoc VPNs.

Tribler Privacy Level Setting

Protocol Encryption

Allow Incoming Legacy Connections [ ]

Outgoing Traffic should
[ ] Force Encryption (increases overall security, but some BT clients may not be reachable) 
[ ] Prefer Encryption (recommended)

Outgoing Traffic in a Ad-Hoc VPN should be
[ ] Encrypted (recommended) with [ ] AES128 or [ ] AES256
[ ] Clear

Italics : Optional

Issues relating to routers

Currently users do not know how many hops away any particular Seed or Peer is. There is an ongoing development of a nearest peer discovery protocol, but its deployment is slow but ongoing.

Ever BT client should run in IP4 and IP6 (where possible) a Traceroute to determine how far away in router hops a Seed or Peer is. However, this is User Interface issue -- so if the user is not choosing to display this on the Seeds / Peers properties list the Traceroute should not be done.

IP4 delivers a solid (but varying over time) hop count, that is the number of routers the packet has had to transverse.
IP6 does not count hops in its Traceroute, so the time delay or time dispersion (in ms) should be used.

NTP, in a modified low complexity form (say NTP-BT) could be used to find precisely the time delays and dispersions of a connection.

User Interface example, at the area where Seeds & Peers are displayed...

Hops (ms)
Socket State
Down Speed
Up Speed
home.test.ca [uTP]
uTorrent 3.0
15 (120)
20 KiB
20 KiB
BitTorrent 2.2
22 (180)
22 KiB
QbTorrent 1.1
26 (211)
10 KiB 5 KiB
null-dev.za [uTP] 60123
LibTorrent 4.0
28 (207)
20 KiB 11 KiB

Issues relating to Error Correction

Currently it is not possible to choose the kind of ancillary Error Correction BitTorrent uses. Error Correction issues are up to the network, but there is no guarantee that in the future BitTorrent will be running on networks as reliable as those today.


The use and setting of the preferred Error Correction should be possible because some people will end up sing BitTorrent over very noisy or error prone circuits. The BitTorrent file transfer protocol should not be altered in any way, but some ancillary signalling mechanisms needs to be created to cope with the issue. It must be up to the programmers that maintain the BT protocols to add the Error Correction code.

The following state diagram makes the assumption that the final file transfer message formatter before the [Transmitter] --> {IP Internet} step is fixed and invariant in its behaviour and thus can be ignored (and treated as part of the [Transmitter]).   

The current pipeline for the transmission of a file segment is

  1. [Sector AA] --> [Transmitter] --> {IP Internet}
  2. {IP Internet} --> [Receiver] --> [Sector AA]
  1. [Sector BB] --> [Encrypt "MK::BB"] -->  [Transmitter] --> {IP Internet} 
  2. {IP Internet} --> [Receiver] --> [Decrypt "MK::BB"] --> [Sector BB] 
  3. "MK" just means Method + Key.
  4. The  "::" is just an operator stating that the variable following it gets operated on.

The pipeline for the transmission of a file segment with Error Correction added :

  1. [Sector AA] --> [ECC Formatter] --> [Transmitter] --> {IP Internet} 
  2. {IP Internet} --> [Receiver] --> [ECC Decode] --> [Sector AA]
  1. [Sector BB] --> [Crypto "MBB"] --> [ECC Formatter] --> {IP Internet} 
  2. {IP Internet} --> [Receiver] --> [ECC Decode] --> [Decrypt "MBB"] --> [Sector BB]
In this state machine diagram, not much change. Only the ECC Formatter and ECC Decoder are added to the transmission chain. Both should be separate entities from the Cryptography or Standard File Segment message formatters.
User Interface example

Preferred Error Correction
[ ] None. Use existing legacy methods.
[ ] Randomize ECC methods
[ ] Voyager ECC [ ] Cassini ECC
[ ] Galileo ECC [ ] Turbo Code ECC
[ ] Low Complexity Parity ECC

ECC Use Policy
[ ] Force ECC over Proxy Connections
[ ] Force ECC over VPNs
[ ] Force ECC for "Slow Mode" transfers

Issues relating to measurement units

Client programs have handled measurement unit display issues better as time has gone on but there is still a lot of work to be done.

One classical mistake made by uTorrent (but it is not alone) is that it displays a torrent that was not downloaded by the client as having a Share Ratio of Infinity. This is crazy maths, and a botched display issue.

All uTorrent's display mistake means is that Americans can't do maths -- as BitTorrent is an American corporation.

Measurement unit display should not affect any of the client program's byte transfer accounting code. The client's accounting code should be accurate to within (±) 16 bytes.

User Interface example (italics, not really required)

Measurement Units (Sizes, Speeds, Dates)
[ ] Base 1; Kilobits, Megabits, ...
[ ] Base 5; Kilobauds, Megabauds ...
[ ] Base 16; Kilowords, Megawords, ...
[ ] Base 1000; KiB, MiB, GiB ...
[ ] Base 1024; KB, MB, GB ...
[ ] I prefer [ ] 2 or [ ] 3 or [ ] 4 decimal units of precision for user interface numbers.
Display  [ ] Fuzzy or [ ] Exact : Dates & Times
[ ] Use the Torrent object size as display default (if downloaded bytes ~ 0)
[ ] Show friendly hashes (823F0 AD700 ...) but copy normally

State Machine Transfer between BitTorrent Clients & Trackers

1. For partial sectors, there is no quality state transfer that has low bandwidth.

2. There needs to be a non-binary XML based, stateless Client to Client state transfer mechanism. The current mechanism is a mess of binary bit fields that are badly documented and often badly constructed.

Geneara1 Requirements

Standards Compliance
If it is decided that an existing XML protocol should be used, a backup related protocol should available as an alternate.

Such a mechanism should be limited to transferring less than 1000 bytes at a time, with 1200 being the maximum limit.
Such a mechanism should only use Printable ASCII, to reduce complexity. Header : <?xml version="1.0" encoding="ASCII6" ?>
Such a mechanism should have a header prefix of no more than 10 bytes indicating compression state.

Encryption & Error Correction
Such a mechanism should only transfer Client to Client 'state' in an Encrypted form.
Such a mechanism should protect the state transfer with a hashsum. MD5 should be the baseline minimum, SHA256 preferred.
Such a mechanism should put the hashsum of the transfer in the header.

Such a mechanism should ZIP compress the State Transfer XML data to keep it under the 1000 byte limit in IP4.
To reduce bandwidth there needs to be an option of permitting Base64 encoding and ZIP compression, if really complex state transfer is needed.

Version Tracking
Such a mechanism should provide a protocol version number of the last agreed upon standard update : Example : "2014.08"
Such a mechanism should force very sub protocol to have a version number. Example : "2014.08"

Message Number Tracking
Every message should have a number string in the format "RR_YYY_DDD_HH_$$$"

There needs to be 12 record types, with about 10 sub-types for Preferred Communications State
  1. Choking State. If a client is overloaded, it needs to indicate what Torrents are affected and how. Up to 10 Torrent states could be transferred.
  2. Endgame Mode (must be under 100 bytes)
  3. Synchronisation State. To keep Cryptography, Error Correction, Speed and other factors synchronized. Only 1 Torrent State at a time.
  4. Data Loss or Message Loss. {Message Number; Lost, Garbled}
  5. Client Friendly Name and 3 bitstrings for client to client authentication. (Name or UTF16 Name, Bitstrings [1 2 3])
  6. Discovery State (Distributed Hash Tree, Local Peer Discovery, Peer Exchange, Experimental, Test)
  7. Client A <---> Client B Verification, maybe for a partial form of Single Packet Verification.
  8. Remote DNS & Tracker request, Proxy Protocol.
  9. Private TRACKER : Login or Authentication State.
  10. Private TRACKER : Accounting State. How much of a Torrent has been transferred. This is transmittable to Trackers only. Must be Encrypted.
  11. Public or Private TRACKER : Other Client State, how many other people have Torrent "X"? Must be Encrypted.
  12. Preferred Communications State

Issues relating to updating a Client

1. Currently, traditional HTTP and HTTPS are used to download and update BitTorrent clients. This updating mechanism works very well except for the problem of website availability, something that typically suffers badly when a major client update is released.

A few clients can use FTP or SFTP for client updating, but this is rare. FTP as part of a client update mechanism is still a capability that is not used. Very few BitTorrent clients have any support for FTP at all unless they are of the dedicated downloader type.

Although it is not foreseeable that any or all of these protocols will cease being used for updating clients in the future, traditional file downloading technology is not the most efficient way of updating a client.

Data compression schemes are essentially not used for updating clients. This helps neither the user nor the creator of the client program.

The bandwidth saving gains of BDIFF and CORRAGETTE are unknown in the BitTorrent trade when it comes to updating the client program.

Google uses Corragette to update the Chrome browser, and possibly Google Earth. Yet Corragette's use with smaller applications is still limited.

Corragette -- although CPU independent -- in practice it is deeply tied to the X86 CPU binary architecture in its current form. Modifying a client updating mechanism to support Corragette has not been done yet. As most BitTorrent applications are small already so Corragette is not considered to be the best fit.

Bdiff is adequate enough (and CPU code decoupled enough) to more than adequately fit the needs of client updating for minor versions for the next decade.

2. Every client should have a separate updater program. With uTorrent, this is the exception but the cost is complexity -- and sometimes the updater just does not work.

Assumptions made on roles of the programs
  1. The Client Program can only download the : Updater, Translation or Help Files, Updated Version of the Client.
  2. The Updater can only install the the Updated Version of the client, or any Translation or Help files.
  3. The Updater can do "garbage collection" keeping the file structure of the installed program free of any no longer necessary files. 
  4. The Updater should only run for no more than 20 minutes each day, excluding installation runs.
The usual algorithm for updating the Updater (generalized) :
The usual algorithm for updating the Client Program (generalized) :

3. Every client needs to keep 1 to 3 copies of older versions (and or Beta versions) so that it may be possible to revert to an older version.

Keeping multiple versions around for backup opens up the option of reverting to the most recent Stable Version -- if one is leaving the Alpha or Beta track.

This program updating flexibility is really needed for times when the current version is not working.

Suggested directory structure
Suggested update process
Update to the [ ] Beta [ ] Stable version when possible.
In Beta [ ] exit me to Stable version when convenient.
Beta testing Captcha ( ) [ ] {Submit-button}

Use  [ ] ftp; [ ] sftp; [ ] http; [ ] https; [ ] BitTorrent to download update.
Do not use [ ] sftp; [ ] https; [ ] BitTorrent;  to download update.
Use [ ] BDIFF for minor version updates.
Use [ ] Corragette for minor version updates.
Update the updater ever [ ] 2 weeks [ ] month
Update help & translation files every [ ] fortnight [ ] month

Italics : Optional.

Issues relating to outbound messages

1. BitTorrent can be very bursty protocol. There can be literally 'storms' of outbound control message packets to send -- and this results in equivalent storms of these same packets being received by the client at the other end.

These control message storms can sometimes surpass the capacity of the communications link for the client program at the other end, resulting in forced TCP queuing and general misbehaviour of the communications link between the clients.

The storminess of the control message protocols can lead to control message losses and retransmissions, and this should be avoided.

Outbound control messages are not subject to rate limiting (or queueing).
When outbound control messages are subject to queueing or rate limiting : the outbound rate is essentially so high as to be meaningless.

Each control message should be allocated no more than 2048 bytes in a fixed size message queue array.

2. Control message types (choking, have-all, have-none, ...friendly-name) don't have priorities. Most BitTorrent clients treat all outbound control messages as having equal priority. This bizarre protocol habit has been in place since the protocol was invented, and it only makes extra busy work for routers and bridges.

Priority [1 ...8]
Control Message Type
Choking State, Endgame Mode Absolute requirement
UDP & IP6 Affinity
UDP to avoid TCP "man in the middle" Hangup attack
Error Correction Affinity
For Client to Client connections for some downloaders
VPN Preferences
For VPN link negotiation
Have-all or Have-none
To sort out seeders or those starting at 0% or 100%
Real Time Debugging "data block"
~ 1kb to ~4kb of state information for debugging
Standard Have() + Partial_Have() bitfields
4 bit quantized Have bitfield
Cryptography settings
Before or during any file transfer
Partial Have database, 8 / 16 / 32 / 256 segments;  32 bit int
Preferred File Transfer Modes
Before or during any file transfer; allows for use of FTP(s), HTTP(s)
IP4, uTP Connection Reset Requests
Done about 120s before needed, to fix uTP & IP4 bug
Pause State
True / False; Will Resume In (seconds);
Extra DHT, DNS servers (secure-sig)
To allow DHT & DNS server lists to be propagated;
Client to Client Verification
To shut down communications with clients that misrepresent themselves
Terse-name decoders can fill the gap, so not critical
Friendly-name long
To add Build Number, OS, 32 vs 64 bit version
Protocol test 'A1A' ... 'Z9Z'
To test a protocol before releasing it, $#$ to label disambiguate protocols

User interface impact

Outbound Control Message Limits
No more than [ ] 2 [ ] 3 [ ] 5 per second.
Queue size [ ] 25 [ ] 50 messages.
Control Message Priority
[ ] Default model or [ ] Test model.


With the new space available for protocol messages, the HAVE-ALL and HAVE-NONE message needs to be revised into a puzzle.

The "HAVE-ALL" message in the original BT protocol was subject to a "man-in-the-middle attack" at the ISP router.

A HAVE-ALL message can get a Client <-- --> Client connection shut down in TCP via sending both sides a "TCP-HANGUP" message.

The new BT protocol for HAVE (ALL|NONE) messages have only temporarily fixed the problem [of ISP man-in-the-middle-attacks].

This fix is subject to being undone at any minute, so this fix needs a long term fix.

There is a better solution to the HAVE "ALL or NONE" Protocol  

THE FIX IS : send a puzzle with a Binary (1,0) or Terinary (1,0,-1) outcome.

The puzzle must be simple enough (as in Linear Algebra, or Factoring for Prime Numbers or even Cryptocurrency Mining [if both paries have ASICs to do so]) to be solved in 30 seconds by a 32 bit CPU running at 100 MHz with one core.

As most CPUs running BT applications are typically running at 400 MHz (Android Devices) to 3500 MHz (most multi-core desktops) so this should not prose a problem at the client.

However, these changes would require routers at ISPs to send this session data off to a local cloud of computers. As this cloud of computers would clearly consume electricity, staff time and wages -- this change could end the practice of ISPs exploting this part of the BT protocol set to forbid seeding.

This means

Issues related to RAM Cache Size

There is no reason for BitTorrent clients to have disk cache sizes beyond 100 megabytes.

In typical BitTorrent client use -- a RAM Cache of (32 or 40) megabytes  -- is in many cases "almost too much".

With older Android mobiles getting by with a RAM Cache of 20 megabytes may be absolutely necessary.

So for the sake of other programs running on the host machine, minimizing the RAM Cache size is vitally important operational imperitive.

A small RAM Cache does not force the host operating system into unproductive disk thrashing.

User interface impact (add around Disk Caching related parts of the user interface)

[ ] limit RAM hard drive cache memory to
     [ ] 40  [ ] 32  [ ] 20  [ ] 16  [ ] 12 megabytes

Issues relating to long term conversion to "Polymorphic BitTorrent Protocols" (but not affecting Encryption)

In order to understand what a "Polymorphic Protocol Engine" is and what it does you must see


OSI Layers and the OSI Model

CRCs & Hashsums

DHT (Distributed Hash Tree)

Diff, bsDiff & Corragette

XML, plain and compressed

VPNs (Virtual Private Networks)

VPN Risks

VPN Types (short list, by no means authoritative)

Bad ISPs (ISPs that make alterations or censor BitTorrent traffic)

1D Fractal Downloading algorithm alternates
List of fractals by Hausdorff Dimension (contains index of 1D type fractals)
General Risk Vectors that may Indirectly Impact BT Protocols and Content

Legal Risk Vectors

Open Source Systems, the way the world is going

Initial Ideas
Document Created

Last Revised

Revisions made


Revision state

June 2010 to August 2013
06 September 2013

01 December 2016

Archive previous version, Update 1 @  Y=2016


Currently Revisable & Updatable