Some Urgently Needed Changes To Make BitTorrent Clients Function in Their Users Best Interests

Some Urgently Needed Changes to Make BitTorrent Clients Function in...
http://hireme.geek.nz/bt-usability-fixes-needed.html
Some Urgently Needed Changes

to Make BitTorrent Clients (and Protocol) Function
in Their User's Best Interests
Abstract
These are changes that primarily need to be made in BitTorrent client
program user interfaces, but secondarily need to be made in the way the
client program interacts with the computer system it is running on.
There are some suggestions for some protocol changes, but these changes do
not affect the way the files themselves are transferred.
The BitTorrent protocol should (in the long run) be overseen by the
International Telecommunications Union (ITU), in the capacity of providing
"a framework for documenting the protocol state machines" (Client to Client,
Client to Tracker & Torrent File Syntax).
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.
Preface
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. However, every aspect of BitTorrent's use is affected by ongoing security concerns and
problems.
Notably : the era of blindly trusting BitTorrent clients is history
BT Client verification is about the only way to spot web robots applications pretending to be actual BT clients.
Fake BT clients mostly are web robots whose goal is to track down people for abuse because of supposed copyright
issues.
The fake BT client policy will probably evolve into verifying BT clients an banning the fake ones, and the IP
1 of 28
12 Dec 15 18:37
2 of 28
addresses and domains they use.

