[00:37:08] *** waldorf_ has joined #bittorrent
[00:37:29] *** anakh has joined #bittorrent
[00:42:33] *** chelz has joined #bittorrent
[01:13:06] <anakh> hey what is 'v' in DHT (from utorrent) ?
[01:13:15] <anakh> 00000020  65 31 3a 71 34 3a 70 69  6e 67 31 3a 74 34 3a 01  |e1:q4:ping1:t4:.|
[01:13:18] <anakh> 00000030  00 00 00 31 3a 76 34 3a  55 54 42 c3 31 3a 79 31  |...1:v4:UTB.1:y1|
[01:24:46] *** morgajel has joined #bittorrent
[01:24:55] *** K`Tetch has quit IRC
[01:25:01] *** K`Tetch_ has joined #bittorrent
[01:25:43] <The_8472> version number
[01:26:07] <The_8472> it's an optional field
[01:26:17] <The_8472> with no well-defined meaning
[01:26:37] <The_8472> but the convention is 2 ascii bytes, 2 bytes in some binary encoded number
[01:26:39] <The_8472> usually...
[01:27:13] <morgajel> so I'm trying to make the maketorrent-console app create a torrent for some files with non-ascii names, such as Ang?lica.iso, and it's spitting out the following: to utf-8 ('utf8' codec can't decode bytes in position 3-5: invalid data). Either theassumed filesystem encoding "UTF-8" is wrong or the filename contains illegal bytes.
[01:27:17] <anakh> k
[01:27:22] <morgajel> any suggestions on what I can do to get around it?
[01:27:39] <morgajel> I thought trying --filesystem-encoding UTF-16 would work, but nope
[01:28:56] <morgajel> I haven't had much luck finding documentation on --filesystem-encoding
[01:29:56] <The_8472> try ISO-8859-15
[01:29:59] <The_8472> that might work
[01:30:27] <morgajel> BitTorrent.BTFailure: unknown key --filesystem-encoding
[01:30:53] <morgajel> along with the regular python stacktrace
[01:34:34] *** gilles has joined #bittorrent
[01:46:01] *** init0_ has joined #bittorrent
[01:54:40] *** gf__ has joined #bittorrent
[01:57:38] *** init0 has quit IRC
[02:00:52] *** bittwist has joined #bittorrent
[02:11:59] *** SundanceKid has quit IRC
[02:12:56] <TheSHAD0W> You know, I just realized something.
[02:12:57] <TheSHAD0W> The_8472.
[02:13:05] <The_8472> ?
[02:13:20] <TheSHAD0W> Scrape is a pretty valuable metric, right?
[02:13:43] <TheSHAD0W> Would you dump your DHT in favor of something that could give a better metric?
[02:14:35] <TheSHAD0W> And would be more resilient against exploits.
[02:14:55] <The_8472> if you mean the azdht? i'm not making policy decisions. but i'm always interested in improving things
[02:15:00] <The_8472> so just spill it
[02:15:26] <TheSHAD0W> The mole was working on a network that could do it.
[02:15:35] <TheSHAD0W> "mole2" on here.
[02:15:45] <TheSHAD0W> (Hasn't been on for a couple of days.)
[02:15:59] <The_8472> yeah, i talked with him about it, randpeer i think. it is an interesting approach
[02:16:17] <The_8472> but that was years back
[02:16:21] <The_8472> i haven't heard of any progress
[02:16:24] <TheSHAD0W> Well, I just remembered a conversation I had with him.
[02:16:34] <TheSHAD0W> He had some very interesting statistics gathering routines.
[02:16:53] <The_8472> ah yeah, some log-scaled averages stuff
[02:17:31] <TheSHAD0W> One real benefit to BitTorrent is the statistics.
[02:17:52] <The_8472> yup, scrapes are a good indicator for the swarm's state
[02:18:13] <The_8472> though piece distribution graphs are even better... but you can only generate those while being connected to the swarm
[02:18:13] <TheSHAD0W> Not just that.
[02:18:36] <TheSHAD0W> It's an indicator for success, for the popularity of the item being transferred.
[02:18:58] <The_8472> well, that i don't care much about. but others might, yes
[02:19:04] <TheSHAD0W> Yeah.
[02:19:31] <TheSHAD0W> I think artists, even if they're pissed about their stuff being pirated, get a kick out of finding how popular they are.
[02:20:03] <TheSHAD0W> Not to mention finding indies based on their download stats.
[02:20:20] <The_8472> doesn't one of those "anti-p2p" firms even assess the success of content on p2p networks? ^^
[02:20:26] <TheSHAD0W> Without the stats I think BT gets an even worse (undeserved) reputation than it has now.
[02:21:40] <The_8472> well... i'm not interested in marketing. but scrapes have some direct, simple uses that are too good to be abandoned
[02:23:11] <The_8472> so yeah, as long as we can't decentralize that too DHT isn't a good alternative
[02:24:13] <anakh> ugg, im coding a benc decoder now :p
[02:24:22] <anakh> just awful :)
[02:24:26] <TheSHAD0W> LOL
[02:25:18] <The_8472> if you have a library that provides dynamically sized maps and you implement it recursively then it's quite trivial
[02:25:18] <DWKnight> rear-admaril reinvent-the-wheel?
[02:25:34] <anakh> dwknight: not reinventing the wheel, refactoring it !
[02:25:41] <anakh> the_8472: yah its just tedious :P
[02:25:54] <The_8472> well, so is writing any other parser...
[02:25:58] <TheSHAD0W> I still think you should look at the ones out there.
[02:26:21] <The_8472> i can only offer one in java ^^
[02:27:02] <anakh> lets see here
[02:27:09] <anakh> test 1: do they use esbuf? no
[02:27:13] <anakh> test 2: were they coded by me? no
[02:27:20] <TheSHAD0W> LOL
[02:27:21] <anakh> that's the two tests i universally apply to libraries
[02:27:35] <The_8472> so you basically write everything yourself?
[02:27:50] <The_8472> then why don't you invent a language with native.. er... esbuf support? ^^
[02:28:27] <anakh> one of my commercial development projects do involve its own language :P
[02:28:34] <anakh> although its highly specialized
[02:28:42] <anakh> turing complete though !
[02:29:06] <The_8472> turing completeness doesn't say anything about how practical it is
[02:29:12] <The_8472> brainfuck is turing complete too
[02:29:17] <anakh> its very practical for its intended application
[02:29:24] <anakh> and actually turing completeness was a relatively late 'feature' in it
[02:29:28] <anakh> no loops before
[02:31:50] <anakh> uhm whats the correct term used in benc for the key:val entries
[02:31:52] <anakh> is it pairs ?
[02:32:26] <The_8472> dictionary entry, <key,value> pair, map entry...
[02:32:42] <The_8472> associative array index and value
[02:32:53] <The_8472> depends on your language ^^
[02:33:00] <anakh> dictionary entry would be kinda confusing
[02:33:19] <anakh> as it could both apply to the pairs themselves AND all data between a d and e
[02:33:21] <The_8472> well, name it after the data structures in your libs
[02:33:39] <anakh> hm good point
[02:33:41] <anakh> entry it is then
[02:55:14] *** chelz has quit IRC
[02:55:14] *** DWKnight has quit IRC
[02:56:58] *** chelz has joined #bittorrent
[02:56:58] *** DWKnight has joined #bittorrent
[03:07:29] <Astro> I can hand you a benc module for erlang :)
[03:07:46] <TheSHAD0W> ...
[03:07:47] <TheSHAD0W> NO WAI!
[03:09:48] <TheSHAD0W> Did you write a client for it?
[03:10:02] <alus> hopefully just a tracker...
[03:10:12] <anakh> i still vote for os/360 !
[03:10:36] <alus> os/360 == 0
[03:11:14] <anakh> what's z/os then?
[03:11:37] <anakh> must be undefined!
[03:11:40] <anakh> or infinite!
[03:11:46] <Astro> really, just a tracker
[03:12:19] <TheSHAD0W> anakh: Did you ever see the mathematical proof that women are evil?
[03:12:39] <The_8472> it's oooooold
[03:12:48] <The_8472> maybe even as old as the internet. but not even time is that old
[03:13:23] <TheSHAD0W> http://www.anvari.org/fun/Gender/Proof_that_Girls_are_Evil.html
[03:13:44] <anakh> that one is sooo fucking old
[03:13:44] <The_8472> yes, that's the one
[03:13:47] <anakh> :P
[03:13:48] *** gilles has quit IRC
[03:13:51] <alus> z/os == -2 if z == -2 and os == 1. 1/360 == 0 because of ints
[03:14:05] <anakh> i ustve seen it the first time -96 taped to someones door at stockholm university
[03:14:09] <anakh> language dept, mind you :)
[03:23:45] *** Miller` has quit IRC
[03:32:31] *** DWKnight has quit IRC
[03:32:32] *** chelz has quit IRC
[03:33:41] *** chelz has joined #bittorrent
[03:33:41] *** DWKnight has joined #bittorrent
[03:35:25] *** Miller` has joined #bittorrent
[03:44:05] *** The_8472 has quit IRC
[03:45:05] *** bt42 has joined #bittorrent
[03:47:03] *** Snoopotic6367 has quit IRC
[03:48:10] *** bittwist has quit IRC
[03:48:10] *** K`Tetch_ has quit IRC
[03:48:10] *** ivan` has quit IRC
[03:48:11] *** DeHackEd has quit IRC
[03:48:12] *** HandheldPenguin` has quit IRC
[03:48:59] *** bittwist has joined #bittorrent
[03:48:59] *** K`Tetch_ has joined #bittorrent
[03:48:59] *** ivan` has joined #bittorrent
[03:48:59] *** HandheldPenguin` has joined #bittorrent
[03:48:59] *** DeHackEd has joined #bittorrent
[03:50:52] *** stalled has quit IRC
[03:51:26] *** stalled has joined #bittorrent
[03:52:51] *** bittwist has quit IRC
[03:55:06] *** ivan` has quit IRC
[03:55:06] *** Handhelda has joined #bittorrent
[03:55:09] *** ivan` has joined #bittorrent
[03:55:36] *** HandheldPenguin` has quit IRC
[03:55:56] <anakh> a@flatline:~/dev/bt$ ./esbenc
[03:55:57] <anakh> type: dict
[03:55:57] <anakh> key: [d]'a'
[03:55:57] <anakh> type: str
[03:55:59] <anakh> key: [s]'id' = 'IIIIIIIIIIIIIIIIIIII'
[03:56:01] <anakh> type: dictend
[03:56:04] <anakh> <- dictionary
[03:56:06] <anakh> type: str
[03:56:09] <anakh> key: [s]'q' = 'ping'
[03:56:11] <anakh> type: str
[03:56:14] <anakh> key: [s]'t' = 'TTTT'
[03:56:16] <anakh> type: str
[03:56:19] <anakh> key: [s]'y' = 'q'
[03:56:21] <anakh> type: dictend
[03:56:24] <anakh> <- dictionary
[03:56:26] <anakh> so, works like a charm
[03:59:10] *** K`Tetch has joined #bittorrent
[04:01:35] *** DeHackEd has quit IRC
[04:01:35] *** K`Tetch_ has quit IRC
[04:03:41] *** K`Tetch_ has joined #bittorrent
[04:03:41] *** DeHackEd has joined #bittorrent
[04:03:48] *** bittwist has joined #bittorrent
[04:07:27] *** bittwist is now known as Guest56740
[04:07:54] *** DWKnight has quit IRC
[04:07:54] *** chelz has quit IRC
[04:08:11] *** K`Tetch_ has quit IRC
[04:08:31] *** DWKnight has joined #bittorrent
[04:08:36] *** chelz has joined #bittorrent
[04:10:41] *** bittwist has joined #bittorrent
[04:14:49] *** Guest56740 has quit IRC
[04:25:46] *** bittwist has quit IRC
[04:25:55] *** bittwist has joined #bittorrent
[04:27:27] *** bbelt16ag has quit IRC
[04:28:44] *** bt42 has quit IRC
[05:33:37] *** A9 has joined #bittorrent
[05:33:54] *** A9 has quit IRC
[06:05:48] *** flexible has joined #bittorrent
[06:06:07] <flexible> i've recently set up ubuntu 9.10 on an old computer to work as a headless fileserver, however torrentflux seems to only manage up to 16~kbps, whereas my iMac, on the same network, manages to acheive up to 1.2megs a second... can anyone help me work out what is wrong?
[06:37:56] <chelz> flexible: are you sure ports are forwarded
[06:38:19] <flexible> yes
[06:39:01] <chelz> flexible: is it connected to the network in the same way your imac is
[06:39:08] <chelz> as in wired or wireless
[06:41:46] <flexible> wired... i just tried transmission and i'm getting 350~kbps...
[06:41:57] <flexible> don't know what is wrong with torrentflux
[06:58:27] <K`Tetch> settings probably
[07:13:52] <Miller`> flexible: I've tried that setup before, and found it far better to use uTorrent's web gui instead of torrentflux
[07:35:58] <chelz> rtorrent from anywhere works fine for me
[07:42:12] *** SundanceKid has joined #bittorrent
[07:42:37] *** gf__ has quit IRC
[07:43:54] *** DeHackEd has quit IRC
[07:44:50] *** DeHackEd has joined #bittorrent
[07:45:20] *** stalled_ has joined #bittorrent
[07:46:05] *** stalled has quit IRC
[07:46:24] *** stalled_ is now known as stalled
[07:56:50] *** anakh has quit IRC
[08:16:28] *** Firon_ has joined #bittorrent
[08:19:56] *** Firon has quit IRC
[08:30:45] *** anakh has joined #bittorrent
[09:02:21] <erdgeist> http://erdgeist.org/BT-Clients.pdf
[09:08:47] *** Switeck has quit IRC
[09:23:37] *** waldorf_ has quit IRC
[09:35:51] <Miller`> erdgiest: how accurate is that? I had the impression that Azureus had a lot more of a share...
[09:36:01] <anakh> ugh... 300 lines of code all wasted on ... benc :D
[09:36:55] *** Miller`` has joined #bittorrent
[09:37:58] *** Miller` has quit IRC
[09:38:03] *** Miller`` is now known as Miller`
[09:38:17] <anakh> finished the decoding a few hours ago, now returned and wrote the actual recursive function that will be whats called
[09:38:23] *** Miller`` has joined #bittorrent
[09:38:46] <anakh> but now im too tired to continue with what i needed the benc decoder for !#!@
[09:44:49] <chelz> [citation needed] on that pdf
[09:45:02] <chelz> the high amount of Unknown is pretty interesting if true
[09:45:26] <Miller`> I agree on both points
[10:06:53] *** waldorf_ has joined #bittorrent
[10:11:15] *** MassaRoddel has joined #bittorrent
[10:35:04] *** Firon_ has quit IRC
[10:37:54] *** Firon has joined #bittorrent
[10:51:23] *** tris has quit IRC
[10:53:15] *** tris has joined #bittorrent
[11:06:42] *** waldorf_ has quit IRC
[11:06:46] *** waldorf_ has joined #bittorrent
[11:07:47] *** Waldorf- has joined #bittorrent
[11:14:11] *** waldorf_ has quit IRC
[11:15:38] <anakh> who's the official maintainer of dht btw?
[11:16:56] *** Firon has quit IRC
[11:17:25] *** Firon has joined #bittorrent
[11:20:37] *** uriel has quit IRC
[11:20:49] *** uriel has joined #bittorrent
[11:39:42] <chelz> anakh: there's the bep then there are disparate implementations soo.. take your pick
[11:55:22] <anakh> someone should add, for example, protection against using dht nodes as DoS amplifiers :P
[11:59:21] <anakh> could easily prevent that and add some crypto at the same time
[11:59:39] <chelz> eh that's just overhead at this point
[11:59:59] <chelz> there are so many ways it could all be exploited or used for nefarious means, but it hasn't happened, so there isn't really any push
[12:00:01] <anakh> ok s/add some.*// then!
[12:00:03] <anakh> haha
[12:00:05] <anakh> famous last words
[12:00:22] <chelz> most big trackers for projects out there are using software that's 2-5 years old
[12:00:31] <chelz> stuff like eclipse, ubuntu, fedora
[12:00:45] <anakh> and your point is?
[12:01:17] <anakh> one of my primary desktop OSes is 10 or so years old
[12:01:45] <chelz> i use that as an example for how people seem to like things the way they are
[12:02:00] <chelz> i'm not saying it's good or bad, just that it's the case
[12:02:30] <anakh> not realy comparable
[12:02:36] <anakh> 2 or 5 or 10 year old software can be perfectly secure
[12:02:41] <chelz> what's your 10 year old OS?
[12:02:47] <anakh> sol8
[12:02:53] <chelz> ah wild
[12:03:13] <anakh> hey until early 2005 my primary box was a sparcstation5 with sol 2.6 :p
[12:03:54] <anakh> i alternated between that and a laptop with qnx for many years
[12:04:39] <chelz> what editor?
[12:05:29] *** fireba11 has quit IRC
[12:05:31] <anakh> mostly joe
[12:05:36] *** fireba11 has joined #bittorrent
[12:05:51] <anakh> since it reminds me of DOS EDIT which probably still is the one i've written the largest part of my code in
[12:06:21] <chelz> that's some dedication
[12:06:25] <anakh> qnx has a really nice IDE though but i havent had time to run much else than plain linux for the past couple of years :/
[12:06:35] <anakh> qnx is actually great when developing because it's strictly posix
[12:06:46] <anakh> if something works on qnx it works on everything resembling *ix
[12:10:36] <anakh> (ok, as long as you arent doing qnx specific shit :p)
[12:52:05] *** GTHK has quit IRC
[13:07:34] *** goussx_ has joined #bittorrent
[13:25:14] *** goussx has quit IRC
[13:25:15] *** goussx_ is now known as goussx
[13:49:08] *** PyroPeter has joined #bittorrent
[13:53:08] <PyroPeter> which protocol is used betwen bittorrent clients?
[13:58:30] <kjetilho> usually TCP/IP
[14:01:50] <PyroPeter> but there must be some higher protocol, most of the "magic" happens betwen clients
[14:04:22] <kjetilho> so you think there is a "magic" bittorrent protocol used on top of TCP/IP?
[14:04:37] <kjetilho> why, you are completely right :-)
[14:08:10] <PyroPeter> I dont actually get what you are trying to tell me :-P
[14:13:59] <void^> bittorrent clients use the bittorrent protocol which runs on top of tcpip
[14:14:06] <void^> but shh, 'tis a secret ;)
[14:19:14] *** rrr has quit IRC
[14:19:29] <PyroPeter> but why is there no documentation on the bittorrent.org page? there is just a bep about the boring tracker-thing
[14:21:23] <DWKnight> bep 3 covers more than just the tracker side of things
[14:26:30] <kjetilho> PyroPeter: http://lmgtfy.com/?q=bittorrent+protocol+specification
[14:58:38] *** anakh has quit IRC
[15:02:53] *** anakh has joined #bittorrent
[15:04:15] <anakh> one more question: what happens if a DHT peer at a specific ipaddr:port
[15:04:25] <anakh> a) presents different id's to different clients?
[15:04:42] <anakh> b) changes id? (this must happen a lot under normal usage..)
[15:09:27] <anakh> and uhm
[15:09:28] <anakh> In Kademlia, the distance metric is XOR and the result is interpreted as an unsigned integer. distance(A,B) = |A xor B| Smaller values are closer.
[15:09:42] <anakh> does that mean only the first 32 bits are compared
[15:09:46] <anakh> or is it folded first
[15:09:47] <anakh> or what
[15:36:13] *** Andrius has joined #bittorrent
[15:49:18] *** anakh has quit IRC
[16:24:52] *** anakh has joined #bittorrent
[16:24:58] *** anakh is now known as anakata
[16:42:47] *** Waldorf- has quit IRC
[17:29:53] *** The_8472 has joined #bittorrent
[17:58:47] *** Switeck has joined #bittorrent
[18:12:03] <burris> how do you use dht as a dos amplifier?
[18:16:04] <burris> anakata not only the first 32 bits, use an atribrary length integer
[18:17:06] <burris> or actually a 160 bit integer is enough
[18:17:34] <burris> but good languages have arbitrary length integers, try using one :-)
[18:19:08] <burris> and unless you've come up with something new, the token required to do a put stops dos attacks using the dht
[18:20:47] <anakata> anything that responds with a larger udp packet than was sent to it can be used for amplification
[18:21:26] <anakata> dns amping made a recurrence like 2 years ago
[18:21:35] <anakata> had a couple multi gig attacks coming in
[18:21:58] <anakata> all consisting of responses containing like tons of large txt records
[18:22:44] <anakata> just a simple dht ping can provide a decent amp ratio
[18:26:13] <burris> how would you prevent this attack?
[18:30:07] <anakata> make sure responses are always smaller than the queries until you have confirmed two-way comm
[18:30:30] <anakata> and rate limiting doesnt hurt either but i guess clients do that already ?
[18:30:55] <burris> yeah
[18:31:27] <burris> seems like there are easier ways than using BT dht
[18:33:19] *** _rafi2_ has joined #bittorrent
[18:36:28] <anakata> well it ha as an installed base of millions
[18:36:34] <anakata> and ip addrs are easy to find
[18:37:00] <anakata> so better fix any potenial issues before they are hit in the wild heh
[18:41:23] <The_8472> the amplification only would be based on packet sizes, not on the number of packets
[18:41:40] <The_8472> a really good DoS amplifier lets you create a storm of packets with 1 or a few
[18:42:23] * The_8472 doesn't see how this would be all too dramatic
[18:43:00] <anakata> might be some way to achieve really high amp with dht
[18:43:08] <anakata> will play with it later once my dht impl is done
[18:48:03] <TheSHAD0W> anakata: You may get multiple legitimate IDs from the same IP, from NAT'd peers.
[18:48:22] <burris> I did find a ref to dos amplification from 2001 rfc but it seems the first high profile amplification attacks happened earlier this year
[18:50:27] <burris> and one from 04 for sip uri-list servers
[18:51:34] <anakata> back when i was a dos kiddie i did amp attacks
[18:51:40] <anakata> and that was around 99 or so
[18:51:47] <anakata> 98-99
[18:51:54] <anakata> though it wasnt public / widespread by then
[18:52:05] <anakata> udp dns shit
[18:52:10] <burris> just wondering why it wasn't on the radar
[18:52:25] <anakata> because the computer security industry is a fucking joke?
[18:52:45] <burris> no shit
[18:52:51] <burris> everyone is a spook wannabe
[19:00:27] <anakata> famous last words: This vulnerability is not possible to exploit. :D
[19:13:28] *** _rafi2_ is now known as _rafi_
[19:13:57] *** Guest63573 has joined #bittorrent
[19:14:10] *** Guest63573 has left #bittorrent
[19:16:58] <anakata> hey dht gurus
[19:17:07] <anakata> does this dht ping response look ok
[19:17:24] <anakata> d1:t4:d...1:y1:r1:rd2:id20:DHThelper0DHThelper0ee
[19:17:52] <anakata> wtf it certainly doesnt
[19:17:56] <anakata> length is missing from a value
[19:18:34] <anakata> or nope, its ok, right?
[19:18:57] <anakata> i only do benc shit when i have trouble sleeping so it can be tricky to debug :PP
[19:20:44] <burris> what is type "d..." ?
[19:21:41] <burris> duh, that's tid... been a long time since I looked at any of this shit
[19:21:51] <anakata> 1:t == key
[19:21:56] <anakata> 4:d... == val
[19:22:04] <anakata> non-printable characters are escaped
[19:23:12] <The_8472> no, it doesn't look ok
[19:23:22] <The_8472> IDs should be selected at random
[19:23:27] <The_8472> 20 bytes binary garbage
[19:23:58] <burris> yeah, that's your position it the keyspace/routing-table
[19:24:18] <anakata> the_8472: well doh
[19:24:33] <anakata> this is just testing :p
[19:24:36] <The_8472> i mean it's selected once, when you start your node
[19:24:45] <anakata> yes yes i know i know
[19:25:18] <TheSHAD0W> What sort of asymmetries would be induced if it weren't entirely binary garbage?
[19:25:30] <TheSHAD0W> Is it run through SHA or something to rescramble it?
[19:25:32] <burris> it's easier to understand the packets if you print them in python or json format
[19:25:51] <The_8472> TheSHAD0W, no. the IDs are the IDs. they're not mangled in any way
[19:26:07] <TheSHAD0W> So what's the answer to my first question.
[19:26:09] <TheSHAD0W> What sort of asymmetries would be induced if it weren't entirely binary garbage?
[19:26:11] <anakata> that might be worth looking into actually
[19:26:19] <anakata> i bet a lot of stupid programmers use rand() seeded with time() etc
[19:26:32] <burris> if the id's aren't evenly distributed over the entire keyspace then you could end up with hotspots
[19:26:41] <The_8472> then you'd have serious problems because the DHT assumes a uniform distribution of nodes throught its keyspace
[19:26:54] <TheSHAD0W> That's a bad assumption IMO.
[19:27:03] <anakata> someone get a big lits of live id's
[19:27:09] <anakata> and lets do some stats analysis
[19:27:10] <burris> anakata yeah, you need more entropy than you get with time...  sha1 is frequently used in generating nonces to distribute the entropy over the entire 20 bits of the id
[19:27:14] <TheSHAD0W> I could see people throwing peer IDs in there.
[19:27:30] <anakata> like number of id's whose first bytes correspond to rand() seeded with a time() the past week :)
[19:27:31] <The_8472> the IDs are 20 bytes
[19:27:36] <The_8472> peer IDs don't fit
[19:27:52] <anakata> arent peer ids 20 bytes too
[19:27:55] <burris> anakata, that's why it's a good idea to run sha1 on your seed
[19:27:57] <anakata> havent coded bt in ages
[19:28:03] <The_8472> they're 8 bytes i think, no?
[19:28:06] <anakata> burris: yeah.. and use a good prng :p
[19:28:34] <anakata>     while (peer != NULL)
[19:28:35] <anakata>     {
[19:28:35] <anakata>       if (memcmp(peer->peer_id, akbuf_data(peer_id), ID_LEN) == 0) break;
[19:28:35] <anakata>       peer = peer->next;
[19:28:35] <anakata>     }
[19:28:48] <anakata> and ID_LEN is the len of info_hash and peer_id, i.e. 20
[19:28:55] <anakata> exactly what i remembered then
[19:28:57] <burris> anakata, well you don't need a prng since the sha1 takes care of distributing the entropy, the real trick is getting enough entropy which is historically difficult on windows, dunno how it is now
[19:29:01] <anakata> i also remember that they generally arent very random :P
[19:29:19] <anakata> burris: basically you need more than 20 bytes in..
[19:29:31] <anakata> but yeah sha1 would be your prng
[19:29:35] <TheSHAD0W> Hehe.
[19:29:45] <The_8472> first of all... use nano-time (most architectures have counters with a higher precision than unix time) to seed a PRNG...
[19:29:48] <burris> anakata, you need 20 bytes of entropy, how much entropy is in each byte of your seed depends on your source of entropy...
[19:29:52] <TheSHAD0W> You should see the code I wrote to try and randomize stuff.
[19:30:29] <TheSHAD0W> http://cvs.degreez.net/viewcvs.cgi/bittornado/BitTornado/__init__.py?rev=1.38&content-type=text/vnd.viewcvs-markup
[19:30:33] <burris> anakata, if your source has low entropy you may need much more than 20 bytes of seed
[19:31:21] <burris> The_8472, time, even with a high resolution source, doesn't have much entropy
[19:31:26] <The_8472> and right now 20 bytes of entropy aren't actually needed. about 4 bytes are sufficinent.
[19:31:38] <The_8472> since we only have about ~10 million nodes in the DHT
[19:31:43] <anakata> burris: ya exactly
[19:32:17] <burris> The_8472, true that, but estimating the actual entropy in your seed is difficult so overkill is a good idea
[19:32:21] <anakata> can dig out my old code for seeding crypto prngs on systems without urandom etc if anyone is interested
[19:32:46] <The_8472> considering that 86.400.000 milliseconds pass every day... nanonsecond resolution is sufficient atm
[19:32:47] <burris> then again, it isn't so important that the id is unpredictable as it is to be evenly distributed over the keyspace
[19:32:58] <anakata> ya
[19:33:02] <anakata> why not have the client store the current value
[19:33:10] <anakata> then next time it starts it does id=hash(value)
[19:33:18] <anakata> and saves that
[19:33:31] <burris> they pick and id and stick with it until the config data gets blown away
[19:33:35] <anakata> at the very least you'd get better distribution
[19:33:42] <The_8472> and guys, you're barking up the wrong tree. inventing PRNGs/entropy sources on the application level again and again is one of the pitfalls in computer security...
[19:33:52] <The_8472> use your OS/language primitives if you can
[19:33:58] <anakata> the_8472: now there now there... :)
[19:34:05] <anakata> this isnt a mission-critical crypto app :)
[19:34:15] <The_8472> it's still a common error
[19:34:21] <anakata> besides i happen to have enough knowledge to implement secure entropy sources :)
[19:34:42] <The_8472> sha1(constant + nanotime) = you're good for our purposes.
[19:35:25] <anakata> nanotime is windows specific though
[19:35:38] <The_8472> well, lunix has cpu counters too
[19:35:39] <anakata> and where the hell do they get it from considering x86 doesnt have any timer with that res :p
[19:35:49] <anakata> ya RDTSC
[19:36:10] <anakata> x86 specific though..
[19:37:16] <TheSHAD0W> 9_9
[19:37:20] <TheSHAD0W> Just found a bug in my code.
[19:38:19] <anakata> current tsc on my laptop is 0x0000038f1d4afddb btw :p
[19:38:31] <anakata> atleast according to 5 lines of ASM
[19:39:33] <The_8472> well, usually you combine the realtime clock + high resolution counter
[19:47:55] <anakata> like i said , should have the client save current id
[19:47:58] <anakata> then hash it again on next start
[19:48:01] <anakata> pref with new entropy
[19:48:51] *** _rafi2_ has joined #bittorrent
[19:50:37] <The_8472> or just keep the ID forever
[19:50:43] <The_8472> then you can reuse the old routing table too
[19:50:44] <TheSHAD0W> http://www.boingboing.net/2009/11/20/britains-new-interne.html
[19:51:03] <anakata> and run into potential delta isues later
[19:51:10] <The_8472> huh?
[19:52:14] <burris> if you pick a new id at start, you can reuse your old routing table, just take each entry and insert into your new routing table as normal...
[19:53:07] <The_8472> you can reuse far less entries since most of your old entries will end up in the root bucket and thus displace each other
[19:53:33] <burris> with churn most of your entries aren't any good anyway unless you stop and restart immediately
[19:53:55] <The_8472> or you have long-lived entries in your routing table... which is exactly how things work
[19:54:09] <The_8472> i have some that are are 4 days old. with a 16 hour downtime in between restarts
[19:54:14] <The_8472> so yeah
[19:57:18] *** _rafi_ has quit IRC
[19:58:54] <Andrius> <The_8472> well, lunix has cpu counters too < I'd very much prefer portable stuff, not lunix or windblows specific
[19:59:26] <The_8472> then use java
[19:59:30] <The_8472> or python
[19:59:41] <The_8472> or... whatever comes with a portable library that has a DECENT function set
[20:04:34] <anakata> ah, it does a nice little chat with utorrent in vmware now :P
[20:04:45] <anakata> had some routing issues before
[20:04:54] <anakata> + uttorrent has like 1k dht peers cached lol
[20:05:43] <anakata> 'a' = { 'id' = '.6Q.}M..nN.5.,R6....'; 'info_hash' = 'Ka.....&a........s].'; };
[20:05:46] <anakata> 'q' = 'get_peers'; 't' = '....'; 'v' = 'UTB.'; 'y' = 'q';
[20:05:51] <anakata> Log[d] got dht query 'get_peers'
[20:05:56] <anakata> 'id' = '.6Q.}M..nN.5.,R6....'; 'info_hash' = 'Ka.....&a........s].';
[20:10:09] *** KyleK_ has joined #bittorrent
[20:13:19] *** bittwist has quit IRC
[20:18:45] *** _rafi2_ has quit IRC
[20:24:38] <anakata> btw, the 't' of utorrent doesnt seem very random
[20:50:10] *** Andrius has quit IRC
[20:58:29] *** sdada1 has joined #bittorrent
[21:00:27] *** sdada1 has left #bittorrent
[21:03:18] *** Andrius has joined #bittorrent
[21:03:56] *** PyroPeter has left #bittorrent
[21:12:08] <anakata> what happens when i present myself as a different ID depending on the querying ip addr
[21:13:19] <The_8472> that would make lookups more inefficient
[21:14:34] <anakata> well atm im not building a standard dht node :)
[21:14:37] *** klapaucjusz has joined #bittorrent
[21:14:52] <The_8472> it would make other people's lookups inefficient
[21:15:44] <anakata> my goal is to cache for example all infohash->peer data i can
[21:16:06] <The_8472> for what purpose?
[21:16:20] <anakata> and act more or less like a tracker, having torrents list my addr(s) in nodes
[21:16:59] <anakata> well it'll either be best or worst of both worlds, tracker-based and tracker-less :)
[21:17:05] <The_8472> so when a single node goes down then not just a small fraction of the keyspace loses 1/8th of the redundancy but all of your "tracked" nodes do?
[21:17:08] <The_8472> yeah, bad idea...
[21:17:53] <anakata> its not like normal dht will be disabled :p
[21:18:03] <anakata> also it can be way efficient bootstrapping
[21:18:33] <The_8472> no, bootstrapping does not require any special node IDs
[21:18:37] <The_8472> any node can do that
[21:19:05] <anakata> unique node id part is just an experiment in the experiment :)
[21:20:03] <The_8472> only 8 nodes store data for each individual torrent
[21:20:14] <anakata> i know the protocol
[21:20:16] <The_8472> if you insert yourself into all torrents you take away 1/8th of the redundancy
[21:20:27] <The_8472> if 8 people do that then 8 nodes effectively control the entire DHT
[21:20:32] <The_8472> IT'S A STUPID IDEA
[21:20:49] <klapaucjusz> Ehm...
[21:20:53] <klapaucjusz> What's that about?
[21:21:20] <klapaucjusz> Someone wants to do Kademlia in constant time?
[21:21:24] <klapaucjusz> ...but linear space?
[21:21:34] <anakata> no just me doing my favorite thing
[21:21:41] <anakata> i.e. (ab)using protocols in ways they werent meant to
[21:21:42] <klapaucjusz> Hi anakata.
[21:21:55] <klapaucjusz> Nice to meet you.
[21:22:20] <klapaucjusz> There's a comment dedicated to you in some software of mine.
[21:22:26] <klapaucjusz> It says "damn anakata".
[21:22:41] <klapaucjusz> But coming back -- what exactly are you trying to do?
[21:22:44] <anakata> polipo ?
[21:22:47] <klapaucjusz> Aye.
[21:22:50] <klapaucjusz> ;-)
[21:22:58] <anakata> i did fix that misbehaviour though! :D
[21:23:06] <klapaucjusz> Yeah, I know.  It was a long time ago.
[21:23:15] <anakata> i still remember it though! :D
[21:23:16] <klapaucjusz> Coming back to the DHT?
[21:23:22] <anakata> ya
[21:23:24] <anakata> playing around a bit
[21:23:58] <anakata> my current experiment is creating a sort of supernode on torrent sites
[21:24:28] <klapaucjusz> Go on.
[21:24:55] <anakata> would be inserted into 'nodes' in the .torrents
[21:25:16] <anakata> and brutally rape DHT
[21:25:56] <anakata> end result is either some interesting chaos or a better user experience
[21:26:36] <burris> t key doesn't need to be random, it's just so the querying node can differentiate between requests to the same node
[21:27:01] <anakata> burris: isnt there some dos amp possiblities when you can guess t
[21:27:13] <burris> how?
[21:27:42] <anakata> find_node / get_peer queries that provide largest possible response ?
[21:27:56] <anakata> just checking
[21:28:17] *** ajaya has joined #bittorrent
[21:29:29] <The_8472> <anakata> would be inserted into 'nodes' in the .torrents <- good thing that that doesn't gurantee that you get inserted in the routing table... or even contacted
[21:29:37] <anakata> ya i know
[21:29:55] <anakata> would be a good start for new clients though
[21:30:47] <klapaucjusz> What's the goal of the operation?
[21:30:55] <anakata> to see what happens?
[21:31:08] <klapaucjusz> So you'd have multiple node ids?
[21:31:14] <klapaucjusz> How'd that function?
[21:31:49] <burris> anakata, new clients probably won't either unless there is no tracker since peers bootstrap from connected peers using the port message
[21:32:06] <anakata> burris: it does get req'd in my testing with uT atleast
[21:32:16] <burris> sounds like a bug
[21:32:46] <anakata> klapaucjusz: can easily have a different node id for each host:port it listens on
[21:32:50] <anakata> no problem
[21:33:03] <klapaucjusz> anakata: that's sick.
[21:33:24] <klapaucjusz> (Said with admiration.)
[21:34:06] <anakata> hell i'm the guy who wrote a BT tracker with its own stateless tcp stack .. so dont complain about THESE _minor_ standards violations :)
[21:34:22] <The_8472> minor?
[21:34:31] <The_8472> sending a different node ID on every request is minor? oO
[21:34:55] <klapaucjusz> It's not even a standards violation.
[21:35:13] <klapaucjusz> He's just pretending to be a whole herd of nodes.
[21:35:14] <anakata> the_8472: thats just testing to see what happens though!
[21:35:25] <The_8472> if 1 node does it... not much
[21:35:39] <anakata> the_8472: but i will do unique nodeid per listenaddr:port
[21:35:45] <The_8472> if a few dozen nodes do it in a well-coordinated manner.. the DHT breaks
[21:35:49] <anakata> ya
[21:36:04] <klapaucjusz> Yep.
[21:36:18] <klapaucjusz> anakata: what are you sending in the v field?
[21:36:28] <anakata> currently dont set it
[21:36:34] <klapaucjusz> Please do.
[21:36:40] <klapaucjusz> So we can blacklist you automatically ;-)
[21:36:55] <anakata> should it be "ACHTUNG!" ? :)
[21:37:04] <klapaucjusz> No, you're limited to 4 octets.
[21:37:15] <anakata> well you wont see me unless you are supposed to so dont worry :)
[21:37:38] <anakata> its not like im sneeking this into the global dht :)
[21:37:45] <klapaucjusz> Ah?
[21:37:53] <klapaucjusz> Sorry, I'm lost.  I missed the beginning of the discussion.
[21:37:57] <klapaucjusz> Could you please summarise for me?
[21:38:48] <The_8472> well, trying to break the mainline DHT is sortof pointless. it's as well-protected as the purse of an 80yo granny in a gang-infested street at night
[21:38:48] <anakata> my [crazy] idea is that for a specific set of torrents / tracker / etc provide a sort of supernode
[21:38:57] <anakata> one damn good reason is that dht is much more efficient than standard bt protocol
[21:39:12] <The_8472> DHT is actually less efficient
[21:39:15] <anakata> the_8472: not trying to break anything with this, dont worry :p
[21:39:27] <The_8472> it takes 60-100 requests + replies for an uncached lookup
[21:39:47] <anakata> im talking from a single node getting requests perspective
[21:41:50] <The_8472> you still fail to demonstrate the necessity for such a "supernode". not to mention that it probably does more harm than good
[21:42:00] <anakata> its for a specific application
[21:42:15] <anakata> not some new worldwide thing :)
[21:42:24] <klapaucjusz> The_8472: that's not a reason not to play with new ideas.
[21:42:45] <The_8472> it's a reason not to play with a live system
[21:43:13] <burris> how is mainline dht vulnerable "as the purse of an 80yo granny in a gang-infested street at night?"
[21:44:18] <klapaucjusz> Off topic: what's TCP port 121?
[21:44:27] <The_8472> let's see... it doesn't specify tiered lookups. so hijacking lookups to arbitrary keys is quite easy by returning nodes lists that point to nodes closer to the requested target than any other node
[21:44:32] <anakata> the_8472: its not like it'll try to take over global dht :p
[21:44:41] <The_8472> this way you can divert many lookups
[21:45:04] <The_8472> then you can inject your nodes at arbitrary IDs. plenty of them and thus take over that particular keyspace section
[21:45:05] <klapaucjusz> Simple workaround: we should not accept multiple nodes in our routing table with the same IP.
[21:45:07] <The_8472> and this goes on
[21:45:20] <klapaucjusz> Won't work in IPv6, but should be a fairly good defense in IPv4.
[21:45:22] <The_8472> there comes IPv6...
[21:45:41] <The_8472> or even anti-p2p companies with a handful of /24s
[21:45:53] <anakata> i'd be most worried about the latest actually
[21:45:53] <The_8472> that gives you more IPs than nodes in the routing table of a node
[21:45:58] <burris> picking an arbitrary id was intentional design decision
[21:46:28] <The_8472> burris, so? i answered your question, that being intentional or not doesn't change anything
[21:46:46] <klapaucjusz> The_8472: are there any defenses in AzDHT?
[21:47:23] <burris> well I don't consider it to be a vulnerability, remember bittorrent isn't designed for warez
[21:47:48] <klapaucjusz> burris: that's not a question of warez vs. Linux distributions.
[21:48:10] <klapaucjusz> 8472 is right, the DHT is very easy to disrupt.
[21:48:15] <The_8472> klapaucjusz, yes.
[21:48:16] <burris> who is attacking linux distros?
[21:48:26] <anakata> anyone could be attacking global dht
[21:48:42] <klapaucjusz> The_8472: care to be more eloquent?
[21:48:55] <anakata> because they dont like the political / philosophical / religious / whatever-stuff that someone dists over it
[21:49:19] <The_8472> we derive node IDs for ips, lookups work with generations, there is some verifying of neighbors and that they store replicated data and other things i don't remember
[21:50:30] <The_8472> <burris> well I don't consider it to be a vulnerability, remember bittorrent isn't designed for warez <- so it's ok that your linux distro DHT entry gets killed off as collateral damage in people attacking the DHT to stop warez distribution?
[21:50:44] <The_8472> with the DHT everyone is in the same boat
[21:50:45] <burris> yup
[21:50:54] <burris> no, linux distros have trackers
[21:51:01] <burris> so attacking the DHT won't do too much
[21:51:09] <burris> it's only a backup
[21:51:26] <burris> and that's probably why nobody has bothered to really attack it
[21:51:51] <burris> I got over the trying-to-make-it-s00per-secure crap long ago, so did bram
[21:52:39] 
[21:52:53] <anakata> you can find the correct reliability / security / usability tradeoff though
[21:53:04] <burris> we thought people would use DHT for trackerless torrents but it turns out that people don't want trackerless torrents, people like trackers/index servers
[21:53:18] <anakata> and working with distributed systems are a very pleasing challenge :)
[21:53:31] <The_8472> burris, that's because the DHT has shortcomings
[21:53:41] <burris> anakata I believe we did find the correct tradeoffs
[21:53:56] <burris> anakata of course it's not perfect but I think the DHT has done very well over the last five years
[21:54:10] <anakata> ya as a compliment
[21:54:53] <burris> The_8472, uh no, people like control and community  which is precisely the reason BT won out over kazaa, ed2k, etc...
[21:55:05] <anakata> but figure some suit at the MAFIAA presents some half made up numbers to his superiors about how much $$$ is being lost to this new method of stealing movies and avoiding the law
[21:55:09] <The_8472> burris, that happens on indexing sites, not on trackers
[21:55:43] <anakata> or someone with some time/resources gets pissed off about some highprofile material thats being distributed via bt
[21:55:46] <anakata> etc
[21:55:58] <burris> if you're running an index site, why not a tracker too?  virtually all indexing sites are trackers...  indeed, why have a private flag if not to tie the tracker to the index site?
[21:56:15] <The_8472> ... *points at tpb, isohunt and mininova*
[21:56:19] <anakata> burris: legal reasons ?
[21:56:45] <burris> yeah, warez sites suffering legal attacks, precisely what the DHT is not designed for
[21:56:59] <The_8472> and who cares about private torrents, they're opposed to any progress including DHT anyway
[21:57:14] <K`Tetch> mostly run by morons
[21:57:21] <anakata> well currently they are attacking totally open trackers without any warez index sites too
[21:57:25] <The_8472> burris, chinese firewall...
[21:57:41] <burris> bittorrent isn't a publishing system for dissidents, never has been and never will be
[21:57:47] <K`Tetch> I love the statement that was made that 'lots of clients ignore private flags, including bitcomet and birlord' made to me by a private tracker admin
[21:58:07] <klapaucjusz> burris: it isn't. Agreed.
[21:58:25] <klapaucjusz> However, we'd like BT to be resilient, both to temporary network outages and hostile attacks.
[21:58:27] <The_8472> burris that means it's not necesary to harden it against arbitrary censorship?
[21:58:53] <klapaucjusz> The_8472: let us not discuss what we want it to be resilient against.
[21:58:59] <burris> we're back to the tradeoffs...  we made our tradeoffs, you made yours but look at what the market said
[21:59:05] <klapaucjusz> What we can all agree about (hopefully) is that we want it to be resilient.
[21:59:26] <klapaucjusz> I think we can also agree that having two distinct methods of locating peers makes the protocol more, not less, resilient.
[21:59:49] <burris> it is resilient, maybe not as resilient as possible or as you like but it does appear to work
[21:59:51] <The_8472> burris, rofl... now you're acting stupid. the market does not evaluate everything based on a single factor...
[22:00:59] <The_8472> marketing and FUD play a role there too you know
[22:01:03] <anakata> people go to some *great pains* to prevent/slow distribution of all sorts of material they dont like
[22:01:06] <anakata> i mean
[22:01:39] <anakata> i've had someone hack a US ISP and announce more specifics for one of our prefixes in BGP
[22:01:42] <anakata> just to get a web server offline
[22:02:11] * klapaucjusz wonders who that market person is, and what methods he uses to evaluate network protocols.
[22:02:13] <burris> hey, if you want a more resilient dht go ahead and build one but don't think that the current dht is the way it is due to ignorance or a mistake
[22:02:21] <anakata> i can easily see *someone* *somewhere* seeing something they dont like distributed via bt/dht and deciding to bring it down
[22:02:39] <anakata> burris: ah no no, i dont
[22:02:42] <burris> the amplification of pings was ignorance/mistake though
[22:02:58] <klapaucjusz> burris: ?
[22:03:15] <burris> lack of version was also a mistake
[22:03:18] <anakata> besides, like i said earlier, its a very interesting field to work with
[22:03:31] 
[22:03:31] <The_8472> burris, so you're saying you took the horribly bad khashmir DHT, then evaluated everything and found it perfectly suitable for decentralized torrents
[22:03:45] <The_8472> and now that nobody really wanted to use decentralized torrent for years
[22:03:45] <burris> sure is interesting
[22:04:00] <burris> we thought people wanted trackerless torrents but it turns out they don't
[22:04:02] <The_8472> you just retcon your goals to "just a backup solution"
[22:04:23] <The_8472> instead of improving things that decentralized torrents are actually viable
[22:04:27] <anakata> holy shit guys.. shut this up and start designing/coding stuff instead :p
[22:04:32] <burris> hehehe
[22:06:13] <The_8472> and if you considered everything you wouldn't have to ask
[22:06:14] <The_8472> <burris> how is mainline dht vulnerable "as the purse of an 80yo granny in a gang-infested street at night?"
[22:09:49] * klapaucjusz is busy adding code to Transmission to check the reverse DNS of every DHT node and blacklist it if it belongs to anakata
[22:09:57] <anakata> hahahaha
[22:10:21] * The_8472 doesn't like the "nobody got anything to hide, there is nobody out there to get you and security is not important at all"-threat model
[22:10:23] <anakata> like i said, you wont ever see them :p
[22:11:06] <anakata> i dont even have any dht nodes active in the global network atm
[22:12:39] <anakata> but watch it or i'll view that as a challenge to connect from as many different prefixes and locations as possible .... :)
[22:13:06] <The_8472> http://torrentfreak.com/novell-strips-bittorrent-dht-technology-from-opensuse-091122/ <- lol, speak of the devil
[22:13:58] <klapaucjusz> http://trac.transmissionbt.com/ticket/2222
[22:14:22] <anakata> next dht related project would probably be developing abuse/misbehaviour-resiliant stuff
[22:15:40] <klapaucjusz> http://trac.transmissionbt.com/attachment/ticket/2579/0001-Make-logging-message-more-informative.patch
[22:16:03] <The_8472> hahahahaaha
[22:24:37] <anakata> and oh for my dear paranoid sirs information, all my dev is done on ipaddrs that arent glbally routed :p
[22:24:59] <anakata> they arent rfc1918 but they wont be appearing in any routing table :P
[22:27:49] * klapaucjusz adds code to Transmission to drop any nodes that aren't RFC 1918.
[22:28:20] <The_8472> maybe he's using multicast instead!
[22:28:37] * klapaucjusz adds code to Transmission to drop any nodes that use multicast.
[22:29:34] <anakata> hahahah
[22:29:35] <alus> haha, opensuse
[22:30:08] <anakata> this netblock is more like bureaucast
[22:30:30] <anakata> left over from some reorganization involving a lot of papers being turned
[22:31:04] <anakata> and ended up reserved @ ripe
[22:33:31] <anakata> its pre-RIPE so i guess it got lost in time or sth
[22:33:53] <anakata> fully authorized to use it internally by the registry of course!
[22:42:30] <klapaucjusz> Somebody is sending me DHT ping packets with a 1-octet transaction-id.
[22:42:37] <klapaucjusz> First time I see that.
[22:42:52] <The_8472> well, then they can only do 256 requests concurrently...
[22:43:05] <klapaucjusz> Not necessarily.
[22:43:16] <klapaucjusz> Only 256 requests per remote IP.
[22:43:31] <The_8472> heh, true
[22:43:39] <The_8472> IP+port even
[22:43:49] <klapaucjusz> It's coming over IPv6, so I suspect BitFlu.
[22:44:50] <klapaucjusz> By the way, the IPv6 DHT has almost doubled over the week-end.
[22:45:11] <The_8472> nice, did you release transmission 1.8 or something like that?
[22:45:22] <klapaucjusz> No, it's still dominated by your implementation.
[22:45:34] <klapaucjusz> I still haven't submitted the IPv6 code for inclusion in Transmission.
[22:46:12] <anakata> is 'v' limited to 4 bytes btw?
[22:47:26] <The_8472> not really a well-defined key. but... so far that's how it's used
[22:47:27] <anakata> it'd be good to have a "Did these packets cause the collapse of your government? See http://yaddayadda"
[22:47:35] <The_8472> UDP ...
[22:48:09] <anakata> is everything after the root dict ignored by the implementation(s) ?
[22:48:43] <The_8472> probably not, bdecoders might throw exceptions or wahtever
[22:49:24] <anakata> so where could ppl like me actually stick a ownership tag ?
[22:49:31] <klapaucjusz> The v key.
[22:49:47] <anakata> but everyone sets it to 4 bytes length!
[22:49:54] <klapaucjusz> That's plenty.
[22:49:59] <anakata> some stupid impl is probably gonna bork out if i make it longer
[22:50:05] <klapaucjusz> DHT packets are not the right place for advertising.
[22:50:15] <anakata> hahahah
[22:50:34] <klapaucjusz> Please follow the current conventions.
[22:50:42] <klapaucjusz> Two ASCII bytes that identify your implementation.
[22:50:58] <klapaucjusz> Two binary bytes, big-endian, that identify your internal version number.
[22:51:05] <anakata> 3:msg29:Fuck sexy girls in your area! :D
[22:51:17] <klapaucjusz> And don't worry.  If you break the Internetz, we'll track you down.
[22:52:02] <anakata> no comptuer crime laws here! :-)
[22:52:37] <klapaucjusz> I have Ukrainian friends.  And Georgian too.
[22:53:04] <anakata> and my dad knows karate!
[22:53:42] <klapaucjusz> Hmm... it looks like you're not in Russia after all.
[22:56:31] <klapaucjusz> Interesting setup, anakata.
[22:58:06] <anakata> this prefix is registered at a RIR for one continent, to a company from a second, and announced from a third
[22:58:22] <anakata> simply happened to end up that way.. path of least resistance etc
[22:59:04] <anakata> and this is the /24 of my home
[22:59:19] <anakata> flatline == my laptop
[22:59:25] <DWKnight> hired goons will find you
[22:59:33] <anakata> i have my own :)
[23:01:38] <anakata> welwell time to sleep
[23:01:54] <anakata> i have a staff of html/php coders to manage tomorrow
[23:01:55] <anakata> argh
[23:02:22] <DHE> got traceroute?
[23:03:02] <klapaucjusz> DHE: go for it.  You'll be surprised.
[23:04:46] <DHE> how the hell is kh = Cambodia anywas?
[23:04:54] <anakata> kampuchea
[23:05:20] <anakata> 'cambodia' is like a half-botched transliteration of the actual name
[23:05:24] <anakata> which kampuchea is closer to
[23:05:29] <DHE> clearly it lost something int the translation
[23:05:49] <anakata> but the exact sound of the p doesnt exist in western languages
[23:06:10] <anakata> but the actual spelling is with a b
[23:07:26] <klapaucjusz> Interestingly, there are two addresses in whois.
[23:08:00] <klapaucjusz> One in kh, and one in the Seychelles.
[23:08:11] <klapaucjusz> He's being routed through Hong-Kong.
[23:08:34] * klapaucjusz is ready to pay protection money to anakata.
[23:08:38] <anakata> imagine .. a world without borders !
[23:08:51] <anakata> dude all that stuff is totally unintentional
[23:09:12] <anakata> it was just the easiest way to get everything done and a /24 at home
[23:09:17] * klapaucjusz is ready to pay protection money, as long as he doesn't get addressed as "dude".
[23:10:27] <klapaucjusz> "I promise, yer honour, I didn't mean to create a complex network of shadow companies."
[23:10:37] *** Miller`` has quit IRC
[23:11:02] <anakata> HK routing is normal btw
[23:11:18] <klapaucjusz> Not between France and Sweden.
[23:11:23] <anakata> as this country is a bit lacking of plentiful/modern/etc connections tot he outside
[23:12:22] <anakata> well im not in either of those countries so
[23:12:35] <anakata> fuck sweden is like 0C and freezing now
[23:13:02] * klapaucjusz likes Swedish herring.
[23:13:55] <anakata> also i doubt i'd choose a $1600/Mbps route for routing games for my live network :)
[23:16:35] <klapaucjusz> ...on the other hand, Swedish salmon is overrated.
[23:17:15] <anakata> btw
[23:17:17] <anakata> 64 31 3A 61 64 32 3A 69 64 32 30 3A F2 36 51 A0 7D 4D D3 1C 6E 4E B4 35 d1:ad2:id20:.6Q.}M..nN.5
[23:17:20] <anakata> 14 2C 52 36 CD 98 AB 08 36 3A 74 61 72 67 65 74 32 30 3A F2 33 EA 2E 88 .,R6....6:target20:.3...
[23:17:23] <anakata> C7 9D 85 6B 7A 96 0A D3 3A AC A2 F8 09 47 5F 65 31 3A 71 39 3A 66 69 6E ...kz...:....G_e1:q9:fin
[23:17:27] <anakata> 64 5F 6E 6F 64 65 31 3A 74 34 3A 9E 0A 00 00 31 3A 76 34 3A 55 54 42 C3 d_node1:t4:....1:v4:UTB.
[23:17:30] <anakata> 31 3A 79 31 3A 71 65 1:y1:qe
[23:17:35] <anakata> D7 E7 D4 E3 30 39 34 42 4C 41 42 40 66 6C 61 74 D7 E7 D4 E3 ....094BLAB at flat dot ...
[23:17:41] <anakata> 64 31 3A 61 64 32 3A 69 64 32 30 3A F2 36 51 A0 7D 4D D3 1C 6E 4E B4 35 d1:ad2:id20:.6Q.}M..nN.5
[23:17:45] <anakata> 14 2C 52 36 CD 98 AB 08 36 3A 74 61 72 67 65 74 32 30 3A F2 34 27 5D 6A .,R6....6:target20:.4']j
[23:17:48] <anakata> 2E 87 63 3E 0C 57 5C 91 A2 7B 74 EB C5 F7 59 65 31 3A 71 39 3A 66 69 6E ..c>.W\..{t...Ye1:q9:fin
[23:17:52] <anakata> 64 5F 6E 6F 64 65 31 3A 74 34 3A 9F 0A 00 00 31 3A 76 34 3A 55 54 42 C3 d_node1:t4:....1:v4:UTB.
[23:17:55] <anakata> 31 3A 79 31 3A 71 65 1:y1:qe
[23:18:00] <anakata> E9 A2 2A D0 30 39 34 42 4C 41 42 40 66 6C 61 74 E9 A2 2A D0 ..*.094BLAB at flat dot .*.
[23:18:04] <anakata> 1 id per listenaddr:port
[23:18:06] <anakata> and my test setup hasnt blown up yet... amazing !
[23:19:08] <klapaucjusz> anakata: I hope you're drawing randomly at least the first 32 bits of your id.
[23:19:14] <klapaucjusz> They should be spread uniformly.
[23:19:55] <anakata> klapa: yes i am
[23:20:01] <anakata> first and last 32 bit
[23:20:40] *** ajaya has quit IRC
[23:21:33] <anakata> but this isnt somethign that will become part of the global dht "network" anyways
[23:22:08] <chelz> oh snap hey anakata, i don't think i'll ever forget you as the author of hypercube. i didn't know you spoke around here. :D
[23:22:39] <anakata> here my primary purpose seems to be to scare the living shit out of DHT authors .. :)
[23:23:21] <chelz> haha
[23:25:38] <DWKnight> is it working?
[23:26:21] *** Miller` has quit IRC
[23:27:08] <klapaucjusz> DWKnight: yes.
[23:28:49] <anakata> "-i wanna do this thing that dht wasnt meant for to achieve a certain goal with a certain set of users" -"THERE WILL BE GREAT TRIBULATIONS! ONE SEVENTH OF THE WATER WILL TURN BITTER"
[23:29:05] <anakata> fuck i need to re-read Revelation
[23:29:07] <anakata> can't even quote it properly
[23:29:33] <klapaucjusz> And its name shall be that of a well-known French drink.
[23:29:57] <anakata> haha yeah
[23:32:28] <klapaucjusz> Hmm.
[23:32:32] <klapaucjusz> My code still compiles.
[23:32:38] <klapaucjusz> Must be buggy in some subtler way.
[23:33:40] <klapaucjusz> (Of course, makeing absynth with 6 measures of water, as Revelation preconises, is ridiculous.)
[23:36:19] <klapaucjusz> "IPv6 DHT not ready -- broken, 0 nodes"
[23:36:46] <mpl> klapaucjusz: drinking absynth, is ridiculous anyway ;P
[23:37:47] <klapaucjusz> No choice.
[23:37:59] <klapaucjusz> When the Day comes, you'll have to.
[23:38:07] <klapaucjusz> Revelation is very clear on that.
[23:38:27] <mpl> then dare I say, "screw Revelation"?
[23:38:40] <mpl> whatever that is...
[23:38:52] 
[23:38:59] <mpl> hah
[23:39:21] <mpl> who knows, maybe I'd dig St. John.
[23:39:36] 
[23:40:01] <mpl> if Jesus loved him, who are we to not love him?
[23:40:15] <klapaucjusz> (I'm not sure it's the same John, though.)
[23:45:34] * klapaucjusz has broken transmission
[23:49:32] *** Miller` has joined #bittorrent
[23:49:44] *** Miller`` has joined #bittorrent
[23:50:38] *** anakata has quit IRC
[23:58:17] * klapaucjusz has fixed transmission





top