NOTICE: This channel is no longer actively logged.
[00:00:15] *** _rafi1_ has joined #bittorrent [00:04:35] *** _rafi_ has quit IRC [00:04:36] *** K`Tetch has quit IRC [00:13:02] *** K`Tetch has joined #bittorrent [00:17:34] *** _rafi2_ has quit IRC [00:18:23] *** _rafi1_ has quit IRC [00:25:10] *** L337hium has quit IRC [00:35:36] *** Harold_parker has joined #bittorrent [00:38:10] *** burris has quit IRC [00:38:37] <Harold_parker> fucking fuck [00:38:40] <Harold_parker> mininova now too [00:38:47] <Harold_parker> where will this end D: [00:41:49] <Switeck> when everyone is dead [00:42:46] <Switeck> I'm waiting for GOOGLE to get shut down for similar reasons [00:42:50] <Harold_parker> lol [00:42:57] <Harold_parker> google have too much sway now i think [00:43:07] <Switeck> it indexes way too much to not be considered a "contributor" [00:43:24] <Harold_parker> ehehe [00:43:53] <Switeck> I've even heard about Google Maps showing the best places to buy drugs... [00:44:02] <Harold_parker> ..... [00:44:05] <Harold_parker> wtF? [00:44:21] <Harold_parker> that is so illogical [00:44:25] <Harold_parker> i don't even know where to start [00:44:35] <Switeck> reason never entered the picture... [00:45:29] <Harold_parker> well i did read hamas were apparently using google maps to fire rockets [00:45:38] <Harold_parker> which is just retarded since they could use ANY map [00:46:04] <Harold_parker> seems the media is more interested in publishing a story than researching it first [00:46:17] <Harold_parker> but yeah i reckon google's so powerful now they'd be hard to challenge [00:46:19] <Switeck> yes [00:46:33] <Switeck> Hamas could fire the rockets and turn on world news channels to see where they land [00:47:02] <Harold_parker> aye exactly [00:47:19] *** eightfold has joined #bittorrent [00:48:48] *** init0_ has quit IRC [00:49:57] <eightfold> don't know if this could be a place to ask a utorrent question, but i'll give it a try. [00:51:26] <eightfold> i'd like to start running utorrent in a virtualbox virtual machine. i want to move it from the host installation. all the torrents on the host install of utorrent have no .torrent files. i want to save all the settings from the host install and copy to the virtual machine and resume where i left off. [00:52:04] *** GTHK has joined #bittorrent [00:52:13] *** goussx has joined #bittorrent [00:52:46] <Harold_parker> and... [00:52:51] <Harold_parker> ? [00:53:04] <eightfold> i'd like to export the settings of utorrent [00:53:14] <eightfold> seems they reside in the win registry nowadays [00:53:26] *** init0 has joined #bittorrent [00:53:30] <eightfold> there's only the .exe in the utorrent folder [00:53:54] <GTHK> %appdata% [00:54:26] <eightfold> GTHK: ah, k [00:54:37] <eightfold> there it is, thank you [00:54:57] <eightfold> GTHK: should this be the only place where settings and files related to utorrent are stored? [00:55:39] <GTHK> If you create a blank settings.dat with the exe everything will go with the EXE instead. [00:56:18] <eightfold> what do you mean by "everything will go with the EXE instead"? will it be in the same folder? [00:56:19] <Switeck> It would help to try uTorrent's FAQ [00:56:33] *** burris has joined #bittorrent [00:56:50] <Switeck> http://www.utorrent.com/faq/installation [00:56:57] <eightfold> thanks [00:57:20] <Switeck> run self-contained in one directory [00:58:18] <eightfold> Switeck: but swiping the settings.dat would also remove all current settings (info about loaded torrents etc), i assume? [00:58:37] <Switeck> resume.dat controls what torrents you have loaded [00:59:10] <eightfold> ok, that's good [00:59:18] <Switeck> You may also still have the .torrent files stored where the old settings.dat and resume.dat are [00:59:21] <Switeck> copy them as well... [01:00:07] <GTHK> .old = old, .new = you somehow managed to kill your computer at the right time and probably don't have caching, and .bad = the hash failed. [01:03:05] <eightfold> hmm, i moved the uTorrent appdata folder to the virtual machine. running the utorrent.exe on the virtual machine now brought up the installer [01:03:49] <Switeck> that means you goofed [01:04:19] <Switeck> you copy what was in the folder to the same folder as the utorrent.exe? [01:04:30] <Switeck> so settings.dat is in the same folder as utorrent.exe? [01:04:56] <GTHK> Doesn't the installer pop anyway? seems to do son in appropriately. [01:05:05] <eightfold> no, resorted to still having appdata in the appdata folder (ie, not doing blank settings.dat) [01:05:39] <GTHK> Make sure you have a backup before continuing [01:05:41] <eightfold> so i copied the utorrent folder from the host install to the appdata folder on the guest system [01:06:13] <eightfold> GTHK: i have a backup of the original settings, it's still on the host system installation [01:06:37] <GTHK> I;ve gotten the installer on my "contained" installs, and sometimes on upgrades. [01:07:03] <Switeck> just do a blank settings.dat first install [01:07:25] <Switeck> then stop+close uTorrent, and copy over ALL your settings files and .torrent files and restart utorrent [01:08:22] <The_8472> hehehe, that procedure seems to be the same for almost any application ^^ [01:09:18] <eightfold> also, should i change the paths for were the data is on the old install, before moving the appdata folder? i mean, the path for the completed torrents on the host system was D:\Users\foo\Data\Downloads\uTorrent\Data\Complete , should i change it to \\192.168.1.50\Downloads\uTorrent\Data\Complete on the host install [01:09:33] <GTHK> The install process doesn't seem to overwrite files either. [01:10:01] <eightfold> i don't have the torrent files left, either. that's why i'm worried utorrent wont find data on the new virtual installation [01:14:52] *** bbelt16ag1 has joined #bittorrent [01:15:04] *** bbelt16ag has quit IRC [01:15:19] <GTHK> It'll read what you have. What are you trying to do? [01:18:35] <eightfold> problem is, i now changed the path to \\192.168.1.50\Downloads\uTorrent\Data\Complete on the old/host system install, so that when copied to the virtual machine it would find the completed data. but, it's giving the message that it can't find the files at D:\Users\foo\Data\Downloads\uTorrent\Data\Complete ie, the old path. [01:19:17] <GTHK> Errrrrrrr bencode edit? [01:19:18] <eightfold> so, i guess the path i set in the settings are only for torrents loaded after the settings has been made. not for already loaded torrents. [01:19:54] <eightfold> bencode? [01:20:10] <GTHK> You could tweak the data files to change the paths. [01:20:24] <eightfold> GTHK: sounds like what i would want to do [01:20:34] <eightfold> GTHK: how complicated would that be? [01:21:04] <GTHK> If you don't read the warning, you'll probably trash the files. [01:21:18] <GTHK> https://forum.utorrent.com/viewtopic.php?id=31306 [01:21:31] <eightfold> GTHK: and you are now talking about the actual downloaded data? [01:21:32] <eightfold> :) [01:22:27] <GTHK> I thought you were having pathing issues with uT looking in the wrong place? o.o [01:23:32] <eightfold> GTHK: yes, that is corrent. [01:24:12] <eightfold> GTHK: i thought you warned me that some critical unbackedup files would be deleted. like the data downloaded via utorrent. [01:24:17] <eightfold> the appdata files are already backed up [01:24:31] <eightfold> i can trash them around as much as i like :) [01:25:23] <GTHK> Nah, mistakes in the data files can cause them to be rejected is all. [01:25:33] <GTHK> *.dat [01:25:39] <GTHK> ...pie. [01:28:56] <eightfold> ok, i'm replacing in resume.dat [01:28:59] <eightfold> anything more? [01:29:12] *** DHE has joined #bittorrent [01:30:15] <GTHK> .fileguard needs to be taken care of. Did you read the warnings? [01:33:10] <DHE> woah, what'd I miss? [01:33:38] <eightfold> DHE: everything :) [01:33:50] <GTHK> Talk about uTorrents appdata, that's about when I got here. [01:34:06] <eightfold> GTHK: yes, exit utorrent first and don't mess around with info dictionary. can't quite figure out what would change the info dictionary though [01:34:19] <Switeck> everything changes it :P [01:34:21] <DHE> oh great. [01:34:34] <GTHK> The warning about .fileguard :( [01:34:38] <eightfold> Switeck: ah, k :) [01:35:02] *** goussx_ has joined #bittorrent [01:35:05] <Switeck> Did you get Ultima's Bencode editor (or similar)? [01:35:31] <eightfold> GTHK: fileguard is a registry key suppose? [01:35:43] * GTHK gives up. [01:36:25] <eightfold> GTHK: haha, sorry. i think i just realized it is info inside the .dat files [01:37:09] <eightfold> Switeck: 0.6.1 from here: https://forum.utorrent.com/viewtopic.php?id=31306 [01:37:31] <Switeck> ok [01:38:56] <eightfold> could the .torrent files infohash contain information needed for private torrent trackers to identify me as me? [01:40:50] <The_8472> no [01:41:15] <The_8472> that is outside the part used to calculate the infohash [01:42:42] <eightfold> so, what could the loss of affecting the infohash be? [01:43:11] <GTHK> infohash is used to ask the tracker for people with the same torrent. [01:43:12] <The_8472> loss of affecting the infohash? oO [01:43:21] <The_8472> speak english please [01:43:35] <eightfold> shite, english is not native tongue [01:44:32] <TheSHAD0W> If the infohash changes, peers will not recognize each other, nor will the tracker connect you to the right torrent. [01:44:35] <eightfold> what could i mess up by changing the infohash (which the bencode editor seems to do)? [01:44:50] <TheSHAD0W> This is a security feature, to make sure no one edits a torrent. [01:44:50] <eightfold> TheSHAD0W: ouch [01:45:14] <TheSHAD0W> Otherwise people could add malware or trojan horses. [01:45:18] <The_8472> the bencode editor only changes the infohash if you change something inside the info section, hence the name [01:45:23] <The_8472> anything outside it can be changed [01:45:36] <GTHK> Just don't change anything in the info dictionary. If you have pathing issues within uT you should be mucking in resume.dat anyway. [01:46:01] <eightfold> yeah, and all i want to change is the path. so this should be ok i guess? [01:46:35] <eightfold> resume.dat is what i'm looking at, yes [01:46:42] <eightfold> and that is all that should be edited? [01:46:51] <eightfold> no other dats? [01:46:53] *** Sekou has joined #bittorrent [01:47:27] <Switeck> yes [01:47:38] <TheSHAD0W> I would recommend you not edit that. [01:47:41] <Switeck> only resume.dat needs to be edited to change paths [01:47:47] <TheSHAD0W> I recommend you do things manually. [01:47:53] <Switeck> (make backups first!) [01:47:56] <TheSHAD0W> (1) Start the torrent fresh. [01:47:56] <TheSHAD0W> (2) Stop it. [01:48:04] <TheSHAD0W> (3) Copy the old files over the new ones. [01:48:11] <TheSHAD0W> (4) Set the client to force re-check. [01:48:16] <TheSHAD0W> (5) Restart the download. [01:48:59] <TheSHAD0W> You'll lose a little bit of data, but it's not worth the hassle. [01:49:41] *** goussx has quit IRC [01:49:45] *** goussx_ is now known as goussx [01:49:55] *** bbelt16ag1 has quit IRC [01:52:10] <eightfold> should i delete any .dat.old or .dat.1.bad [01:52:14] <Switeck> yes [01:52:23] <Switeck> delete those [01:52:34] <Switeck> you backed up everything in case they later prove "valuable"? [01:53:37] <eightfold> error: invalid download state [01:53:46] <eightfold> try resuming [01:54:18] <Switeck> did you do a force recheck to verify those files exist where they say they are? [01:54:39] <eightfold> i removed the .fileguard, replaced the paths to the correct ones. copied the resume .dat to the new folder [01:54:54] <eightfold> Switeck: nope :) [01:55:16] <eightfold> Switeck: success :) [01:55:35] <eightfold> there will be some rechecking to do [01:55:53] <eightfold> luckily, i'm going to sleep [01:58:12] <eightfold> thanks all for excellent help! [02:01:58] *** Sekou has left #bittorrent [02:06:53] *** goussx has quit IRC [02:13:27] *** goussx has joined #bittorrent [02:19:33] *** goussx has quit IRC [02:20:23] *** Harold_parker has quit IRC [02:24:15] *** goussx has joined #bittorrent [02:40:40] *** chelz has joined #bittorrent [02:43:56] <erdgeist> Is there any plans to automatically feed a torrent search engine from dht? [02:45:53] <Switeck> I think TPB is trying to do something like that XD [02:46:09] <erdgeist> Switeck: I hold that bet :) [02:46:56] <The_8472> the DHT is not really indexable, at least it's very costly to do so [02:47:15] <erdgeist> The_8472: So far I know :) [02:47:45] <erdgeist> The_8472: I'm brainstorming with a friend about putting trust metrics into DHT [02:48:15] <erdgeist> The_8472: like signing an info_hash as "legit". i.e. containing what its metadata claims [02:49:07] <The_8472> things like that could be done. but not with the mainline DHT as it is. it doesn't allow you to store arbitrary data for example [02:49:42] <erdgeist> The_8472: Yes. And it should not be blown up, unnecessarily. [02:49:56] <erdgeist> The_8472: But in the long run those centralized indexes will vanish [02:50:08] <chelz> well is there some way to sniff what's going on on the network so an indexer would be able to at least see what's being requested on the DHT and then request it itself? [02:50:25] <erdgeist> chelz: Yes, my thoughts were along those lines [02:50:35] <chelz> erdgeist: something only exists as long as someone else is hosting it, whether or not it's a node on a DHT [02:50:37] <The_8472> you could insert a bunch of nodes throughout the keyspace and sample which GET_PEERS requests are done [02:50:56] <chelz> The_8472: would that not be considered malicious activity? [02:51:11] <erdgeist> chelz: but such an distributed indexer could be easily replicated everywhere [02:51:21] <erdgeist> chelz: without needing gigabit link, like tpb does [02:51:31] <The_8472> if the node is participating properly in the DHT then it might be a privacy issue, but not necesarily harmful to the performance of the DHT itself [02:51:38] <chelz> ah [02:51:57] <The_8472> if you want a distributed indexter a DHT is not the proper thing to do i think [02:52:11] <The_8472> there are better approaches [02:52:11] <chelz> well ideally each of the inserted nodes would be some kind of 'public resource' and the data gathered by them could be used by any indexing site that wanted it [02:52:58] <erdgeist> The_8472: well, having metadata available via dht reduces the indexing site's problem to "searchsting"->info_hash and info_hash->trust [02:53:05] <The_8472> getting a non-exhaustive sample of the DHT-tracked torrents is quite easy. making things exhaustive AND efficient... that's non-trivial [02:53:27] <The_8472> erdgeist, yes [02:53:31] <Switeck> DHT to me is a proxy server form of tracker [02:53:36] <chelz> in terms of working with what's already in use by bittorrent, i don't see any other options. it would be cool if a spec for a more featureful dht could be drawn up by top torrent client devs [02:53:52] <Switeck> each "hop" it must make to find data compounds the bandwidth requirement [02:54:00] <erdgeist> The_8472: Now you can model the info_hash->trust problem with some extra index in dht [02:54:13] <The_8472> that is what i doubt [02:54:29] <The_8472> indexers are selective, have user comments and things like that which basically are a measure of trust [02:54:45] <The_8472> you can't squeeze that into a single algorithm easily [02:55:02] <The_8472> i mean how would you phrase "legit source, but file #13 is corrupt" into a trust value? [02:55:26] <erdgeist> then this obviously is not legit [02:55:33] <The_8472> well [02:55:49] <The_8472> "legit source, but file #13 is missing 1 block" [02:56:08] <DWKnight> yhatzee's reasoning for not using a score number seems to apply here [02:56:12] <erdgeist> so I can choose to keep on trusting that signatut, or not [02:56:22] <chelz> that is a very good example The_8472 [02:56:27] <DWKnight> it's hard to display a subjective opinion numerically [02:56:31] <The_8472> yeah [02:56:58] <The_8472> and then there's the issue that bad torrents get deleted. thus clients would have to keep a shadow list of torrents to downvote basically despite having deleted them [02:57:04] <chelz> there was a thing on 5 star ratings and youtube and how the vast majority are either 5 or 1 since people aren't really comparing videos against eachother and some other stuff [02:57:04] <The_8472> since the DHT's memory is volatile [02:57:08] <The_8472> it forgets pretty fast [02:57:24] <The_8472> star ratings are even worse than downvoting things [02:57:42] <The_8472> because people don't just rate if it is what it says on the can but also the quality of the content itself. or whether they like it [02:58:03] <erdgeist> The_8472: Well, with torrents it is really obvious in 99/100 cases [02:58:12] <The_8472> picture a bunch of creationists rating a torrent on darwin's reasearch low [02:58:12] <erdgeist> The_8472: either the torrent is lying or it isnt [02:58:19] <chelz> something that i originally thought was a solution but turned out to replicate existing functionality would be say a trusted feed of torrents from some kind of editors, in the style of sharereactor and rlslog, but then an indexing site already provides a trusted list of torrents [02:58:43] <The_8472> erdgeist, still leaves the issue of rating liking the content vs. legitness vs. quality of the content [02:58:44] <erdgeist> The_8472: either it _IS_ a CAM of <movie> or it is sesamestreet [02:59:12] <erdgeist> The_8472: this is just convenience, not essential [02:59:16] <The_8472> erdgeist, you know the intent, i know the intent... users don't. they vote based on whatever they feel to vote on [02:59:39] <The_8472> y would be say a trusted feed of torrents from some kind of editors <- that's a lot easier to implement [02:59:50] <chelz> having any written up "suggested voting style" would be ignored quite quickly. reddit's reddiquitte is basically gone, for example. [02:59:57] <The_8472> having many moderated feeds of torrents. [03:00:23] <The_8472> like... release groups ^^ [03:00:24] <chelz> The_8472: yeah but so far i've only really seen the eztv guys take on the idea [03:00:27] <chelz> haha [03:00:30] <chelz> exactly [03:00:50] <The_8472> so i could have my ubuntu-feed for example, my pirated tv shows feed, my anime group X feed, ... [03:00:52] <chelz> as long as things are cryptosigned it's verifiable [03:01:03] <erdgeist> The_8472: Hmm, signed comments, then? [03:01:09] <The_8472> not comments, no [03:01:10] <erdgeist> The_8472: floating aroud in a p2p-net? [03:01:35] <The_8472> anyone (or a group of people) can basically generate a distributed RSS feed of infohashes [03:01:44] <The_8472> which is signed by that group / single person [03:01:49] <chelz> making a distributed system for either ratiotracking or determining the legitimacy of torrents are both very difficult problems [03:01:58] <The_8472> that basically cuts out the indexer of the equation [03:02:05] <erdgeist> The_8472: smart [03:02:13] <chelz> The_8472: torrent clients would have to be updated to support this though [03:02:18] <The_8472> yes [03:02:51] <The_8472> distributed RSS feeds + DHT scrapes are the most realistic, easiest ways i can think of to replace indexers [03:03:02] <The_8472> it's not a 1:1 replacement, but as good as it would get [03:03:26] <The_8472> keyword search... the DHT is ill-suited for that, you'd need something completely new. [03:03:28] <chelz> when you get to the point of adding in new stuff, rather than working with what's there, it's seductive to think of how to combine fixes to multiple problems into one system [03:03:43] <erdgeist> The_8472: no, keyword search belongs somewhere els [03:03:45] <The_8472> DHTs are exact-match, not fuzzy-search. or multiple-index/permutation-search [03:03:48] <The_8472> indeed [03:03:49] <chelz> distributed searching is not popular and people don't seem to want it [03:04:17] <chelz> with the hydra aspect of index sites as it is, there's not really a demand for trusted feeds either [03:04:21] <The_8472> distributed searching can be done, but not with Kademlia. not efficiently anyway [03:04:47] <chelz> yeah and if it's not efficient then it's usually not speedy, totally unlike a centralized tracker [03:04:47] <The_8472> chelz, well... index sites only really work when they're big [03:04:56] <erdgeist> chelz: you can't do distributed searching by have a good reputation systems [03:05:01] <The_8472> because then they tend to gather all kinds of obscure content by their sheer mass [03:05:10] <erdgeist> chelz: I mean "without having" [03:05:28] <The_8472> many small indexers make searching for obscure content hard [03:05:36] <The_8472> unless they're specialized [03:05:37] <chelz> erdgeist: kad/emule gets along decently with number of people sharing a file [03:06:02] <chelz> yeah this gets into this other concept of well what about somehow getting sites to connect their back ends [03:06:08] <erdgeist> chelz: they're too small now. all the big traffic is in newsgroups and bittorrent [03:06:11] <chelz> usenet for example [03:06:31] *** KyleK_ has joined #bittorrent [03:06:40] <chelz> erdgeist: yeah, i'm hoping to take what good ideas they have and help get them into bittorrent [03:07:18] <chelz> my main fear of having distributed sites all providing access to something is that some of the sites would get more popular than others and collude to push out smaller sites. somehow usenet has resisted this. [03:07:47] <The_8472> distributed sites is non-sense [03:07:51] <erdgeist> chelz: usenet is the mafia [03:08:04] <erdgeist> chelz: they just could survive since they make shitloads of money [03:08:07] <The_8472> too heavyweight to distribute things [03:08:13] <erdgeist> chelz: and then just buy whoever is after them [03:08:37] <chelz> The_8472: non-sense for what use? i'm talking about a shared database of indexed torrents [03:09:25] <chelz> erdgeist: but still there are numerous providers. i don't know how hard/easy it is to be a new business and try to offer usenet access but i think it's possible. [03:09:39] <chelz> the 'aggregated scrape file' on openbittorrent is one step in the direction of a distributed tracker system [03:09:44] <The_8472> chelz, ah well... that's something different ^^ [03:10:13] <erdgeist> chelz: good luck [03:10:32] <erdgeist> chelz: most usenet services don't give you access to "the good shit" [03:11:02] <chelz> erdgeist: what? like which ones? the standard paid ones like easynews, gigawhatever, and those do [03:11:15] <erdgeist> chelz: yes [03:11:22] <erdgeist> chelz: and guess why they're not yet shut down? [03:11:48] <erdgeist> chelz: do you know what an easynews account is, per month? [03:11:57] <chelz> erdgeist: i'm not talking about legality, i'm talking about letting new businesses/groups have access to the distributed pool of data [03:11:59] <The_8472> they have the money to pay for an armada of lawyers? [03:12:05] <chelz> offtopic :| [03:12:22] <erdgeist> chelz: they do the caching themselves [03:12:48] <erdgeist> The_8472: lawyers and politicians [03:12:48] <chelz> but each provider can specify which other serves to talk to if they wanted, so they could form a private circle [03:13:17] <chelz> which would be good for business, since then to get the latest stuff, you'd need to join a provider that's part of the inner/private circle [03:13:32] <chelz> there's that potential for abuse in a distributed site setup [03:13:48] <erdgeist> But we were talking about how to distribute a realtime search index [03:14:54] <chelz> well say all the databases on torrent indexers were suddenly open and accessible by other sites. people would still go to mininova and tpb and so they would have an advantage. mininova and tpb could block smaller sites from accessing their feed. [03:15:25] <erdgeist> chelz: we do not [03:15:29] <erdgeist> chelz: ehrm, tpb does not [03:16:16] <erdgeist> but that russian search index-engine always is overloaded [03:16:35] <erdgeist> Normally I'd say, this is a problem for google [03:16:43] <erdgeist> But they're not exactly unbiased [03:17:03] <chelz> hmm yeah [03:17:23] <chelz> well yeah, that distributed thing is just one idea i had for tackling the single point of failure issue of index sites [03:18:54] <erdgeist> And tpb's way of remembering forever, who downloaded which file is not that hot, in the long run, either [03:19:05] <The_8472> they do? [03:19:58] <chelz> i didn't know tpb kept track of torrentfile dls or snatches [03:20:00] <erdgeist> Well, every comment you ever make, every torrent you upload is forever associated with your username [03:20:17] <The_8472> downloads != uploads [03:20:33] <erdgeist> No, downloads are not recorded [03:20:46] <erdgeist> but once you comment on the quality, this is public info [03:21:06] <The_8472> well, yes. but do they log IPs associated with the usernames? [03:21:14] <chelz> oh so you're talking about anonymized ratings [03:21:16] <The_8472> if they don't then you're basically making pseudonymous comments [03:21:24] <erdgeist> The_8472: of course not [03:21:36] <Switeck> bleh [03:21:42] <The_8472> then i don't really see the issue except for people who put a name in there that could be associated with them [03:21:52] <erdgeist> sure. but once your pseudonym is revealed (be it a police raid) you can be linked to you past [03:21:53] <Switeck> need to get back to putting the data closer to end-users [03:22:18] <Switeck> Either everyone is a tracker (DHT) or many small-but-specialized trackers [03:22:27] <erdgeist> Oh bugger, I type like a 13 year old. [03:22:30] <The_8472> erdgeist, how can it be revealed if they don't keep IP logs? [03:23:02] <erdgeist> The_8472: but you log in there with your pseudonym [03:23:05] <chelz> Switeck: the tracker issue has pretty much been solved with DHT. the only issue now is the index site. [03:23:24] <erdgeist> chelz: not exactly. private torrents still need a tracker [03:23:33] <chelz> The_8472: history on a suspect's computer showing they logged into tpb under tha username [03:23:34] <The_8472> erdgeist what exactly is the threat model here? [03:23:40] <The_8472> ah [03:23:45] <Switeck> the index site is the source for the .torrent? [03:23:58] <The_8472> well, that affects only that single suspect. and he probably would have those .torrents on his computer too [03:24:00] <erdgeist> The_8472: You being busted for whatever reason and the police being able to reconstruct your history by knowing it [03:24:06] <The_8472> and... you can always choose not to keep cookies/a history [03:24:27] <The_8472> disable the history, autologin and password store in your browser [03:24:35] <The_8472> or just store it on an encrypted disk [03:24:42] <The_8472> if you're concerned about that [03:24:45] <erdgeist> The_8472: sure. I am just saying, its not perfect [03:24:47] <chelz> erdgeist: erdgeist: the only reason private sites exist is to try to increase retention time, usually done by having a ratio system. keeping a high retention time versus making sure a key link in the p2p chain isn't broken are two different issues. [03:25:13] <chelz> the actual finding of files requires an index site currently, so that's a single point of failure. [03:25:29] <Switeck> It does? [03:25:29] <The_8472> erdgeist, well... i don't see this as a threat. sure, anonymous comments would be even better. but people very rarely get into trouble over having an account on some site [03:25:32] <chelz> oh and exclusivity and potential increased dl speeds [03:25:39] <Switeck> I can email people a .torrent file [03:25:43] <chelz> exclusivity doesn't lend itself to well to a massp2p system [03:25:46] <erdgeist> The_8472: now. take everything you just wrote about the above and apply it on a p2p trust metric [03:26:01] <Switeck> I'm sure bare .torrent files can be hosted on ordinary websites. [03:26:04] <erdgeist> The_8472: suddenly ip->pseudonym->ip is available [03:26:12] <chelz> Switeck: then what is that site suddenly? an index site. [03:26:21] <The_8472> depends on how you implement the trust metric [03:26:30] <erdgeist> The_8472: correct [03:26:40] <Switeck> chelz, an index site usually means statistics too...but those are not necessary [03:26:45] <chelz> Switeck: people searching for torrents aren't going to see your email, since it's in private accounts, not hosted in some public method [03:26:52] <erdgeist> The_8472: So I've only wanted to give an example of how this suddenly becomes an issue [03:26:57] <Switeck> Rapidshare it XD [03:27:11] <The_8472> erdgeist, you brought up TPB though, where it's not really an issue. that was my point [03:27:19] <chelz> Switeck: then rapidshare becomes an index site. ideally there would be some distributed index system that was reliable. [03:27:30] <erdgeist> The_8472: only to have an example to begin with ;) [03:27:38] <Switeck> reliable requires redundancy [03:27:50] <The_8472> not a good one. you could just describe the problem itself instead of making a bad example [03:27:55] <chelz> Switeck: exactly. and making something distributed helps a lot with that [03:28:02] <erdgeist> The_8472: maybe. [03:28:17] <Switeck> .torrent file could be hosted by multiple sites [03:28:31] <Switeck> that's really quite trivial [03:28:32] <chelz> erdgeist: well authentication of any kind could incriminate someone. say even on a distributed p2p rating system where auth is handed through pubkey crypto, if you had the privkey for some acct, then it could be tied to a user [03:28:39] <erdgeist> The_8472: I should've thought that through the end before posting it here [03:29:22] <Switeck> why do we even NEED a rating system? [03:29:25] <chelz> Switeck: yeah currently torrent sites seems to scrape eachothers RSS feeds, which is working pretty well i guess. but there is an issue for the non-mirrored files. it's not easy to instantly replicate the torrentdb of a site to provide a mirror. [03:29:38] <erdgeist> Switeck: try finding TBBTS03x01 without one [03:29:55] <The_8472> Switeck, to asses if things are what they say on the can [03:29:59] <chelz> or just finding a nonfake/nonpoisoned copy of something [03:30:07] <chelz> yeah [03:30:08] <The_8472> either we need a trust/ratings system or trusted sources [03:30:14] <chelz> or both [03:30:28] <Switeck> If you don't trust the index site...how is a rating system based on mutual distrust going to help? [03:30:37] <The_8472> a one-way trust relation ship is a lot easier than a web of trust [03:30:38] <erdgeist> The_8472: trusted sources have a tendency to vanish [03:30:51] <The_8472> erdgeist, and new ones pop up in their place [03:31:24] <erdgeist> The_8472: on the other hand: just providing info_hashes hardly is a crime anywhere, is it? [03:31:25] <chelz> i don't think people would use a malicious index site for too long [03:31:53] <The_8472> erdgeist, it would go even further than that. you'd just provide a pubkey to a distributed feed that indexes infohashes + descriptions [03:31:55] <chelz> erdgeist: i'm sure under US law it might fall under contributory copyright infringement if it ever came up in a case [03:32:04] <Switeck> and even a index site with high fake rates (because it's popular) would be used with a grain of salt. [03:32:05] <The_8472> so... pubkey -> dht-rss -> infohash -> .torrent -> data [03:32:10] <The_8472> many many layers of indirection ^^ [03:32:27] <chelz> put google cache infront of all of that too ;) [03:32:31] <The_8472> and anyone could host that pubkey ala "hey, this pubkey points to some nice content which i'm not responsible for" [03:32:50] <chelz> hmm that might work [03:33:30] <erdgeist> The_8472: I wonder if ISPs will be forced to filter everything remotely looking like a magnet-link [03:33:31] <chelz> i know countries vary wildly over whether linking to illegal material is illegal or not. one isn't technically hosting anything but it is a bit gray. [03:33:35] <The_8472> you just need some people who feel responsible in maintaining feeds of particular contents. like... the weekly ubuntu torrent! [03:33:43] <The_8472> erdgeist, SSL [03:33:49] <chelz> The_8472: that is something i was just typing up [03:33:49] <erdgeist> The_8472: btw: dht packets are not encrypted/signed in any way? [03:33:56] <erdgeist> ... stupid me [03:34:00] <chelz> ideally there would be some kind of incentive for providing these services. right now seeding after completing a torrent is totally an altruistic act. [03:34:04] <erdgeist> how could they [03:34:11] <The_8472> no, DHT packets are completely untrusted [03:34:38] <chelz> less overhead if things are untrusted. makes sense that it would start out that way. [03:34:47] <Switeck> chelz, it's not totally an altruistic act, just nearly [03:35:21] <The_8472> it's more of a... if nobody seeds you don't get your content either. [03:35:26] <chelz> Switeck: on a public torrent it is, private torrents not really [03:35:38] <chelz> well that's a tragedy of the commons right there [03:35:42] <erdgeist> The_8472: the thing is, right now a tracker could respond via https, making it hard to intercept bt-traffic [03:35:44] <Switeck> chelz, people seed even on public trackers for rewards [03:35:49] <erdgeist> The_8472: on the isp side [03:35:52] <The_8472> it's more a choice between a low-performing equilibrium (i.e. nobody invests bandwidth, nobody gets bandwidth) and a high-performing one (torrents live longer) [03:35:56] <chelz> Switeck: like what? [03:36:07] <Switeck> if you're uploading part 1 of a series of torrents that most people get the whole series of... [03:36:15] <Switeck> you may be connected to the same peer on multiple torrents [03:36:31] <erdgeist> The_8472: but your isp can now easily filter/modify dht packets. [03:36:45] <Switeck> Even if not, anyone you are uploading to is presumably not putting as heavy a demand on others who could be uploading to you on torrents also on the same tracker. [03:36:50] <The_8472> erdgeist, so far that has been a nonissue. if that should change... we can change it [03:37:23] <erdgeist> The_8472: And I've been personally approached by people asking me how to best build products that help isps redistributing peers [03:37:44] <The_8472> bwhahaha, as if that would ever work [03:37:48] <The_8472> 1 word: Pex [03:37:49] <erdgeist> The_8472: well [03:37:53] <chelz> Switeck: that could happen i guess. but not necessarily a clear reward, compared to say the kind of rewards private trackers give out [03:38:10] <erdgeist> The_8472: depends on whom you're really talking to [03:38:12] <Switeck> private trackers aren't a reward so much as a punishment [03:38:28] <erdgeist> The_8472: I know of at least two products acting as mitm bt-caches/proxies [03:38:50] <chelz> Switeck: how so? [03:38:57] <The_8472> well, they inject themselves into .torrents or tracker-traffic [03:38:58] <erdgeist> The_8472: one is running at an isp in croatia [03:39:00] <Switeck> your ratio just fell, goodbye! [03:39:12] <erdgeist> The_8472: in tracker-traffic [03:39:29] <chelz> there was a story about some isp that would insert its own tracker into torrents downloaded through it, i think in the Philippines [03:39:41] <erdgeist> The_8472: and then they act as a proxy. being the only peer, there's nothing from pex [03:40:08] <The_8472> they block all other peer connections or what? [03:40:13] <erdgeist> The_8472: no [03:40:15] <chelz> Switeck: yeah it is a tradeoff. but losing one's account is the only punishment they can dish out, and the only punishment in a p2p system besides slowing a person's download speed. [03:40:19] <chelz> i've mused about a possible distributed private tracker where the more someone seeds the faster their speeds are. the trickiest part is protecting against gaming/abuse. [03:40:25] <erdgeist> The_8472: they answer to the intercepted announce [03:40:31] <erdgeist> The_8472: with them being to only peer [03:40:35] <The_8472> so the announce never gets through to the tracker? [03:40:39] <erdgeist> The_8472: correct [03:41:00] <The_8472> and that isn't illegal? [03:41:07] <erdgeist> The_8472: So I would not be surprised, if v2.0 could intercept dht packets [03:41:27] <The_8472> well, DHT packets are actually easier to protect [03:41:27] <erdgeist> The_8472: depends. is a transparent http proxy illegal= [03:41:47] <The_8472> it's not transparent, is it? and it's manipulating content, not metadata [03:41:52] <chelz> i wonder if that would be shown to be happening with a https tracker. the cert wouldn't match and the connection would fail i would think. [03:42:03] <Switeck> chelz, a private tracker can prevent you from downloading latest torrents. [03:42:05] <erdgeist> The_8472: well, its manipulating metadata [03:42:11] <erdgeist> The_8472: they DO serve the data [03:42:22] <erdgeist> The_8472: but at speeds THEY deem appropriate [03:42:26] <The_8472> depends if you consider the announce payload metadata or not [03:42:41] <erdgeist> The_8472: They do. I kinda can see their point [03:42:49] <erdgeist> The_8472: not necessarily agreeing [03:43:04] <The_8472> AND WOULD YOU GODDAMN STOP HIGHLIGHTING ME WITH EVERY SINGLE LINE [03:43:11] <chelz> Switeck: ah, indeed. that's another punishment. smart. [03:43:17] <erdgeist> woho :) [03:43:22] <chelz> The_8472: have to make sure you see it ;) [03:43:26] <Switeck> the tracker can hand out fewer ips as well [03:43:26] <The_8472> i... [03:43:32] <The_8472> i'm not blind, ty [03:43:51] <chelz> Switeck: yeah with pex disabled that would hurt too. [03:44:07] <Switeck> if it never handed your ip out to others, you'd be even more screwed [03:44:13] <erdgeist> hmm, where I come from it is considered polite to address the recipient... [03:44:29] <erdgeist> whatever your client does, it's not my fault [03:45:15] <The_8472> i feel belittled if you think that you have to tell me that it's intended for me as if i couldn't get that from the context. on every - single - line. [03:45:21] <chelz> Switeck: well these are all measures that could be taken by existing centralized private trackers, but they're not really directly applicable to a distributed private tracker. [03:45:28] <The_8472> it makes snese in a very busy channel, which this one isn't [03:45:35] <The_8472> *sense [03:45:52] <Switeck> There is no such thing as a distributed private tracker [03:45:55] <erdgeist> I usually use it for later filtering [03:46:00] <chelz> erdgeist: traffic shaping of any kind is a very dangerous thing. at least in the US people are talking about net neutrality [03:46:19] <erdgeist> chelz: So do they in europe [03:46:20] <chelz> Switeck: indeed but i think there could be one. or just some system to keep retention high and people seeding. [03:46:23] <chelz> erdgeist: that's good [03:46:31] <Switeck> I don't [03:46:36] <chelz> Switeck: why? [03:46:39] <erdgeist> chelz: but u.s. laws don't apply everywhere (thanks god= [03:47:08] <Switeck> simple: communication needed in distributed parts removes some of the "private" parts [03:47:10] <chelz> erdgeist: haha. yeah well for us USians we can use all the support we can get to change our laws for the better. european countries resisting them definitely helps. [03:47:27] <Switeck> especially if the parts are not fully trustable [03:47:34] <The_8472> privacy, data manipulation/hacking, telecommunications confidentiality... those are concerns too when the ISP suddenly starts manipulating traffic [03:47:57] <chelz> Switeck: assuming overhead from encryption/crypto is negligible, how could a system not be kept private with similar tech used in systems like tor/i2p/freenet/gnunet? [03:47:58] <erdgeist> I've got friends working at larger ISPs in Germany [03:48:16] <chelz> Switeck: trust could come from some kind of publickey crypto [03:48:17] <erdgeist> And they do explicitely shape bittorrent traffic [03:48:20] <Switeck> tor isn't managing torrents [03:48:25] <Switeck> as an indexer [03:48:41] <The_8472> interesting, but it doesn't seem to be agressive shaping, since i haven't heard anything negative [03:48:46] <The_8472> mostly latency-based i guess? [03:48:49] <chelz> Switeck: i'm not talking about tor itself, just using a similar technology or ideas [03:49:08] <The_8472> or are you talking about mobile providers? [03:49:11] <Switeck> If one part turns "rat", the whole system does what? [03:49:19] <erdgeist> the shaping itself is easy, just use tcp's throtteling when packets are dropped [03:49:26] <erdgeist> no, fibre [03:49:33] <The_8472> tiscali? [03:49:50] <erdgeist> no, "Kabel Deutschland" and "T-Com" [03:50:13] <The_8472> hrrm... i haven't heard about any really noticeable shaping from the telekom [03:50:24] <The_8472> i mean from their endusers [03:50:42] <erdgeist> I know they do it between 9am and 5pm [03:50:56] <chelz> Switeck: they would get banned, like a private tracker. [03:50:58] <The_8472> oO why are you using US times? [03:51:02] <erdgeist> it's not aggressive but it helps to get their QoS content through [03:51:10] <Switeck> but in this case, you're having to ban the TRACKER! [03:51:12] <The_8472> hrmhrm [03:51:29] <erdgeist> I have no clue where you are from and if you can parse o9oo bis 17oouhr :) [03:51:38] <The_8472> i'm from germany ^^ [03:51:43] <erdgeist> in the end THEY want to sell their online move business [03:51:46] <erdgeist> Achwat :) [03:51:59] <chelz> Switeck: well on kademlia it seems to do okay with peers dropping/joining at random times and the system itself is more of the 'tracker' [03:52:23] <The_8472> i knew that you are, watched your tracker fahrn video from a previous chaos congress ^^ [03:52:56] <chelz> Switeck: the only way to keep someone from just rejoining to the DPT is requiring some initial investment, i guess of bandwidth [03:53:07] <The_8472> anyway... where exactly are their issues? last mile? transit? [03:53:23] <erdgeist> so you let me helplessly stumble tring to explain complicated concepts in foreign tongue :) [03:53:24] <The_8472> if you're talking about helping out QoS content [03:53:30] <erdgeist> last mile mostly [03:53:44] <erdgeist> they've connected dozends of households with to few fibre [03:53:46] <The_8472> oh, i'm used to talk in english for the benefit of the spectators ^^ [03:53:50] <Switeck> customer to ISP networking equipment = bottleneck [03:54:07] <erdgeist> so if everyone fileshares, grammy can't watch her soap [03:54:27] <The_8472> and who says that the soap is more important than the soap i download via filesharing? hrrrm..? [03:54:46] <erdgeist> telekom. they are being payed by grammy for the soap [03:54:48] <Switeck> erdgeist, contention ratios of 30:1 and up do that [03:54:55] <The_8472> and i pay for the bandwidth to download [03:55:03] <erdgeist> but not real time :) [03:55:12] <The_8472> bandwidth is bandwidth [03:55:22] <erdgeist> Now I gotta go, bring beer to a party that dried up. Back in... hmm 2h [03:55:23] <erdgeist> :) [03:55:31] <The_8472> hahaha, hf [03:56:06] <Switeck> people's internet speeds have gotten a lot faster in last 10 years but ISP backbones can't speed up much now except through redundancy [03:56:25] <The_8472> well, depends on how much money they throw at the problem [03:56:44] <The_8472> fibers can carry a lot of bandwidth, if you use the expensive stuff [03:56:45] <Switeck> It's only cost effective if they stick with a contention model [03:57:21] <chelz> i've heard of new network tech being asked for by big companies like google and facebook. they say they foresee needing terabit routers very soon. [03:57:30] <The_8472> probably yes, but when i don't get my downlaods in a reasonable time i don't see why my neighbors should get their VoD in a reasonable time either [03:57:34] <Switeck> getting past the first hop from the customer bottleneck is the hard part. [03:57:51] *** bbelt16ag has joined #bittorrent [03:57:59] <Switeck> don't terabit routers already exist? [03:58:21] <chelz> ah i'm not sure about the actual speed asked for, but that it seemed like a lot [03:58:33] <Switeck> sure, no "ordinary" line may be at those speeds -- but if a router had 48+ ports, isn't the total internal bandwidth >1 tbit/sec? [03:59:35] <The_8472> well... even AMS-IX only has a daily peak throughput of 800Gbit/s. and that's distributed over several routers and switches [03:59:40] <Switeck> I'm sure with enough 10 gbit/sec lines, they could all meet at one spot and need an internal routing capacity extremely high. [04:00:01] <Switeck> and 40 gbit/sec fiber lines are becoming more commonplace [04:00:01] *** The_8472 has quit IRC [04:00:21] *** wadim has joined #bittorrent [04:00:23] *** wadim is now known as The_8472 [04:00:52] <The_8472> well... even AMS-IX only has a daily peak throughput of 800Gbit/s. and that's distributed over several routers and switches [04:00:55] <The_8472> and they're the biggst ISP on the planet last time i've checked [04:00:57] <The_8472> *IXP [04:01:14] <Switeck> But Sweden has customers with 1 gbit/sec lines now [04:01:21] <Switeck> what's their infrastructure? [04:01:46] <The_8472> hrrm, let me look up their ixp ^^ [04:03:29] <The_8472> netnod does 180Gb/s peak [04:04:20] <DHE> damn, I missed a cool discussion [04:05:35] <The_8472> so i doubt that they can use those 1Gbit internationally. at least not many fo them at once ^^ [04:05:52] <Switeck> they don't have to jump internationally IMO [04:05:58] <Switeck> who else they going to "peer" with? XD [04:06:35] <Switeck> they get breadcrumbs internationally compared to internal [04:07:15] <Switeck> plus, lines that fast are tough to fully utilize [04:07:35] <The_8472> for more than a few minutes at least [04:07:45] <The_8472> well... seeding you can do. from ramdisks ^^ [04:07:57] <Switeck> You'd need to dump to multiple hdds (probably RAIDs) [04:08:20] <The_8472> i know someone who has a RAID 0 of SSDs... [04:08:22] <Switeck> You could seed from multiple hdds, you'd just need a few fast ones [04:08:33] <Switeck> or lots of slow ones [04:10:32] <chelz> DHE: which one? :P [04:16:55] <DHE> gigabitz [04:24:31] *** KyleK_ has quit IRC [04:27:30] <Switeck> The only reason not to host trackers off "consumer" lines in Sweden is because of possibly semi-transient nature of their internet ip. [04:32:15] <Switeck> but what about DHT nodes? [05:15:45] <burris> I'm using a bit commitment protocol to draw straws with my friends over e-mail B-) [05:38:52] <The_8472> Switeck... dnydns? [05:39:04] <The_8472> and DHT nodes are expected to join and leave at some rate [05:39:39] <The_8472> so an IP that changes every few days is better than a node that only lives for a few hours [05:39:39] <Switeck> If you're going to require heavy-lifting DHT, then you'll need LOTS of Swedish DHTs [05:39:45] <Switeck> DHT nodes :P [05:40:21] <The_8472> no DHT is designed for "heavy lifting" [05:40:30] <The_8472> and a few fast nodes won't do any good either [05:40:39] <The_8472> since load is distributed more or less equally [05:40:59] <Switeck> rating systems? [05:41:04] <Switeck> search capabilties? [05:41:17] <The_8472> well, long-lived nodes might bear some more load. but order of magnitude more at most [05:41:27] <Switeck> If stuff like that gets added to DHT, you're going to want better DHT nodes! [05:41:46] <The_8472> no... we'd want more efficient implementations [05:41:56] <Switeck> watch out for the 5 ton mail truck delivering the postcard [06:00:36] <erdgeist> So [06:00:42] <erdgeist> have I missed anything? [06:02:42] <The_8472> not much [06:04:07] <erdgeist> good :) One thing that struck me is, we need of course QR-Codes for magnet links [06:06:23] <The_8472> QR codes? [06:07:33] *** anakh has joined #bittorrent [06:10:35] <erdgeist> yep [06:24:07] <chelz> one o them cellphone barcode things [06:24:08] <chelz> http://en.wikipedia.org/wiki/QR_Code [06:24:48] <chelz> that would be a pretty cool cell phone app, one that scans a QR code and adds it to a personal RSS feed on some site or server that your torrent client is watching [06:25:08] <The_8472> oh [06:26:03] <chelz> physical sharing of torrent files is an interesting concept but might have some usage issues [06:26:24] <The_8472> and not all that practical [06:26:55] <chelz> there's this one app where you bring two cellphones close together then move them away and it exchanges contact info (i think they call it a 'bump', but people probably aren't knocking phones) [06:26:56] <The_8472> considering that you get most of your torrents/infohashes online anyway [06:27:22] <chelz> yeah but perhaps through 'bumping' or something else, you can share a torrent with a guy infront of you [06:28:04] <chelz> the japanese use those QR codes for URLs and a lot of marketing material has picked up on it. maybe some fields could use torrented stuff to market themselves. [06:36:42] <anakh> http://88.80.20.41/memoryhole/user/esbenc.tar.gz my C bencode decode library, if anyone is interested [06:37:04] <anakh> its not terribly optimized but its quite nice.. and uses a good memory mgmt lib :P [06:41:19] *** Smushers has joined #bittorrent [06:48:54] <alus> anakh: you have a stack overflow bug if the structure is too deep [06:52:02] <anakh> ya [06:52:08] <anakh> obviously as it recurses [06:52:09] <anakh> doh [06:59:40] *** MassaRoddel has quit IRC [07:14:30] <Switeck> http://arstechnica.com/tech-policy/news/2009/11/libraries-dying-for-bandwidthwheres-the-fiber-and-cash.ars [07:16:27] *** _rafi_ has joined #bittorrent [07:27:57] *** rrr_ has quit IRC [07:28:51] *** Smushers has quit IRC [07:46:17] *** MassaRoddel has joined #bittorrent [07:50:51] *** Smushers has joined #bittorrent [07:57:51] *** The_8472 has quit IRC [07:58:58] *** rrr_ has joined #bittorrent [08:08:12] <chelz> any word if anyone got the mininova database before they switched to "Content Distribution" torrents only? [08:34:39] *** goussx has quit IRC [08:44:17] *** goussx has joined #bittorrent [08:55:46] <anakh> is the 'announce_peers' query ever used in DHT? [09:00:36] *** GTHK has quit IRC [09:13:11] *** goussx has quit IRC [09:28:21] *** Switeck has quit IRC [09:29:09] *** anakh has quit IRC [10:04:50] *** anakh has joined #bittorrent [10:05:19] <anakh> why do i get these packets from utorrent [10:05:20] <anakh> 64 31 3A 61 64 32 3A 69 64 32 30 3A 58 73 4F E6 EC 99 56 40 B4 45 68 27 d1:ad2:id20:XsO...V@.Eh' [10:05:24] <anakh> F9 9C 37 EB 68 E5 8C B2 36 3A 74 61 72 67 65 74 32 30 3A 58 73 4F E6 EC ..7.h...6:target20:XsO.. [10:05:27] <anakh> 99 56 40 B4 45 68 27 F9 9C 37 EB 68 E5 8C B3 65 31 3A 71 39 3A 66 69 6E .V@.Eh'..7.h...e1:q9:fin [10:05:31] <anakh> 64 5F 6E 6F 64 65 31 3A 74 34 3A 1F 00 00 00 31 3A 76 34 3A 55 54 42 C3 d_node1:t4:....1:v4:UTB. [10:05:34] <anakh> 31 3A 79 31 3A 71 65 1:y1:qe [10:05:44] <anakh> ffind_node with target == sending id?! [10:29:43] *** medecau has joined #bittorrent [10:29:52] *** medecau has left #bittorrent [11:19:39] *** Elrohir has joined #bittorrent [11:34:13] *** Elrohir has quit IRC [12:09:52] <MassaRoddel> to get nodes close to its own id [12:11:15] <MassaRoddel> this way you build your own table [12:19:19] *** KyleK_ has joined #bittorrent [12:24:16] <anakh> aaah ok [12:25:13] <anakh> just caught me by surprise :P [12:38:08] *** _rafi_ has quit IRC [12:38:22] *** jnpplf_ is now known as jnpplf [12:39:38] *** ivan` has quit IRC [12:39:49] *** ivan` has joined #bittorrent [13:23:17] *** bittwist is now known as bt42 [13:23:53] *** bt42 is now known as bittwist [13:24:26] *** KyleK__ has joined #bittorrent [13:41:06] *** KyleK_ has quit IRC [13:42:03] *** KyleK_ has joined #bittorrent [13:59:09] *** KyleK__ has quit IRC [14:06:54] *** Smushers has quit IRC [14:52:20] *** altNull has joined #bittorrent [15:01:41] *** altNull has left #bittorrent [15:04:14] *** The_8472 has joined #bittorrent [15:08:01] *** chelz has quit IRC [15:41:47] *** medecau has joined #bittorrent [16:04:26] *** medecau_ has joined #bittorrent [16:16:38] *** medecau_ has quit IRC [16:20:28] *** medecau has quit IRC [16:52:16] <anakh> so, DHT client works nicely [16:56:03] *** Elrohir has joined #bittorrent [17:25:32] *** goussx has joined #bittorrent [17:31:45] *** _rafi2_ has joined #bittorrent [17:42:03] *** goussx has quit IRC [17:52:03] *** L337hium has joined #bittorrent [17:52:49] *** goussx has joined #bittorrent [18:13:31] *** ProperNoun has quit IRC [18:25:23] *** HandheldPenguin` is now known as HandheldPenguin [18:27:02] *** goussx has quit IRC [18:27:41] *** void^_ has joined #bittorrent [18:27:42] *** void^ has quit IRC [18:54:04] *** DHE has quit IRC [18:55:50] *** L337hium has quit IRC [19:01:27] *** Andrius has joined #bittorrent [19:02:27] *** goussx has joined #bittorrent [19:04:34] *** L337hium has joined #bittorrent [19:58:19] *** goussx_ has joined #bittorrent [20:14:39] *** goussx has quit IRC [20:14:40] *** goussx_ is now known as goussx [20:24:49] *** goussx has quit IRC [20:50:14] <anakh> uh [20:50:14] <anakh> s 1259437732 Node 188.186.82.64:27858 distance 0x00075d1a best 0x00000122 worst 0xffd8fa5b nodeID C9166D11A1CB67ED906AA8F0D58A2126F495611500 currentToken 385C184E1B93B3E3AAE8C83F366A6A8B927DB217 [20:50:19] <anakh> s 1259437732 Node 77.235.114.152:10005 distance 0x000af07a best 0x00000122 worst 0xffd8fa5b nodeID C91BC071FC942A5F1FBB5AE8762D075F75F3E84800 currentToken 385C184E1B93B3E3AAE8C83F366A6A8B927DB217 [20:50:23] <anakh> s 1259437732 Node 80.7.162.186:56014 distance 0x000b8393 best 0x00000122 worst 0xffd8fa5b nodeID C91AB39816B6EF88380231A1B2E13A952DFA5A5800 currentToken 385C184E1B93B3E3AAE8C83F366A6A8B927DB217 [20:50:27] <anakh> arent tokens supposed to be like random .. ? [20:57:02] <Andrius> it looks random [20:57:06] <Andrius> the first time you read it... [20:58:17] <The_8472> tokens are opaque [20:58:31] <The_8472> they could be generated based on your IP/port/a timestamp [20:58:39] <The_8472> or do you mean transaction IDs? [20:59:48] <anakh> no token [20:59:52] <anakh> as in get_peers / announce_peer [21:00:01] <The_8472> they don't have to be random, no [21:00:29] <The_8472> they shouldn't be predictable though [21:00:44] <anakh> ya and my guess is that they are quite predictable [21:02:35] <anakh> heh these tokens were cute too: [21:02:36] <anakh> 3838383433363431 [21:02:37] <anakh> 3838383737333935 [21:02:37] <anakh> 3838383835393736 [21:02:37] <anakh> 3838383836343836 [21:02:39] <anakh> 3838383836363030 [21:02:48] <The_8472> oO [21:03:05] <The_8472> oh [21:03:07] <The_8472> timestamps i think [21:04:26] <anakh> a few of them are obvious time(NULL) :p [21:04:53] <The_8472> well, that's almost ok if the node is stateful [21:05:22] <The_8472> i.e. if it remembers which timestamp it has sent to whom [21:05:38] <The_8472> at least it makes attacks more expensive [21:05:42] <The_8472> but... still too easy [21:05:44] <anakh> i get sudden flashbacks from ip spoofing in the early 90s :) [21:05:53] <The_8472> yeah, reminds me of that too ^^ [21:06:33] <anakh> i wonder what causes these repetitions of identical tokens from unrelated notes i pasted above [21:06:51] <The_8472> probably calculated based on your address/node id or something like that [21:06:54] <anakh> my gut feeling is that it seeds some rng from time() or similar [21:07:02] <The_8472> without a local secret used to hash it [21:07:07] <anakh> well thing is they tend to appear several identical in a row [21:07:34] <The_8472> packets would have to arrive synchronously at millisecond-precision [21:07:52] <anakh> time() is seconds :) [21:08:17] <The_8472> that would be reaaally stupid [21:08:37] <anakh> i've seen commercial apps generate keys with srand(time(NULL)) + rand() :PPP [21:09:26] <anakh> same product (alarm/entrance control system) also protects communication between the external hardware and the pc admin software using a static key thats the same for all customers and devices :) [21:09:31] <The_8472> on every invocation? [21:09:37] <anakh> yes [21:09:44] <The_8472> wow... [21:09:53] <anakh> well the "seed" material for the key is the same [21:10:04] <anakh> they do a bunch of ugly things to it [21:10:15] <anakh> which all seems to be done by some kid without any understanding of crypto whatsoever [21:10:38] <The_8472> initializating a prng with nanosecond-precision time ONCE per session is sufficient for most threat models... [21:10:54] <The_8472> but reinitializing it everytime is just retarded [21:11:45] <anakh> i can see how it happens .. someone needs to generate random numbers, remmebers/reads something about srand() and rand() ... :> [21:12:03] *** _rafi2_ has quit IRC [21:12:21] <anakh> though .. vanilla rand()s are predictable if you can see the output [21:12:41] <The_8472> java comes with 2 default PRNGs for that purpose [21:12:55] <The_8472> one congruent feedback generator which is fast but easy to predict [21:13:03] <The_8472> and one based on sha1 [21:13:15] <anakh> ya, i normally use a lfsr for fast non-crypto generation [21:14:57] <anakh> rand() is typically based on multiplication and thats several cpu cycles more expensive! :D [21:15:22] <The_8472> even in modern c libraries? [21:15:32] <anakh> lemme check unix rand sec [21:18:03] <anakh> If we are using the trivial TYPE_0 R.N.G., just do the old linear congruential bit. Otherwise, we do our fancy trinomial stuff, which is the same in all the other cases due to all the global variables that have been set up. The basic operation is to add the number at the rear pointer into the one at the front pointer. Then both pointers are advanced to the next [21:18:08] <anakh> location yclically in the table. Th e value returned is the sum generated, reduced to 31 bits by throwing away the "least random" low bit. [21:18:13] <anakh> comment from stdlib/random_r.c .. glibc [21:18:36] <anakh> the "TYPE_0" is just val = ((state[0] * 1103515245) + 12345) & 0x7fffffff; [21:19:03] <kjetilho> that's the code suggested by POSIX [21:19:07] <anakh> so lfsr is definitely faster [21:19:24] <kjetilho> but I don't think POSIX requires any specific implementation [21:20:10] <The_8472> when implemented in galois form at least, yeah [21:28:39] *** KyleK_ has quit IRC [21:35:01] <anakh> MSVC++ rand() is beautifully oldschool atleast :) [21:35:02] <anakh> 7C366BEE |. 8B48 14 MOV ECX,DWORD PTR DS:[EAX+14] [21:35:02] <anakh> 7C366BF1 |. 69C9 FD430300 IMUL ECX,ECX,343FD [21:35:02] <anakh> 7C366BF7 |. 81C1 C39E2600 ADD ECX,269EC3 [21:35:02] <anakh> 7C366BFD |. 8948 14 MOV DWORD PTR DS:[EAX+14],ECX [21:35:04] <anakh> 7C366C00 |. 8BC1 MOV EAX,ECX [22:19:13] *** burris has quit IRC [22:21:55] <anakh> 11480 unique nodes, 3639 unique tokens ... [22:37:26] *** L337hium has quit IRC [22:39:22] *** Switeck has joined #bittorrent [22:41:38] <Switeck> These hostiles?: http://www.cidr-report.org/cgi-bin/as-report?as=14478&view=2.0&v=4 [22:43:23] *** bittwist has quit IRC [22:49:40] <The_8472> yeah, baytsp are hostiles ^^ [22:53:02] <Switeck> seems they added a few ip ranges recently according to that. [22:59:19] *** GTHK has joined #bittorrent [23:05:07] *** mxs has quit IRC [23:05:20] *** mxs has joined #bittorrent [23:11:53] *** chelz has joined #bittorrent [23:13:18] *** comps has joined #bittorrent [23:15:30] <comps> hello everyone, I'm trying to understand how DHT and PEX actually works, I get the concept of XOR routing and other thing (which are well explained everywhere on the web), but what I really don't get is initialization of actual connection to a network, the layer-3 (IP) part of it. [23:16:23] <comps> I mean - there's a whole lot of IP addresses and incredibly more in IPv6 addressing space and I keep wondering how a client can actually find the initial bootstraping node without any file/address known before (or hardcoded) [23:17:34] <comps> I can imagine a hardcoded DNS name with A entries changing frequently, but that's not _really_ decentralized, ... [23:17:41] <DWKnight> the top-end clients normally hardcode a bootstrap [23:17:53] <DWKnight> and include methods to add alternative bootstrap nodes if necessary [23:19:17] <anakh> .torrent files can include a list of dht nodes [23:19:40] <anakh> and once you have contact with one/a few nodes your connectivity quickly grows [23:21:03] <comps> anakh: yeah, I get the concept of the actual layer-4 network (ie. once you find one node, it's theoretically possible to ask it about others), but I wasn't able to imagine HOW a client can find this node in entire IP addressing space [23:21:16] <anakh> just ran a quick test with my dht code [23:21:28] <anakh> just started out with 1 random node [23:21:34] <anakh> <1min and it knows 1k nodes [23:21:43] <anakh> 2k now [23:22:08] <anakh> like ppl said [23:22:10] <DWKnight> depends on your bootstrap method [23:22:11] <comps> *sighs* [23:22:18] <anakh> hardcoded bootstrap nodes [23:22:25] <anakh> DHT nodes included in .torrent files [23:22:56] <anakh> and i also think modern clients exchange dht nodes when theyve connected via a normal tracker, correct me if im wrong here.. [23:23:05] <anakh> (does PEX also do DHT nodes for example?) [23:24:01] <comps> so .. if I have only a magnet link with no .torrent file, the client has to use it's hardcoded bootstrap server (ie. it's DNS/IP) in order to obtain the initial information? [23:24:17] <anakh> ya but thats very rarely the case in real life [23:24:42] <anakh> 5688 DHT nodes found now.. will exit client so i can continue coding on it :) [23:24:47] <comps> right, thanks, I was just wondering why is my client able to work this way [23:25:30] <anakh> and remember, once you establish communications with even a single DHT node you quickly get lots and lots more [23:26:08] <comps> I said I got the layer4 protocol concept :) .. [23:26:28] <anakh> yeah but thats also important to remember to understand how the bootstrapping is done .. :) [23:26:43] <The_8472> you're forgetting 1 important aspect [23:26:48] <The_8472> cached routing tables [23:27:03] <comps> just the IP part wasn't clear for me ... as it's impossible to simply broadcast (or something like that) a request for invitation into the whole internet addressing space [23:27:20] <The_8472> theoretically yes, practically no [23:27:32] <comps> sure [23:27:38] <anakh> you could do multicast at your local isp if they support it [23:27:46] <The_8472> few do [23:27:46] <anakh> there's some protocol to find peers that way [23:28:36] <anakh> and well.. with a decent connection you could practically try speaking dht with all routed ipv4 space in a few days.. [23:28:38] <The_8472> anyway, while this may be a philosophical issue... as implied in the term boostrapping... pulling oneself out of the swamp by the bootstraps [23:28:48] <The_8472> it's not a practical concern since you can just use any node to join [23:29:09] <anakh> hah is that where the term comes from? i mustve heard it the first time 15 years ago or so :P [23:30:11] <anakh> closest association i could tihnk of was strapping as in changing/installing jumpers [23:31:55] <anakh> we should all use the good old term IPL instead. [23:33:30] <comps> well, thanks for the info and have a nice day/night :) [23:34:43] <anakh> wtf, should be IPLed .. too quick with s/ [23:35:05] *** comps has left #bittorrent [23:39:02] <Andrius> pinging all ipv6 IPs on all ports would be a fun way to bootstrap [23:39:48] <anakh> on the more realistic side sweeping all routed ipv4 space on standard ports is very very doable [23:40:14] <anakh> tends to generate abuse email though :P [23:42:00] <The_8472> Andrius... boiling the oceans and all.. [23:45:35] *** HandheldPenguin is now known as HandheldPenguin` [23:46:49] * Andrius starts pouring hot water into nearby river with hope that it will help him bootstrap IPv6 DHT [23:47:37] <TheSHAD0W> Um. [23:47:58] <TheSHAD0W> Just create a torrent w/ a small text file, and ask some IPv6 users to seed it. [23:48:18] <The_8472> or just use the ipv6 dht bootstrap nodes [23:48:20] <anakh> everyone should agree on a range for IPLing (:P) decentralized protocols, in the /64 anad /48 networks of ipv6 [23:49:00] <Andrius> TheSHAD0W, I'd need to have working IPv6 connection for that [23:49:09] <The_8472> 6to4 [23:49:10] <TheSHAD0W> ... [23:49:21] <TheSHAD0W> No, you'd just need to talk to some people w/ working IPv6 connections. [23:49:39] <TheSHAD0W> Is there a ##ipv6 here? [23:49:45] <Andrius> #ipv6 [23:49:56] <TheSHAD0W> Well, ask some people there. [23:50:20] <anakh> you just need someone with say a few spare /64's to set up a tunnel [23:50:42] <The_8472> 6to4! [23:50:55] <anakh> thats how i ran ipv6 back in the 3ffe:: days [23:50:59] <Andrius> I know how to setup 6to4, but currently I'm stuck behind a router that doesn't know anything about ipv6 [23:51:11] <The_8472> use custom firmware then [23:51:40] <The_8472> that's what i'm doing [23:51:51] <The_8472> 6to4 on the router + teredo on windows ^^ [23:52:02] <The_8472> so can even test multihoming [23:53:35] <anakh> doesnt f.ex. openvpn support v6 [23:53:43] <anakh> so you can run it from behind anything [23:58:12] *** Elrohir has quit IRC