There may possibly evolve a real time public database of reverse IPs (and application fingerprints) for dangerous
BT clients.
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 encryption are essentially mandatory as of 2014, but only single layer encryption is available. Using
the existing single layer encryption has practically been mandatory since 2009. No other outbound transmission option is
safe, yet BitTorrent client applications fail to warn a person of insecure transmission or usability settings.
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 behavior 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.
BitTorrent Realpolitik
Copyright Law in the English speaking world has been turned into a sort of tyrannical "joint venture" State & Copyright
Sector property confiscation law. The state ends up being the biggest loser of all, but the governments in the English
speaking world are more or less enslaved to varying degrees to this so called Copyright Mafia. The long term equation of
how the copyright laws have evolved is not good, and individuals (but not corporations) that create copyrightable content
are now the greatest victims of the copyright laws in place.
There is a legal tactic of entrapment used especially in he US (and Canada, by proxy) where the copyright holder gets all
the person's money -- and the government is shackled with prison and court costs (and the person being rendered nearly
permanently legally unemployable). The end product being Copyright Holder gets a small amount of money, and the
government loses many millions (but mainly billions).
The ongoing Canadian example (FEB 2014)
Note that New Zealand and the US, UK, Sweden etc ... are far more corrupt and abusive with their own similar laws
A Canadian internet service provider has been ordered to hand over the names and addresses of about 2000
customers who allegedly downloaded movies online. [...] As a result, those TekSavvy customers could
eventually receive a letter from Voltage threatening legal action. Under the federal Copyright Act, statutory
damages for non-commercial infringement range between $100 and $5,000. [...]
TekSavvy's Lead Counsel Nicholas McHaffie (a lawyer with Stikeman Elliott) said the safeguards the judge
put in place would put Voltage on a "tight leash" and help to discourage copyright trolling.
"The concern is that in getting 2000 names, the Copyright Holder can simply send out a bunch of letters that
threaten legal proceedings and make outrageous demands for compensation -- and say youre going to face a
lawsuit if you dont" he said in an interview with CBC's The Lang & OLeary Exchange.
Voltage has been accused of threatening lawsuits against thousands of BitTorrent users in the US. Typically
internet users do not have the resources to fight the threat of a lawsuit, McHaffie said. But the case
12 Dec 15 18:37
management process will ensure that Voltage does not overstate its case in the letters to alleged downloaders,
he said.
There was a real concern that what we had here was not an occasion to enforce copyright, but rather an effort
to send out a large number of letters and reap a bit of a reward using the process of the court. The court
responded by saving we want to be very careful before we allow that to happen in Canada, McHaffie
added. Voltage was also ordered to pay any costs that TekSavvy incurs in identifying the customers in the
case, as well as legal fees. [...] CPPIC Director David Fewer said his read of the decision is that the court
would not be eager to assign penalties at the higher range of what the Copyright Act allows.
"If Voltage is asking for figures in excess of [$100] I think the court is going to shut them down pretty
quickly" Fewer said.
"And if that's the case I think Voltage is done because this is no longer a viable business model. And that's
what the whole copyright troll thing is about, it's about using the court process to get settlements that are in
excess of what you could get for [actual] damages to scare people into settling."
Fewer said he was happy that the court will vet any letters that Voltage sends to alleged copyright offenders,
since they're typically designed to scare people into settling a case.
"A lot of people just pay the settlement rather than deal with the uncertainty and the anxiety of the claim and
the model is predicated on that," he said.
"Certain people are risk averse and it's cheaper to settle rather than to hire a lawyer to deal with it, even if you
are innocent."
The strangest of all, is why there is even this kind of corruption of the law exists at all. If reliable (but officially unofficial)
sources are right, BitTorrent use is the least of concern for nations like the US or Canada or New Zealand. If you know
whom to ask, this strategic knowledge is apparently available.
It is a widely known in the signals intelligence intercept profession (and never classified as an official state secret in
the English speaking countries) that MOSSAD apparently has placed a number of Tzar Bomba type weapons for
use when the US finance system melts down. A US bankruptcy could terminate the flow of money to MOSSAD,
and the state it runs. Thus the need for an atomic war. There is a nuclear weapons arsenal at its disposal.
These Tzar Bomba weapons were strategically placed as far back as the late 1990s, and are apparently real. These
weapon systems will be used, there is no question about that. Possibly 100 millions in North America may be killed,
even 200 millions is not unreasonable. On top of this, it could all happen in a single day. Yet, in light of the
Snowden Files -- it is beyond improbable that those in the signals intelligence profession in the US (or Canada, or
the UK for that matter) are even capable of finding these Tzar Bombas. It is beyond hopeless to even think that
these weapons can be kept from being used when the Global Finance Crisis truly does melt down.
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.
3 of 28
12 Dec 15 18:37
4 of 28
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 500 (recommended)
[ ] Base 100
[ ] Base "Number of Files" in Torrent (memory efficient)
[ ] Give smaller files higher priority
[ ] Each file must have a unique priority
[ ] 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.
12 Dec 15 18:37
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 avalable
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 SmithVolterraCantor 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.
5 of 28
12 Dec 15 18:37
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.
SmithVolterraCantor Set
In mathematics, the SmithVolterraCantor 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 SmithVolterraCantor 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 Franois 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.

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.
6 of 28
12 Dec 15 18:37
The User Interface changes would look like this

Tracker Management
Security
[ ] 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.
7 of 28
12 Dec 15 18:37
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 dont 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
8 of 28
12 Dec 15 18:37
optimal
DHT_Primary, DHT_Fallback01, DHT_Fallback02 ... DHT_Fallback16
Stored in the format "{Server-Domain:Port}" format like this "router.bittorrent.com:8991"
Using "Port 8991" exclusively for DHT is a bad idea, BT clients should use Ports (60256 ... 60512; 61512 ... 61768)
as DHT fallback.
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.
Entities like the "Electronic Freedom Foundation" should not be the only option, as many entities like University
(Fraternities, Computer Science Departments, Electrical Engineering Departments) etc ... might be willing to set up
DHT servers for local campus use.
Having established entities run DHT servers is at best a stop-gap measure, as a method of redundancy it should only
be about 1/3 of the solution to the global DHT server availability problem.
Ideally, some BT clients should support their own ad-hoc DHT protocol servers. It will take time, and some minor
tweaks to the DHT communications system as a whole (a user may need to choose to bind to a DHT network :
BitTorrent, qbTorrent, etc...) -- but hundreds of thousands of DHT servers is way better than 200 or even 500
dedicated core servers.
DHT is increasingly being used for a lot of security oriented functions, BitTorrent (company) is developing a Chat
network based on DHT
See : http://engineering.bittorrent.com/2013/12/19/update-on-bittorrent-chat/
See : http://labs.bittorrent.com/experiments/bittorrent-chat.html
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)
9 of 28
12 Dec 15 18:37
User Interface Impact (I)

