The methodology is explained in [1] and is inspired from the "How do
BitTorrent block lists get created?" thread + some ideas of us.
The principles are simple, torrent-live does set an infohash that it is
the only one to know, announces it and register those that are
pretending to have it as spies. It does randomely change its nodeId to
explore different paths of the DHT, finally it does load the torrent by
connecting to the peers discovered through the search of its infohash
which has been chosen to be close to the real one, so it does not say
what real infohash it is looking for, except to the targeted peers, and
it does attempt to connect to only 20 peers until the swarm stabilizes
to this number.
In addition it does block the peers that seem not to behave normally,
like not responding to pieces requests or lately or wrongly, the
combination of all this + the total freeriding behavior (please see
previous email below) makes probably very difficult the tracking, but
the risk to connect to a spy is not null.
It's only using the DHT, not trackers.
While it was not obvious that there were some correlations between spies
monitoring real infohashes and spies monitoring infohashes close to
them, it appears that there is.
The experimentation is still ongoing, but first results show that for a
usual torrent (even not famous, not known or simply private) you get
something like 5000 spies quickly, then it seems to stabilize, things
change when you try a highly monitored torrent (like [2], which,
notwithstanding our opinion, just happened right in time for this
experiment), using the 'findspiesonly' option (ie not downloading the
torrents), the number of spies increased like crazy, first estimations
showed that at least one third of the peers in swarms are spies (+ those
that are not participating in swarms but are just monitoring). Probably
the spies are distributed in the DHT space (so a basic complete
hazardous thought would be that they are 5000*160) and come in renfort
when something has to be monitored strongly somewhere else, currently it
seems to stabilize around 60000 spies.
In the context of Peersm project, we are somewhere offloading the risk
to the ones who are bridging to the bittorrent network, even if they are
just relaying the data in an uncounscious way, not knowing for whom and
even if it is minimized by their total freeriding behavior, that's one
of the rationale of this experiment.
Another one, for those that could be allergic to freeriding, would be to
extend the bittorrent protocol so freeriding becomes unlikely at the
same time peers tracking becomes difficult, one of the ideas would be to
reuse some concepts used by Peersm, like thoses announcing they have
something don't have it but might know someone else who has it or who
might know someone else who might have it, then the data could be
relayed by different peers making difficult to know who has really the
content, the difference with the usual bittorrent protocol is that
(unlike Peersm project) peers would know each others, but in the process
one request can be relayed by a succession of peers, not only one, the
potential freeriders would be registered by others, not sure if this can
fly but thinking about it...
Regards,
[1] https://github.com/Ayms/torrent-live#findspies
[2]
http://torrentfreak.com/expendables-3-leaks-online-100k-copies-down-in-hours-140725/
Le 12/07/2014 00:11, Aymeric Vitte a écrit :
Le 11/07/2014 20:13, David Barrett a écrit :
Is it really freeriding?
Yes, totally, please see below.
I expect it does share as it downloads (I think it's impractical to
totally avoid it)
It does not share anything, just query the DHT and request pieces, do
not register in the DHT, do not advertise itself, do not say what is
has, do not answer to queries, and it's working very well, please just
try it.
, but it just doesn't seed after it finishes. Is that right?
It does not seed either unless you explicitely decide to do it.
If so I wouldn't call that freeriding: this is exactly what the
protocol was designed for. It's just not going beyond the minimum.
Accordingly, I'd suggest calling it "minimal sharing".
Apparently the protocol can not avoid this, for now that's not really
my focus but I would have some ideas how to make this total freeriding
more difficult.
That said, why configure the default to the minimum? Why not just
ship it with a 1.0x seed ratio target by default?
As I wrote, you can set the freerider option to false (in
freerider.js, but I can change this for a more accessible option), the
rationale for the freerider option is explained in this thread [1]
(adding the fact that you don't store anything which is not the case
for torrent-live), it was specific to the Peersm project, now maybe
it's giving me other thoughts how to go a bit further simply in
relative privacy/anonymity with torrent-live for usual torrents.
I just pretend here that you minimize your visibility, not at all that
you can not be tracked, what is more interesting is the live streaming
capabilities inside browsers (and TV), real privacy/anonymity for
torrents is the Peersm project.
And if you want to be totally visible, then, again, you can deactivate
the freerider option.
Regards
[1] http://lists.zooko.com/pipermail/p2p-hackers/2014-June/003272.html
David
On Jul 11, 2014 7:51 AM, "Aymeric Vitte" <[email protected]
<mailto:[email protected]>> wrote:
Here: https://github.com/Ayms/torrent-live
"Download and stream live (while the download is in progress)
torrents with your browser as a total freerider, send it to your TV"
This is based on small modifications of torrent-stream/webtorrent
modules.
The principle is simple: you open with your browser the file
being downloaded to stream it and you send it to your TV.
Initially the purpose was to have a complete freerider bittorrent
client for download/streaming (Peersm project) but it happens
that live streaming is working too, and quite well, apparently
with all usual audio/video formats.
It leaves me a little perplexed since the Media Source Extensions
API (used by Peersm) can not do this, unless you adapt on the fly
the format of the files.
If you don't like to be a freerider, you can deactivate the
option, and if you don't like the wording of the freerider
description then please suggest a better/more accurate one.
Comments/remarks welcome.
Regards,
--
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
_______________________________________________
p2p-hackers mailing list
[email protected] <mailto:[email protected]>
http://lists.zooko.com/mailman/listinfo/p2p-hackers
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
--
Peersm :http://www.peersm.com
node-Tor :https://www.github.com/Ayms/node-Tor
GitHub :https://www.github.com/Ayms
--
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
