Slashdot Mirror
Decentralize BitTorrent with Kenosis
UnderScan writes "Eric Ries, writer/programmer/CTO, authored an article 'Kenosis and the World Free Web' at Freshmeat [Owned by Slashdot's Parent OSTG]. Kenosis is described as a 'fully-distributed peer-to-peer RPC system built on top of XMLRPC.' He has combined his Kenosis with BitTorrent & removed the need for a centralized tracker. He states: 'To demonstrate Kenosis's suitability for these new applications, we have used it to improve upon another peer-to-peer filesharing application that Just Works: BitTorrent. BitTorrent does one thing incredibly well. Using a centralized "tracker," BitTorrent manages efficient distribution of data that is in high demand. We have extended BitTorrent, using Kenosis, to eliminate this dependence on a centralized tracker.'
See also the Kenosis README for details on using Kenosis-enabled BitTorrent."
n. Christianity
The relinquishment of the form of God by Jesus in becoming man and suffering death.
Thinkin' Lincoln - a web comic of presidential proportions
QUite useful, of course! We could distribute spatial-data, and Wi-Fi locations to PDAs and laptops in this way. There are metric tons of useful applications for BT and K.
Zhrodague.net - I do projects and stuff too.
One of the problems with BitTorrent is that the trackers themselves can get overloaded with too many clients. If this system can eliminate something like that happening then that'd definately be a good thing.
;)
That being said, the busiest torrents I've seen are for copyright-infringing material, so I guess it's still a boon for piracy.
"People that quote themselves in their signatures bother me" - athakur999
3 is "Get sued by MPAA anyway". Step 4 refers to the studios' profits.
Look, so long as the MPAA goons can trace at least one packet of a movie download to your IP address, you have liability. And with BT, as long as you're downloading, you're also uploading. Use torrent, and your ass is exposed, regardless of whether the index is centralized or decentralized. Call me paranoid, but that's how I look at it.
If I understand this correctly, this doesn't affect communication between the bittorrent peers, just the client and the tracker. It still won't work through an HTTP proxy.
Continuing reading, you can see that it's possible to directly have a torrent reference the network. The kenosisp2p.org bit is only for legacy clients that wouldn't know what to do with a "new" tracker location.
Omnes stulti sunt.
That is true, but you only need to ensure that the torrent you have is legit. Since the .torrent holds the checksums of the chunks, if a peer sends you garbaged data a couple of times then you can safely ignore it and move on, lookin' for other ones with the real data. MPAA would have to dump alot of bandwith to make it annoying enough, wich wouldn't be feasible, and even in such circumstance, it'd have to deal with the problem of being ignored after the clients realized it was sending false data.
You still have the problem with the MPAA/RIAA grabbing your IP, but that's another story...
Wrong! The DNS server is a hack. Normal bittorrent links lead directly to a tracker. Kenosis bittorrent links lead to HASH.their.server.name. BitTorrent-Kenosis clients will recognize this and use the network. The purpose of the DNS (and the reason it's not btkn://HASH or something) is that legacy clients going there will be given the IP of any Kenosis client that can act as a tracker for it. Killing that DNS would kill legacy clients but not the enhanced P2P ones.
Tired of free iPod sigs? Subscribe to my blacklist
Now we are just waiting for a platform-dependent implementation in C++ and MFC that is supposed to be faster because it's "native code", which all the clueless kids with 8mbit internet connections are going to download...
Even network-limited programs like a bt client still need to worry about GUI responsiveness and memory usage. It would be insane to write the first implementation of such a program in C/C++ -- Perl and Python were given to us by gods to prototype these sorts of projects -- but once the basic protocol and UI behavior has been figured out, I would try to rewrite the client in a statically compiled (or at least a JIT-capable) language.
RTFA and read it properly. The server is merely a pretty interface for older BT clients that will search the decentralised version and return the tracker address of the last known tracker for that item.
That's got nothing to do with the decentralised network itself.
I see several weaknesses in this, however. If I wanted to attack this, the route is pretty obvious to me. Several lines of attack stand out:
1: Start serving falsely-labelled file data that is correctly represented internally. There appears to be no moderation system built in, so bogus file data will pollute the system.
2: Start serving any file data that is inaccurately represented internally. For example, make all of your hash entries but one accurate, but make that one hash entry inaccurate. Users end up downloading most of the bad file before it errors out. Depending on the setup of the server and client, they may continue trying to get the data from elsewhere, in which case you could serve larger amounts of corrupted data, possibly by using bad clients working in conjunction.
3: Hash cracking: Brute force hash cracking could allow fake data to pass as real, hash-matching data; only a single cracked piece per file is needed. This would probably be economically inefficient, however, compared to #1 and #2 in terms of the ability to disrupt network usage.
4: Mass peer suits. If BT is the download manager here, getting the people who have the file being shared is laughably simple.
There's probably also some risks for their proposed change to allow multiple seeders, but I'd need to think about it for a while.
1, 2, and 3 require an "intelligent" client. In real life, we inherently weed out those who give bad data simply by our experiences and the experiences of those we know. The more we trust a person, the more we trust what they tell us about others. This sort of system tends to inherently isolate out the bad apples, even if they work together. Even if, working together, they manage to convince a good client that they're right and others are wrong, that good client too will simply be viewed as a liar and its data shunned. Overall, the system will remain intact. It's no easy programming task, however; yet, it is doable, as evidenced by the fact that we, as humans, do it every day.
#4 has a simple solution: Involuntary mirroring. If this system would automatically force the mirroring of data into a cache on the destination machine, and serve it from there, there would be no way to know whether a person was actually uploading copyrighted material or simply acting as a "router". Since our law has finally started to catch on to the fact that it is unreasonable to sue those whose computers pass through illegal data that they had no realistic way of knowing about, it would effectively anonymize *all* data on the network.
Hey, guys, I'm just pleased as punch to report that it's a fleet of a hundred Vogon Battle Destroyers!
The size of the application comes from one thing, wxWidgets which, you guessed it, is written in C++ and not python. The MacOS version runs directly on ObjectC and is much smaller. There might be a direct windows port, python can interface with the win32 api, check out venster. So now you have two options for reducing the size of bittorrent, get coding!
Obligatory rant: If you are tired of the BitTorrent community using python, then write it in another language and stop complaining, nothing in life is really for free.
(I am one of the authors of Kenosis.)
We are planning improvements to Kenosis in a number of areas such as better integration with BitTorrent, a more distributed BT tracker, simulation of larger Kenosis networks and making Kenosis work over NAT.
We'd love help with any of these or other areas.
Please join the mailing list to get involved.
We'd love to have your help making the software ready for primetime. Join our mailing list if you're interested.
Can your IM do this?
From what I understand, you're missing the point of Kenosis... the entire DNS thing is for reverse compatability. I can use Kenosis to get the .torrent file, OR I can use DNS to resolve the ip to get the file, either way I can download the .torrent file.
if the Kenosis DNS is taken down, we can still use Kenosis to get the torrent files, or at least that's what I understand.
test.py is designed to show the API working in various real-world situations. If you'd like to see a comprehensive set of tests that do not require any ports, please see:
kenosis/nodetest.py
Can your IM do this?
1: Start serving falsely-labelled file data that is correctly represented internally. There appears to be no moderation system built in, so bogus file data will pollute the system.
Can't be done. There is a moderation system built-in to BT. The SHA1 hashes which identify the file chunks simply cannot be 'correctly represented internally'. If you know a way of doing this without changing the chunk size by several gigabytes, I think some crypto researchers would like to talk to you.
Any reasonably coded client will start ignoring a peer who delivers enough bad chunks.
For example, make all of your hash entries but one accurate, but make that one hash entry inaccurate. Users end up downloading most of the bad file before it errors out.
Which will leave you with no 'seeds' but the original one. People would wise to this quickly.
Hash cracking: Brute force hash cracking could allow fake data to pass as real, hash-matching data; only a single cracked piece per file is needed.
See above. This is nowhere near practically possible. You have to add gigabytes of data. A chunk is far smaller than that. It won't fly.
#4 has a simple solution: Involuntary mirroring. If this system would automatically force the mirroring of data into a cache on the destination machine, and serve it from there, there would be no way to know whether a person was actually uploading copyrighted material or simply acting as a "router".
This would not work. First, most net users have lower upload speeds than download speeds. Second, and more important is that this requires a lot of bandwith for helping someone else. Expect a hacked client to be produced which does not proxy anyone else, saving their bandwidth, but leeching others'. You could create a tit-for-tat scheme where someone will only proxy for you if you proxy for them. On the other hand, bandwidth is still the main constraint here.
And because some people won't get it, this Informative post will explain.
;-) 3.11 was a hacked version of the Microsoft MPEG 4 layer 2 codec used for .asf files. A french hacker, Jerome Rota, extracted this codec and made it work for .avi files.
DivX
Wikipedia seems to skip a bit of history here, not mentioning the cracking of the sound codec etc, but does conclude with the information on "DivXNetworks, Inc" creating a Clean room design version of DivX (similar, in my opinion, to editing someone elses paper enough to make it not technically plagarism) and releasing it as DivX 4.
For context, click Parent.