Distributed Hash Tree Servers
Update DHT server list every Fortnight [ ] or Month [ ]
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
[ ] Use DHT Local Server at [ ] or IP [ ]
User Interface Impact (II)

[Trackers-Tab]
Name
Protocol Version
Status
DHT
2014aa
OFF
Local Peer Discovery
2013ce
ON
Peer Exchange
2013gv
ON
Tracker Exchange
2015aa
GTG
Update In
Seeds Peers
Downloaded
Blocked
Spoofed
{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 whos sharing a particular BT Object. Because of the
unusual nature of the protocols BT uses -- its 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 BitTorrents (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 Peersms Aymeric Vitte shows
that its rampant.
Through various experiments Vitte consistently ran into hundreds of thousands of IP-addresses that show clear signs of
spying behaviour.
10 of 28
12 Dec 15 18:37
11 of 28
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 1 spies are the largest group. Level 1 spies spread randomized IP-addresses for torrents.
The more dangerous Level 2 spies use the DHT IP-addresses to connect to file-sharers.
Level 2 spies also respond automatically, and return peers for torrents that dont exist.
Level 2 Spies are Data Collectors
The Level 2 spies are the Data Collectors, some if which use quickly changing IP-addresses.
Data Collectors as a matter of protocol and procedure pretend to offer a certain file and wait for BitTorrent users to
connect to them.
Interestingly, only very few of the Level 2 spies actually accept data from an alleged pirate, meaning that most
cannot at all prove [without a doubt] that pirates really shared something.
According to Vitte, this usage defect could be used by accused pirates as a defence.
Thats 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 FAQ
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.
12 Dec 15 18:37
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.
== USER INTERFACE (AND DHT DATABASE CONTROL PANEL) IMPACTS TBA ==

// 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-ipv6peer-flood-150619/
12 of 28
12 Dec 15 18:37
A solution
13 of 28
12 Dec 15 18:37
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.
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.
14 of 28
12 Dec 15 18:37
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
Point to Endpoint (easiest to do, optimal for many networks and networking conditions)
Point to Endpoint Multihop (more secure, but still a point to point connection but with intermediate nodes)
Point to Mesh to Endpoint (even more secure, subject to stateful routing issues; security level can vary)
The primary ad-hoc VPN configuration issues are
limiting the number of VPN links
network keep alive signalling
network rekeying intervals
network "dummy traffic" insertion (at all encryption layers involved)
network management of 2 layers of encryption
network management of traffic forwarding
network management of IP address remapping
network management of DNS requests (not mandatory, if set elsewhere)
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"
15 of 28
12 Dec 15 18:37
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 Time-up Connected Uploaded Downloaded Overhead Overhead
Nodes
Up
Down
Dummy
Traffic
Bad
Packets
Rekey
Events
Psudo-wire 22m
413kb
4852kb
37kb
24kb
1.25%
Tinc
31m
10
1572kb
7243kb
63kb
44kb
1.99%
...
...
...
...
...
...
...
...
...
...
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.
16 of 28
12 Dec 15 18:37
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.
17 of 28
12 Dec 15 18:37
User Interface example, at the area where Seeds & Peers are displayed...
IP
home.test.ca [uTP]
Port
Client
42155 uTorrent
3.0
Hops
(ms)
Socket
State
Down
Speed
Up
Speed
15
(120)
33.6 encrypt
20 KiB 20 KiB
brandenburg.haus.de 52111 BitTorrent

2.2
22
(180)
21.5 clear
22 KiB
waka.org.nz
38251 QbTorrent
1.1
26
(211)
11.9 encrypt
10 KiB 5 KiB
null-dev.za [uTP]
60123 LibTorrent
4.0
28
(207)
80.0 clear
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.
ADDING ERROR CORRECTION MUST HAVE NO IMPACT ON THE FILE SECTOR TRANSFER PROTOCOLS.
ERROR CORRECTION MUST TAKE PLACE IN THE FILE SECTOR PRE-FORMATTER (AFTER THE
ENCRYPTION BLOCK IF APPLICABLE).
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
CLEAR
1. [Sector AA] --> [Transmitter] --> {IP Internet}
2. {IP Internet} --> [Receiver] --> [Sector AA]
CRYPTO
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 :
18 of 28
12 Dec 15 18:37
CLEAR with ECC

1. [Sector AA] --> [ECC Formatter] --> [Transmitter] --> {IP Internet}
2. {IP Internet} --> [Receiver] --> [ECC Decode] --> [Sector AA]
CRYPTO with ECC
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
19 of 28
12 Dec 15 18:37
20 of 28
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.
Acceptable : Wireless Binary XML.
Acceptable : Efficient XML Interchange.
However, the compressed token must not sacrifice any extensibility or upgradeability.
Coding
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.
Compression
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_$$$"
R : Reserved for future use, maybe use a Mod 11 checkdigit.
Y, D, H : Year, Day of Year, Hour
$$$ : "BBB" to "YYY" (13824 states) = 13824/{60m x 60s} ~= 3.84 messages possible per second.
The letter string at the end should reset every hour.
Every message should expire [and be deleted] after 2 minutes.
There needs to be 12 record types, with about 10 sub-types for Preferred Communications State
12 Dec 15 18:37
21 of 28
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
UDP, IP6 Affinity
Connection Reset Request (verification hash or bitstrings; sender's countdown timer {128 ... 8}seconds;
this is to work around IP4's and uTP's sequence numbering bugs)
Cryptography Settings (Capable, Current, Preferred, Fallback)
Error Correction (Capable, Current, Preferred, Fallback)
User Connection State (Dialup, WiFi, DSL, Cable, Business Internet)
Preferred File Transfer Modes (Slow, Medium, Fast, Jumbo, Experimental, Test)
HAVEs (HAVE-ALL or HAVE-NONE), with a Torrent hash as an initial parameter.
HAVEs (Bitfield or Partial Have), with a Torrent hash as an initial parameter.
Partial Sector Transfer State (unsigned 16 bit int for the sector number; unsigned 4 bit quantized bitfield
of each partial sector; up to 20 sectors transmittable at a time). The Torrent hashsum is the initial
parameter.
Italics, highly important
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
12 Dec 15 18:37
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) :
Client Program : Is the Updater changed?
Download Updater via same method as the main program updater.
Inform user of new Updater version.
On next run, run Updater.
If there is no new Client Program version, Quit. [In case the Updater and New Client Version are both
available at the same time.]
If there is a new Client Program or Translation or Help files, Install them.
The usual algorithm for updating the Client Program (generalized) :
Is there a new version of the Client Program?
Download the Client Program via user chosen method.
Use Torrent file to verify New Client program.
Inform user of new Client Program version, offer to Install it.
Call Updater to install the new Client Program.
Quit after launching the Updater.
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
... /{Torrent-client-name}/{Client-directory-01},
... /{Torrent-client-name}/{Client-directory-02},
... /{Torrent-client-name}/{Client-directory-03} ...
22 of 28
12 Dec 15 18:37
Broadly, the way the Chrome Browser has its directory structure has the most merits as this directory
structure supports keeping previous copies of the application available.
The Chrome Browser directory structure makes "BDIFF and Corragette" updating methods possible
minimizing bandwidth.
Suggested update process
Within {Torrent-client-name}/update/
Within {Torrent-client-name}/temp/ or /tmp/ so as to have a temporary working area for the updating
process.
Having the temporary directory inside the /update/ directory is also viable.
The files in the temporary directory should be deleted 2 to 5 days after the update.
Updates
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]
23 of 28
Control Message Type
Notes
12 Dec 15 18:37
Choking State, Endgame

