Professional Documents
Culture Documents
http://hireme.geek.nz/bt-usability-fixes-needed.html
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
http://hireme.geek.nz/bt-usability-fixes-needed.html
12 Dec 15 18:37
http://hireme.geek.nz/bt-usability-fixes-needed.html
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.
3 of 28
12 Dec 15 18:37
4 of 28
http://hireme.geek.nz/bt-usability-fixes-needed.html
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" (###)
12 Dec 15 18:37
http://hireme.geek.nz/bt-usability-fixes-needed.html
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
5 of 28
12 Dec 15 18:37
http://hireme.geek.nz/bt-usability-fixes-needed.html
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.
6 of 28
12 Dec 15 18:37
http://hireme.geek.nz/bt-usability-fixes-needed.html
7 of 28
12 Dec 15 18:37
http://hireme.geek.nz/bt-usability-fixes-needed.html
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]
8 of 28
12 Dec 15 18:37
http://hireme.geek.nz/bt-usability-fixes-needed.html
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
http://hireme.geek.nz/bt-usability-fixes-needed.html
Protocol Version
Status
DHT
2014aa
OFF
2013ce
ON
Peer Exchange
2013gv
ON
Tracker Exchange
2015aa
GTG
Update In
Seeds Peers
Downloaded
Blocked
Spoofed
{Tracker List}
10 of 28
12 Dec 15 18:37
11 of 28
http://hireme.geek.nz/bt-usability-fixes-needed.html
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.
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
http://hireme.geek.nz/bt-usability-fixes-needed.html
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.
12 of 28
12 Dec 15 18:37
http://hireme.geek.nz/bt-usability-fixes-needed.html
A solution
13 of 28
12 Dec 15 18:37
http://hireme.geek.nz/bt-usability-fixes-needed.html
14 of 28
12 Dec 15 18:37
http://hireme.geek.nz/bt-usability-fixes-needed.html
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)
15 of 28
12 Dec 15 18:37
http://hireme.geek.nz/bt-usability-fixes-needed.html
Dummy
Traffic
Bad
Packets
Rekey
Events
Psudo-wire 22m
413kb
4852kb
37kb
24kb
1.25%
Tinc
31m
10
1572kb
7243kb
63kb
44kb
1.99%
...
...
...
...
...
...
...
...
...
...
16 of 28
12 Dec 15 18:37
http://hireme.geek.nz/bt-usability-fixes-needed.html
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
17 of 28
12 Dec 15 18:37
http://hireme.geek.nz/bt-usability-fixes-needed.html
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
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
The pipeline for the transmission of a file segment with Error Correction added :
18 of 28
12 Dec 15 18:37
http://hireme.geek.nz/bt-usability-fixes-needed.html
19 of 28
12 Dec 15 18:37
20 of 28
http://hireme.geek.nz/bt-usability-fixes-needed.html
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
http://hireme.geek.nz/bt-usability-fixes-needed.html
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
12 Dec 15 18:37
http://hireme.geek.nz/bt-usability-fixes-needed.html
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
http://hireme.geek.nz/bt-usability-fixes-needed.html
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.
23 of 28
Notes
12 Dec 15 18:37
http://hireme.geek.nz/bt-usability-fixes-needed.html
VPN Preferences
Have-all or Have-none
Have-bitfield
Have-bitfield-4bit
Cryptography settings
Partial-have-4bit-quantizeddatabase
Pause State
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
...
...
...
...
...
...
Friendlyname-Unicode-UTF16
Friendly-name long
ADDENDUM
24 of 28
12 Dec 15 18:37
http://hireme.geek.nz/bt-usability-fixes-needed.html
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 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
http://hireme.geek.nz/bt-usability-fixes-needed.html
"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
http://hireme.geek.nz/bt-usability-fixes-needed.html
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/ )
27 of 28
12 Dec 15 18:37
http://hireme.geek.nz/bt-usability-fixes-needed.html
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
06 September
2013
21 September
2015
0.87a
Revision state
Revisable,
Updatable
12 Dec 15 18:37