December 4, 2009  
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31


NOTICE: This channel is no longer actively logged.

[00:40:34] *** bbelt16ag has quit IRC
[01:09:41] *** goussx has quit IRC
[01:11:41] *** HandheldPenguin is now known as HandheldPenguin`
[01:14:08] *** goussx has joined #bittorrent
[01:31:45] *** mxs has quit IRC
[01:33:04] *** mxs has joined #bittorrent
[01:41:14] *** ajaya has joined #bittorrent
[01:49:43] *** mxs has quit IRC
[01:50:07] *** mxs has joined #bittorrent
[02:04:00] *** ajaya_ has joined #bittorrent
[02:09:52] *** ajaya has quit IRC
[02:09:52] *** ajaya_ is now known as ajaya
[02:16:09] *** GTHK has joined #bittorrent
[02:21:31] *** yehaT has joined #bittorrent
[02:22:27] <yehaT> Hey. Does anyone know of a torrent client that can also act as hybrid client/remote-controllable server for another copy of the hybrid client running on another computer?
[02:23:07] <yehaT> I'd like to be able to run the dedicated client on computer that's always running, connected and use wire
[02:23:27] <yehaT> and the controlling client on a wifi connected computer that's not up always.
[02:24:03] <DeHackEd> torrentflux? web interface in front of bittornado
[02:24:05] <yehaT> Without sacrificing speed or usability of locally running client (= no web browser clients)
[02:24:27] <yehaT> Silverlight implemented web client would be ok though
[02:24:50] <DeHackEd> command line client of your choice on top of screen?
[02:25:47] <yehaT> Can you recommend some? I'd like the controlling client to be able to get the .torrent/magnet clicks from my browser
[02:26:02] <yehaT> and passing that to the remotable client as described
[02:27:43] <yehaT> Ideally I would have some remotable version of the utorrent. So I started up utorrent, click Logon, check login-automatically box, then enter host/cred of another computer running utorrent and use the remote utorrent as if it was native & local.
[02:29:16] <yehaT> Now if the more dedicated computer was a server then I could get something like that with remote desktop
[02:30:20] <DeHackEd> depends on the OS. Linux makes no distinction between desktop and server roles. Windows XP does have remote desktop support.
[02:30:23] <yehaT> Since it's also being used for gaming occasionally by the owner it's not really ideal to demand running a server OS there..
[02:31:09] <yehaT> or generally demand anything special beside sharing the utorrent. Like virtual machines and the kind..
[02:32:12] <yehaT> (not that I'd demand anything, just thinking of possible solutions at this point that were better than WebUI)
[02:33:39] <yehaT> The setup is practically two windows desktop with shared net: I setup him with the more powerful computer and dedicated link as he want to run 24/7 anyway and I don't.
[02:34:04] <yehaT> So really I want to preserve the 2 desktops setups and just share one utorrent
[02:34:09] <yehaT> it also solves the current problem
[02:34:24] <yehaT> where we are running 2 native utorrents and it causes line contention
[02:34:58] <DWKnight> that would likely happen with any client
[02:35:43] <yehaT> indeed, that's why the remotable utorrent (webui without the web browser or javascript) seems ideal.
[02:36:30] <yehaT> If utorrent had a nice API built for this instead of a web server then one could whip up it in silverlight
[02:36:48] <DWKnight> ok, I should punch you in the face for that
[02:36:56] <DWKnight> http://forum.utorrent.com/viewforum.php?id=20
[02:37:04] <DWKnight> for two reasons
[02:37:17] <DWKnight> 1> assuming that the webui we provide is the ONLY way to remote uT
[02:37:22] <yehaT> hmm "uremote" cool
[02:37:22] <DWKnight> 2> working in silverlight
[02:37:35] <yehaT> I only googled this and didn't find that..
[02:37:47] <yehaT> Guess my bad for not going through the forums properly I'm sorry
[02:38:25] <yehaT> What's wrong with silverlight?
[02:38:40] <yehaT> Beside the MS-argument
[02:38:50] <yehaT> which is not relevant to me :)
[02:39:37] <DWKnight> immature tech compared to what's already out there
[02:41:31] <yehaT> TBH I admit, I can't immediately answer I'd do the "pass torrent/url" to the silverlight bit
[02:41:59] <yehaT> how..
[02:42:21] <yehaT> So it might not end up being that much better than webui
[02:42:24] <yehaT> if that's a requirement
[02:43:11] <yehaT> Anyway I'll give a shot to Uremote, thanks very much
[02:47:48] *** MobileDe has joined #bittorrent
[03:01:20] *** yehaT has quit IRC
[03:02:13] *** GTHK has quit IRC
[03:02:40] *** GTHK has joined #bittorrent
[03:23:45] *** bittwist has joined #BitTorrent
[03:38:14] *** GTHK has quit IRC
[03:38:37] *** GTHK has joined #bittorrent
[04:02:52] *** ajaya has quit IRC
[04:03:30] *** ajaya has joined #bittorrent
[04:05:16] *** ajaya has quit IRC
[04:05:28] *** The_8472 has quit IRC
[04:05:49] *** wadim has joined #bittorrent
[04:05:51] *** wadim is now known as The_8472
[04:14:17] <burris> lots of bad press about twitter "fail whale" so they fixed it so your search just times out
[04:14:30] *** GTHK has quit IRC
[04:15:48] <The_8472> i'd rather prefer the fail whale...
[04:16:05] <The_8472> *shoots marketing people*
[04:20:40] <burris> i'm lusting for one of these http://www.sonosax.ch/recorders/minir82/minir82_index.html
[04:21:17] <burris> good for making torrents!
[04:24:10] *** goussx has quit IRC
[04:27:29] *** GTHKn has joined #bittorrent
[04:32:36] <burris> haha I'm watching a concert live at MSG on the other side of the continent via some douchebag holding up his cellie
[04:32:47] <TheSHAD0W> @__@
[04:33:35] <burris> me and 1650 others
[04:33:41] <The_8472> that must provide you with some overwhelming video quality, a steady picture and probably audio worthy of a skywalker sound system ^^
[04:33:44] <MobileDe> wow, cellular's pretty good
[04:35:28] <burris> when it isn't buffering the audio is enough to follow the jam, hear if its good or not... you can wait a few hours to download higher quality later...
[04:38:28] <burris> they clearly need some k-rad p2p live streaming tech
[04:39:33] <The_8472> i'm not sure if i have ever mentioned it in this channel, but IP-multicast might be excellent for situations like these
[04:40:00] <burris> except that it doesn't work
[04:41:36] <The_8472> technically it does
[04:41:52] <burris> ip multicast would be a great replacement for bittorrent if bittorrent wasn't a replacement for ip multicast
[04:42:37] <The_8472> ip multicast would perform better than bittorrent, so it's more of a makeshift replacement
[04:43:25] <Switeck> And if someone misses packets using ip multicast? what's the fallback plan?
[04:43:33] <burris> FEC
[04:43:57] <The_8472> a) you can loop through finite content
[04:44:08] <The_8472> b) you can have multiple sources at different offsets
[04:44:17] <Switeck> 'finite' doesn't work well if it's >10 GB
[04:44:20] <The_8472> c) you can fill gaps with unicast if all else fails
[04:44:24] <Switeck> and on typical consumer lines
[04:44:32] <The_8472> multiple sources...
[04:44:39] <The_8472> that way your entire download will be maxed out
[04:45:42] <The_8472> 10x 10/1 domestic connections sending via SSM allows a basically unbounded number of people to download at 10Mbit.... and that unbounded number of people can share among each other too, either via unicast or even more multicasting
[04:45:51] <The_8472> basically bittorrent on crack and steroids
[04:46:14] <Switeck> ISPs would hate it XD
[04:46:30] <The_8472> it would reduce upload and transit traffic
[04:46:54] <Switeck> it certainly would for large "torrents"
[04:47:02] <Switeck> for small ones, maybe not so much.
[04:47:14] <Switeck> but what I don't get...
[04:47:24] <The_8472> those are mostly transit anyway.
[04:47:32] <The_8472> multicast can still prevent redundant uploading
[04:47:44] <Switeck> At what point does the single multicast transmission get spread into multiple packets (per packet)?
[04:47:52] <The_8472> 1 person uploads, everyone gets it at once. so only one ISP feels the upload so to speak
[04:48:00] *** goussx has joined #bittorrent
[04:48:08] <The_8472> that depends on where your multicast-capable routers are located
[04:48:23] <Switeck> Doesn't that 1 ISP have to peer through multiple points to reach other ISPs?
[04:49:05] <The_8472> yes, but the last mile wouldn't be concerned by this.
[04:49:43] <Switeck> Ok, last mile -- assume what you're sending is going to 10 ADSL neighbors.
[04:50:15] <The_8472> with normal bittorrent i'd have to upload it 10 times or my neighbors would have to do uploading too
[04:50:42] <Switeck> Does the DSLAM retransmit to each 10 or does the traffic have to "crawl" further up the line, THEN split into 10 and come back down?
[04:50:56] <The_8472> with multicast either it's just me doing the uploading once. all 11 of us upload and everyone gets the traffic, thus can max out their download instead of being limited by the upload
[04:51:46] <The_8472> that is an excellent question, which i cannot answer due to lack of knowldge concerning internet/isp infrastructure
[04:52:27] <The_8472> but it shouldn't matter. You'll always save traffic along some edges. maybe not all of them, but at least some of them
[04:52:34] <Switeck> the transit between the DSLAM and other parts of ADSL infrastructure can be as bottlenecked as cable's individual channels :(
[04:53:00] <The_8472> http://upload.wikimedia.org/wikipedia/commons/1/1d/Multicast_vs_broadcast_illustrated.svg <-
[04:55:46] <Switeck> ISPs would likely resist multicast unless forced...and then maybe only inside their ISP...due to them thinking it'd increase people's usage immensely.
[04:56:44] <The_8472> well, it would make mass distribution scale even better than with bittorrent, so yeah... i guess people would share even more
[04:57:29] <Switeck> it'd mean more people would have their download maxed out constantly while file sharing.
[04:57:40] <The_8472> but it would finally break the 1 bit uploaded = 1 bit downloaded constraint
[04:57:43] <burris> I'm pretty sure this guy has his camera/phone clamped onto the rail
[04:58:00] <Switeck> as-is, I'd say it's abnormal to have one's download maxed out for days on end...unless the line's really slow. :P
[04:58:29] <The_8472> oh, i know people who do. and if their download isn't maxed out for once then their upload still is
[04:58:31] <Switeck> it's actually more like 1 bit uploaded = 0.9x bits downloaded right now
[04:58:53] <Switeck> upload yes, but download max 24/7...probably not
[04:59:07] <Switeck> It gets a lot harder the faster the line.
[04:59:19] <Switeck> unless you really are just downloading to say you are
[05:01:26] <The_8472> well, and why would that change?
[05:02:19] <The_8472> well, i guess people could suddenly start uploading videos only in HD quality, multi-GB files instead of downsized stuff
[05:02:36] <The_8472> *eyes some 1080p bluray torrents*
[05:08:47] <Switeck> instead of people downloading ~100 GB a month, they might start doing that in a couple days
[05:10:17] <The_8472> well, they already can do that right now, there are just fewer services that actually provide enough content to do it in a sensible way
[05:11:15] <Switeck> correct
[05:11:33] <Switeck> right now, it's a hard-fought luxury still to manage 100 GB in 2 days
[05:12:00] <Switeck> maybe with a few HD movie torrents, sure...but they'll need to be seeded by 100 mbit/sec seedboxes.
[05:12:36] * The_8472 sets up a script that loops through all known linux mirror and downloads .iso files continously
[05:12:46] <The_8472> *mirrors
[05:13:43] <Switeck> the irony of private trackers is...with consumer lines you can't just download at those super speeds for days, you'd murder your ratio.
[05:14:36] <The_8472> ah yes, something else that would finally go away
[05:16:33] <Switeck> nope
[05:16:35] <Switeck> they wouldn't
[05:16:45] <Switeck> people would still go there to be "safe"
[05:17:11] <The_8472> nah, they don't. they go for whatever is fast
[05:17:42] <Switeck> there's people who believe the scammers about "legally download music and movies"
[05:17:46] <The_8472> and private trackers are perceived to be faster, due to all the overseeding
[05:18:07] <The_8472> m'kay. but then i wouldn't count those as private trackers
[05:19:26] <Switeck> the "private" part
[05:34:18] *** Miller` has joined #bittorrent
[05:40:57] *** The_8472 has quit IRC
[05:46:46] *** Gottaname has joined #bittorrent
[05:54:43] *** ProperNoun has joined #bittorrent
[06:01:17] *** bbelt16ag has joined #bittorrent
[06:07:41] *** PN has quit IRC
[06:34:25] *** GTHKn is now known as GTHK
[06:42:58] *** KyleK_ has joined #bittorrent
[06:45:39] *** _rafi_ has joined #bittorrent
[07:00:42] *** MassaRoddel has quit IRC
[07:06:29] *** KyleK_ has quit IRC
[07:19:10] *** MassaRoddel has joined #bittorrent
[07:40:13] *** Firon has quit IRC
[07:45:39] *** GTHK has quit IRC
[07:46:49] *** GTHK has joined #bittorrent
[08:20:44] *** rrr_ has quit IRC
[08:22:14] *** stalled has quit IRC
[09:10:50] *** GTHK has quit IRC
[09:15:17] *** GTHK has joined #bittorrent
[09:29:53] *** stalled has joined #bittorrent
[09:40:13] *** GTHK has quit IRC
[09:41:26] *** rrr has joined #bittorrent
[10:01:00] *** rrr has quit IRC
[10:01:33] *** Switeck has quit IRC
[10:13:58] *** Andrius has joined #bittorrent
[10:14:47] *** bt42 has joined #BitTorrent
[10:20:25] *** stalled_ has joined #bittorrent
[10:22:11] *** bittwist has quit IRC
[10:22:41] *** stalled has quit IRC
[10:25:56] *** stalled_ is now known as stalled
[10:40:49] *** goussx_ has joined #bittorrent
[10:56:55] *** goussx has quit IRC
[10:56:56] *** goussx_ is now known as goussx
[11:17:10] *** mxs has quit IRC
[11:21:09] *** rrr_ has joined #bittorrent
[11:21:18] *** Gottaname has quit IRC
[11:21:50] *** Gottaname has joined #bittorrent
[11:22:27] *** mxs has joined #bittorrent
[11:43:33] *** swinokur has quit IRC
[12:24:24] *** HandheldPenguin` is now known as HandheldPenguin
[12:25:16] *** zonk9d has joined #bittorrent
[12:25:56] <zonk9d> hello all
[12:26:41] <zonk9d> anyone here knows how transmission works internally ?
[12:27:01] <zonk9d> i mean is anyone comfortable with code
[12:27:48] *** swinokur has joined #bittorrent
[12:28:59] *** The_8472 has joined #bittorrent
[13:18:43] *** zonk9d has left #bittorrent
[13:41:22] *** bittwist has joined #BitTorrent
[13:59:59] *** bt42 has quit IRC
[14:19:38] *** Elrohir has joined #bittorrent
[14:41:08] *** The_8472 has quit IRC
[14:41:29] *** wadim has joined #bittorrent
[14:41:31] *** wadim is now known as The_8472
[15:57:03] *** dandon has joined #bittorrent
[15:58:35] <dandon> i have a question. what if someone creates a torrent and i announce it on a different tracker then the ones that came in the torrent... if it does when will it take over only when someone connects through that tracker?
[15:58:46] <dandon> private flag isn't set
[15:59:50] *** ChoyKloun has joined #bittorrent
[16:00:00] <ChoyKloun> sup everyone
[16:00:12] <The_8472> dandon, they may find you via dht then
[16:00:14] <ChoyKloun> im considering to submit a proposal for obfuscation/encryption of DHT traffic.. any thoughts on this ?
[16:00:45] <ChoyKloun> the design is currently mostly in my head so i wanna know if its an utterly stupid idea before taking the time .. :)
[16:00:56] <ChoyKloun> would be designed to make all traffic appear totally random to a passive listener
[16:01:11] <ChoyKloun> and use curve25519 for key exchange
[16:01:45] <ChoyKloun> which is extremely fast and the public values are just 32 bytes
[16:01:47] <dandon> oh The_8472 from vuze :). yes but no
[16:02:03] *** rrr_ has quit IRC
[16:02:18] <dandon> oh right sec
[16:02:39] <ChoyKloun> as a bonus it solves any issues arising from spoofed dht queries :)
[16:04:25] <dandon> oh now i understand
[16:05:00] <dandon> The_8472: isn't there a way for vuze ifi the torrent is on queue to let me be in there as seed?
[16:05:06] <dandon> is this controlled by
[16:05:27] <dandon> disconnect seeds when seeding?
[16:05:31] <The_8472> huh?
[16:05:59] <dandon> look
[16:06:16] <The_8472> at what?
[16:08:17] <The_8472> just tell me what you want it to do
[16:16:05] <dandon> no ok i got my answer
[16:17:55] <The_8472> not sure why you're using notices, but there's a reason to disconnect seeds while seeding... you have no use for them and they have no use for you
[16:19:12] <dandon> but if i'm in queue i won't get count as a seed... if i understand it correctly
[16:19:19] <dandon> =notices . yea i don't know...
[16:19:34] <dandon> i'm in queue = the torrent is in vuze
[16:19:44] <The_8472> then you're not understanding correctly, no ^^
[16:19:58] <dandon> i have tried it with torrenteditor.com
[16:20:02] <dandon> try it yourself
[16:20:08] <The_8472> what you want is the torrent to be started
[16:20:10] <dandon> you will need to find a torrent where you are alone
[16:20:14] <The_8472> instead of queued
[16:20:18] <dandon> no
[16:20:18] <The_8472> which has nothing to do with that setting
[16:20:30] <dandon> i want to get count as a seed by the tracker
[16:20:40] <The_8472> to do that you have to start the torrent
[16:20:44] <dandon> even though the torrent isn't active per se
[16:20:49] <dandon> it is but in queue
[16:20:58] <The_8472> you can't have it both ways
[16:21:10] <dandon> according to torrenteditor.com
[16:21:15] <dandon> just tell me what you think i mean
[16:21:37] * dandon please
[16:21:39] <The_8472> so you want to appear as 1 seed  on the tracker scrapes
[16:21:59] <dandon> as a seed. yes...
[16:22:46] <The_8472> to do that the torrent can't be queued
[16:22:55] <The_8472> it must be started/seeding
[16:23:34] <dandon> i see
[16:23:54] <dandon> so there is no way for me to announce myself as a seed if the torrent is in queued state?
[16:24:08] <dandon> =100%
[16:24:25] <The_8472> uhm
[16:24:28] <The_8472> start it?
[16:24:31] <The_8472> like... force start?
[16:24:40] <The_8472> or stop downloading torrents and let it seed instead
[16:24:48] <The_8472> or adjust your seeding queue rules
[16:25:05] <The_8472> where did you get the idea that 100% = queued....
[16:25:43] <dandon> no i understand now.
[16:25:57] <The_8472> you said that before
[16:26:04] <dandon> i meant i have a full torrent (100%)
[16:26:09] <dandon> no but now i mean it ^^
[16:26:44] <The_8472> being 100% does not imply queued state
[16:27:09] <dandon> but i guess it means seed...
[16:27:20] <dandon> no just within the swarm
[16:28:08] <The_8472> 100% means you can seed it. but you only do so if it's in the seeding-state
[16:28:29] <The_8472> queued means some other torrent is active, either downloading or seeding
[16:28:33] <The_8472> or it falls under the ignore rules
[16:33:20] <dandon> i was just talking about seeding. and afaik you are only listed as seed if you have the whole torrent
[16:33:27] * dandon lol forgot to press enter
[16:33:53] <The_8472> on the tracker?
[16:34:39] <dandon> yes
[16:35:02] <The_8472> then the answer is no
[16:35:21] <The_8472> you're not listed on the tracker as seed just because you have the complete torrent
[16:35:34] <The_8472> it must be unqueued too
[16:35:44] <The_8472> otherwise you would be of little use
[16:38:07] <dandon> what? sec
[16:38:23] <dandon> ? so if i have a torrent and downloaded it to let say 30% (~10 files) the rest of the files flagged as 'do not download' vuze ergo the tracker marks me as seed?
[16:38:44] <The_8472> no
[16:39:00] <The_8472> you're talking about a special case
[16:39:04] <dandon> that is what i meant. you are only seed if you have 100%...
[16:39:04] <The_8472> while you seem to have the basics wrong
[16:39:17] <The_8472> no
[16:39:31] <The_8472> you're not listed as a seed on the tracker just because you have 100%
[16:39:41] <dandon> yes but if i'm seeding
[16:39:46] <The_8472> then yes
[16:40:18] <dandon> and that is what i meant earlier and now i know that you have got me
[16:40:32] <The_8472> you were talking about the queued state
[16:40:33] <dandon> so there is no way of telling the tracker i _could_ be as 100% seed
[16:40:44] <dandon> yes if you will
[16:40:54] <dandon> ^> no. YES
[16:41:11] <dandon> as 100% = a 100%
[16:41:24] <TheSHAD0W> ...
[16:41:27] <The_8472> you're not making sense, at all
[16:41:37] * dandon hehehe. soz
[16:41:48] * dandon farnsworth: oohhhh myyyy
[16:43:15] <TheSHAD0W> dandon: While some private trackers have gotten stupid in modifying their operation, the purpose of a tracker is just to collect statistics and connect you to other peers.
[16:43:44] <TheSHAD0W> If you're not connecting to peers, the tracker doesn't need or want to know about you.
[16:49:03] <dandon> yes TheSHAD0W. no.
[16:49:55] * dandon was thinking
[16:50:08] <dandon> no ok. thank you both for the time. The_8472, TheSHAD0W
[16:59:37] <dandon> what could be the reason a torrent gets rejected by a tracker?
[16:59:40] <dandon> public
[17:01:42] <The_8472> rejected? where and with what reason?
[17:04:06] <ChoyKloun> any comments regarding encryption of DHT ?
[17:04:23] <The_8472> i'm not sure if adding asymmetric crypto is such a good idea
[17:04:41] <ChoyKloun> because...?
[17:04:51] <The_8472> overhead in packet size and cpu time
[17:05:20] <ChoyKloun> packet size: 32 bytes extra in both directions once per session
[17:05:27] <ChoyKloun> cpu time: curve25519 is fast as fuck
[17:05:27] <The_8472> session?
[17:05:30] <The_8472> there are no sessions
[17:05:34] <ChoyKloun> ya
[17:05:41] <ChoyKloun> but obviously a sort of session system would be used for the crypto
[17:05:49] <ChoyKloun> not affecting DHT itself
[17:05:51] <ChoyKloun> just to keep state and keys
[17:06:02] <dandon> tbp linkage ok? The_8472
[17:06:07] <dandon> Error (Requested download is not authorized for use with this tracker.)
[17:06:30] <The_8472> so, that happens in your client?
[17:06:37] <dandon> i'm not sure if torrage has to do with anything but...
[17:06:41] <dandon> vuze yes
[17:06:45] <dandon> publict is ok
[17:06:56] <dandon> *bt
[17:07:01] <The_8472> then the tracker does not accept arbitrary infohashes
[17:07:11] <dandon> it's openbt
[17:07:35] <dandon> just this torrent. the first time i got it
[17:08:05] <The_8472> well, they could have blacklisted the torrent
[17:08:26] <The_8472> anyway, that's an error message from the tracker
[17:08:27] <dandon> i see
[17:08:36] <dandon> yes i realize that
[17:08:36] <ChoyKloun> the_8472: for encryption something like ipaddr+random session ID would be used to ID the 'session'
[17:09:01] <The_8472> so, that would make it stateless at least
[17:09:08] <ChoyKloun> huh
[17:09:18] <The_8472> since you can generate the session ID
[17:09:29] <ChoyKloun> crypto would be stateful obviously, thats the whole point of having the session mgmt
[17:09:34] <The_8472> but a key exchange with every packet is way too costly
[17:09:46] <ChoyKloun> thats why you use sessions
[17:10:05] <dandon> right forgot
[17:10:10] <The_8472> with find_node or find_peer queries you're contacting 100s of nodes you've never seen before
[17:10:16] <ChoyKloun> ya
[17:10:19] <ChoyKloun> obviously you need some intelligence
[17:10:37] <ChoyKloun> but doing a large amount of curve25519 exchanges isnt a major cpu hog
[17:10:43] <The_8472> you would have to do 100s of exchanges with every lookup
[17:10:52] <The_8472> embedded systems?
[17:11:04] <ChoyKloun> see 'need some intelligence' :)
[17:11:22] <ChoyKloun> and maybe some margin note saying 'not mandatory'
[17:11:40] <The_8472> there is no intelligence involved in contacting 100s of nodes you have never seen before and thus cannot have exchanged some keys with
[17:12:13] <dandon> the weird thing is vuze doesn't jump to the next tier if it gets the message
[17:12:16] <ChoyKloun> with intelligence i mean that it wouldn't establish key exchange with every single node it ever talks to, unless you tell it to
[17:12:53] <ChoyKloun> unless this sounds like an utterly stupid idea from start to finish i'll try implementing it in my client and see how much of an overhead it is under actual load
[17:13:02] <dandon> i've been downloading with dht yesterday and it was painfully slow and i just connected to 1/3 of the seed. others trackers 3xx or 2xx seeds and peers. The_8472
[17:13:51] <The_8472> uhm... you're not supposed to connect to all seeds
[17:13:58] <The_8472> and pex should do the rest
[17:14:06] <dandon> yes but here no iti didn't
[17:14:18] <dandon> i have now 12 seeds
[17:14:31] <The_8472> sounds like a rather small torrent
[17:14:37] <dandon> if i connect to inferno i get 300 seeds
[17:14:50] <dandon> it's die hard quadr.
[17:15:03] <The_8472> the seed count in the swarm != seeds connected
[17:15:09] <dandon> h3q.com isn't working either
[17:15:21] <ChoyKloun> the_8472: so does it sound non-stupid enough to try implementing ?
[17:15:40] <ChoyKloun> or should it be sent to the graveyard of ideas
[17:15:47] <dandon> seeds connected where?
[17:15:49] <The_8472> ChoyKloun, i would say it needs to be spelled out and reviewed first. we talk about things before implementing them.
[17:15:58] <dandon> you can try it yourself if you want to... The_8472
[17:16:02] <ChoyKloun> ya was gonna implement it to see real-life performance issues
[17:16:23] <The_8472> dandon... to you of course -.-
[17:16:32] <The_8472> the seed count on the tracker hardly matters to you
[17:17:08] <ChoyKloun> but in any case curve25519 is VERY fast
[17:17:26] <ChoyKloun> http://cr.yp.to/ecdh.html
[17:17:43] <ChoyKloun> http://cr.yp.to/ecdh/curve25519-20060209.pdf
[17:17:43] <The_8472> i'm familiar with the basics of ECC
[17:17:51] <ChoyKloun> D. J. Bernstein. Curve25519: new Diffie-Hellman speed records.
[17:18:39] <ChoyKloun> this is actual perforamnce values for this specific impl
[17:19:15] <dandon> bottom line is vuze tries it with dht if the first tier fails. with the above error message
[17:19:36] <dandon> as it doesn't happen too often (first time for me) i don't care
[17:19:37] <The_8472> ah well, you could try the mldht plugin too
[17:19:45] <dandon> aha
[17:20:16] <dandon> ah ok mainline
[17:20:28] <ChoyKloun> My software computes Curve25519 in just 832457 CPU cycles on a Pentium III, 957904 cycles on a Pentium 4, 640838 cycles on a Pentium M, and 624786 cycles on an Athlon.
[17:20:42] <ChoyKloun> Each of these numbers is a new speed record for high-security DH.
[17:21:03] <The_8472> how does it compare to aes?
[17:21:13] <ChoyKloun> uhm it does an entirely different thing than AES ?
[17:21:20] <ChoyKloun> what we're doing here is key exchange
[17:21:22] <ChoyKloun> not encryptin
[17:21:39] <ChoyKloun> well same algorithm can be used for asymmetric encryption also but invoked in a different way obviously
[17:22:03] <ChoyKloun> same basic math operation can do kex, asym crypto, signing, etc
[17:22:27] <ChoyKloun> but any comparisions should obviously be with regular diffie-hellman
[17:23:07] <ChoyKloun> (as in y=g^x mod p; z=y'^x mod p)
[17:23:17] <ChoyKloun> which unlike curve25519 requires bignum
[17:23:22] <The_8472> ... i know what DH does
[17:23:36] <The_8472> 1 AES block vs. 1 ECDH exchange
[17:23:45] <The_8472> i just want to know the overhead
[17:24:00] <The_8472> since we'd have to do both anyway
[17:24:06] <ChoyKloun> ah k
[17:24:24] <ChoyKloun> i understand
[17:25:21] <The_8472> too bad it's 32bytes, not 20
[17:25:32] <The_8472> otherwise we could generate node IDs from private keys and use them for exchanges ^^
[17:26:37] <ChoyKloun> it could use the node id as a secret value actually
[17:26:47] <ChoyKloun> just pad/hash it :)
[17:27:00] <ChoyKloun> that way you would automatically know the key if you know the node id..
[17:27:24] <ChoyKloun> and also have the option to make it more secure for users that want since you have 12^8 bits of extra entropy
[17:27:28] <The_8472> well, in that case you could just do symmetric encryption
[17:27:48] <The_8472> the question is if that's sufficient for our threat model
[17:27:59] <ChoyKloun> ya kinda but it provides a nice way of doing it
[17:28:03] <ChoyKloun> and it also makes sniffing more difficult
[17:28:30] <ChoyKloun> as its more costly to do curve25519 on thousands of exchanges than doing just aes
[17:28:32] <The_8472> speaking of which, we should define our threat model first
[17:28:39] <ChoyKloun> ya
[17:28:49] <ChoyKloun> threat model im thinking of is primarily blocking/manipulating the traffic
[17:30:39] <The_8472> ok, so they shouldn't be able to intercept messages and replace them with their own
[17:31:10] <ChoyKloun> kinda like that
[17:31:17] <ChoyKloun> mostly concerned with isps who try to block all dht traffic
[17:31:27] <ChoyKloun> because of censorship and/or bandwidth conservation
[17:31:50] <ChoyKloun> first is certainly relevant, i know from insiders that a majority of the traffic blocked in china is BT announce requests..
[17:32:09] <ChoyKloun> but DHT remains functional ... for now
[17:32:45] <The_8472> well,if mere obfuscation is required we need to do far less
[17:33:03] <The_8472> securing it against manipulation on the other hand...
[17:35:15] *** Elrohir has quit IRC
[17:35:18] <ChoyKloun> incidentally curve25519 can also do signatures :)
[17:35:28] <ChoyKloun> (or we acn just do HMAC based on the secret key)
[17:38:38] *** andar2 has joined #bittorrent
[17:38:44] <ChoyKloun> like hash the curve25519 output once to get encryption key, twice to get hmac key
[17:39:16] <ChoyKloun> anyways i do think that a normal node could do curve on ALL exchanges
[17:39:24] <ChoyKloun> obviously not doing it for every single packet
[17:39:27] <ChoyKloun> but for every "session"
[17:42:34] <ChoyKloun> so what i wanted to try is simply add a curve operation for each new node that's encountered
[17:48:20] *** Andrius has quit IRC
[17:51:00] *** Elrohir has joined #bittorrent
[17:51:42] *** Elrohir has quit IRC
[17:51:57] *** KyleK_ has joined #bittorrent
[17:57:13] *** HandheldPenguin is now known as HandheldPenguin`
[18:24:12] *** ajaya has joined #bittorrent
[18:25:40] *** mpweitekamp has joined #bittorrent
[18:26:13] <mpweitekamp> new to bittorrent, anyone have a link of how it works for noobies?
[18:26:33] <ChoyKloun> the_8472: so anyways.. my idea flies ?
[18:26:41] <ChoyKloun> or atleast has a chance of leaving the airfield
[18:26:54] <ChoyKloun> then lets see if it also can land or whether it's a case of controlled flight into terrain :)
[18:27:40] *** liouxNOT has joined #bittorrent
[18:39:30] *** mpweitekamp has left #bittorrent
[18:40:26] *** goussx has quit IRC
[18:42:01] <The_8472> ChoyKloun, well... i'm not sure if it's needed, but at least thinking about it doesn't hurt
[18:42:35] *** lioux_ has quit IRC
[18:43:00] <ChoyKloun> incidentally it also solves some other issues i've been yabbing about :)
[18:45:16] <The_8472> only if it's mandatory
[18:45:30] <ChoyKloun> right
[18:45:34] <ChoyKloun> but it somewhats lessens exposure
[18:53:08] <ChoyKloun> but ya will try it
[18:53:16] <ChoyKloun> i need something thats not fucking php work to code .. :)
[18:53:26] <ChoyKloun> running a php sweatshop all week makes me really hate php
[18:55:43] *** Miller` has quit IRC
[19:05:59] *** Andrius has joined #bittorrent
[19:11:10] *** Andrius has quit IRC
[19:18:20] *** goussx has joined #bittorrent
[19:22:21] *** swinokur has quit IRC
[19:29:45] *** swinokur has joined #bittorrent
[19:32:45] *** swin has joined #bittorrent
[19:35:26] *** swinokur has quit IRC
[19:35:44] *** swin is now known as swinokur
[20:42:34] *** GTHK has joined #bittorrent
[21:13:28] *** GTHKn has joined #bittorrent
[21:18:24] *** bt42 has joined #BitTorrent
[21:25:33] *** GTHKn has quit IRC
[21:37:11] *** bittwist has quit IRC
[21:39:46] *** GTHK has quit IRC
[22:14:02] *** Switeck has joined #bittorrent
[22:26:38] *** Switeck has quit IRC
[22:30:55] *** _rafi_ has quit IRC
[22:32:54] *** Switeck has joined #bittorrent
[22:38:54] <K`Tetch> http://ktetch.wordpress.com/2009/12/04/p2p-hurts-uk-music-sales/
[22:47:03] <Switeck> piracy must be really cutting into album sales...they really should do something about that!
[22:50:31] <Switeck> did that study cover the losses to international music sales?
[22:50:41] <Switeck> or normalize for the downturn in the economy?
[22:51:10] *** tris has quit IRC
[22:52:55] <K`Tetch> there were numbers for finland, from 1980-2008
[22:52:59] *** waldorf_ has joined #bittorrent
[22:53:03] <K`Tetch> or a graph anyway
[22:53:30] *** tris has joined #bittorrent
[22:54:39] <K`Tetch> http://neuron2neuron.blogspot.com/2009/05/finnish-pirate-party-study.html
[23:01:04] <swolchok> what was the short version of why you want to crypt DHT traffic?
[23:03:47] <swolchok> oh, it was mentioned right there at the end -- ISP MITM to shut down the DHT. DH by itself doesn't provide security against MITM...
[23:05:24] <swolchok> isn't your client-side crypto state going to balloon as you contact more DHT nodes? multiplicative increase in the size of the routing table
[23:10:06] *** rrr_ has joined #bittorrent
[23:29:55] *** JudgeSHAD0W has joined #bittorrent
[23:52:10] *** KyleK_ has quit IRC

top