Mode
UDP & IP6 Affinity
Error Correction Affinity
VPN Preferences
Have-all or Have-none
Real Time Debugging "data

block"
Have-bitfield
Have-bitfield-4bit
Cryptography settings
Partial-have-4bit-quantizeddatabase
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;
Absolute requirement
UDP to avoid TCP "man in the middle" Hangup
attack
For Client to Client connections for some
downloaders
For VPN link negotiation
To sort out seeders or those starting at 0% or
100%
~ 1kb to ~4kb of state information for debugging
Standard Have() + Partial_Have() bitfields
4 bit quantized Have bitfield
Before or during any file transfer
Client to Client Verification To shut down communications with clients that

misrepresent themselves
...
...
...
...
...
...
Friendlyname-Unicode-UTF16
Friendly-name long
Protocol test 'A1A' ... 'Z9Z'
Terse-name decoders can fill the gap, so not

critical
To add Build Number, OS, 32 vs 64 bit version
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.
ADDENDUM
24 of 28
12 Dec 15 18:37
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-inthe-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
Puzzle_outcome {} : 0 (False, HAVE-NONE); 1 (True, HAVE-ALL); -1 (Ternary only, HAVE-SOME)
Puzzles could be used to convey "HAVE-SOME" messages, but the type of puzzle to do this is not clear or obvious
at the time of this proposal.
Issues related to RAM Cache Size

There is no reason for BitTorrent clients to have disk cache sizes beyond 100 megabytes, and in typical use 32 megabytes
is in many cases almost too much. So for the sake of other programs running on the host machine, minimizing the RAM
Cache is vitally important.
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
[ ] 32 [ ] 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
Defcon 21 - Defeating Internet Censorship with "Dust, the Polymorphic Protocol Engine" (http://youtu.be
/3z56andRyCY) & (http://youtu.be/jeX7k1w-Pog)
25 of 28
12 Dec 15 18:37
"Dust" (as it is in the video) is not an requirement, but a lower complexity branch of it is needed for BT protocol
use.
A Polymorphic Engine for Filtering-Resistant Transport Protocols (https://github.com/blanu/Dust)
"Dust" is also at (https://hackage.haskell.org/package/Dust); Research paper (http://freehaven.net/anonbib/cache
/wileydust.pdf)
References
OSI Layers and the OSI Model
Internet_protocol_suite (generally organized around OSI layers of functionality)
Hierarchical_internetworking_model (the simplest way to view layered digital communications systems)
OSI_model (layer generalized number)
Physical Layer (I, raw bit transport not always reliable)
Data Link Layer (II, typically has frames and generally reliable)
Network Layer (III, typically has packets)
Transport Layer (IV, but in IP networking some protocols are mixed with the Network Layer)
In IP, these OSI layers are considered to be highly equivalant : Session Layer (V), Presentation Layer (VI)
Application Layer (VII, although in many protocol cases not differentiable from the Presentation Layer)
CRCs & Hashsums
Cyclic redundancy check
Polynomial representations of cyclic redundancy checks
DHT (Distributed Hash Tree)
Distributed Hash Table (general topic)
Mainline DHT (used by most BT clients)
github.com/bittorrent/bootstrap-dht (DHT Bootstrap Server)
Diff, bsDiff & Corragette
http://www.natehardisty.com/wp/2011/04/10/how-google-chrome-updates/ (--)
Diff (the Diff algorithm that is the basis for most differential update algorithms)
Data differencing (--)
Delta encoding (also known as bsdiff)
http://www.daemonology.net/bsdiff/ (--)
http://www.chromium.org/developers/design-documents/software-updates-courgette (Google Chrome uses
Corragette)
Comparison of data serialization formats (--)
XML, plain and compressed
XML (The general purpose flexible encoding system used on the web for complex and varible data.)
Valid characters in XML (this document type was intended to be printable)
Well-formed_document (As XML documents are stateful records, they must be well formed.)
Property list (a data structure that can be conveyed by XML, although the .torrent file format itself uses
26 of 28
12 Dec 15 18:37
BENCODE)
Binary XML (a terser and also non prinatble form of XML)
Wireless Binary XML (see also : http://www.w3.org/TR/wbxml/ ; an alternate method)
Efficient XML Interchange (see also : http://www.w3.org/TR/exi/ )
VPNs (Virtual Private Networks)

Virtual Private Network (general topic)
Template:VPN (general topic template)
IP tunnel (generically what a VPN is or does)
Opportunistic encryption (what a BT protocol client VPN should do or use in its VPN)
Mediated VPN (what a BT protocol client VPN should do or use in its VPN)
Mobile Virtual Private Network (an important subtype of VPN)
Tunnel broker (vitally important for VPN use in BT client applications)
Pseudo-wire (a notable VPN technology)
VPN Risks
VPN blocking (a current VPN issue in China)
Deep packet inspection (a general risk to all Internet protocols)
Stateful Packet Inspection (a general risk to all Internet protocols)
TCP reset attack (a risk factor for all VPNs that are totally dependent on TCP)
IP blocking (a VPN risk)
VPN Types
HTTP tunnel (a type of VPN that could be used)
ICMP tunnel (a covert tunnel)
Fast Local Internet Protocol (replaces IP's TCP and UDP, has the capability of VPN functionality)
Tunneling protocol (a plaintext tunnelling protocol)
Tinc (Open source protocol, significantly used)
Bad ISPs (ISPs that make alterations or censor BitTorrent traffic)

http://wiki.vuze.com/w/Bad_ISPs (other sources TBA)
1D Fractal Downloading algorithm alternates

List of fractals by Hausdorff Dimension (contains index of 1D type fractals)
Hausdorff Dimension (The Hausdorff medthod of measuring 1D, 2D and 3D Fractals)
Logistic map (1D, but memory efficent), Cantor Set (one of the 1st 1D fractals noticed by the maths trade,
reasonably memory efficient)
Smith-Volterra-Cantor set (SVCS is reasonably suitable for downloading Torrents with 1000 or more segments, may
have better System Gain.)
General Risk Vectors
Man-in-the-browser (typically not a problem for BT clients that do not support add-on application frameworks)
Legal Risk Vectors
Special_301_Report (Peter Drahos, a law professor at the Centre for Commercial Law Studies at Queen Mary
27 of 28
12 Dec 15 18:37
University of London's School of Law, has called the Special 301 Report "a public law devoted to the service of
private corporate interests". This law explicitly protects and acts in favor of US intellectual property owners, most
often large corporations, against any foreign national policy or unofficial action that does not conform, even in its
domestic legislation, to the US position on international copyright and IP. Threat of action under Special 301 has
been used to insert US trade lobby backed advisers into states' domestic legislative process in order to ensure
compliance with US trade norms.)
A lot of what "Copyright Trolls" do is even legal, so there is the site Fight Copyright Trolls for the US system.
A news site devoted to the legal problems of distributed file transfer : Torrent Freak
BitTorrent sites may decide to flee to the Tor Network, to escape legal sanction ... and the Pirate Browser may be a
way to reach them.
Canadian VPN services could be forced to alert pirating customers
etc
Open Source Systems, the way the world is going
Networks-vs-Hierarchies which will win? Niall Furguson ()
Open Source Revolution vs 1% the US CIA view. ()
28 of 28
Initial Ideas
Document
Created
Last Revised
Revisions made
Version
June 2010 to August

2013
06 September
2013
21 September
2015
Minor text, table

fixes
0.87a
Revision state
Revisable,
Updatable
12 Dec 15 18:37

Some Urgently Needed Changes To Make BitTorrent Clients Function in Their Users Best Interests

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Some Urgently Needed Changes To Make BitTorrent Clients Function in Their Users Best Interests

Transféré par

Droits d'auteur :

Formats disponibles

Some Urgently Needed Changes to Make BitTorrent Clients Function in...