13:06 <@jrandom> 0) hi
13:06 <@jrandom> 1) 0.4.2.5
13:06 <@jrandom> 2) 0.5
13:06 <@jrandom> 3) ???
13:06 <@jrandom> 0) hi
13:06 * jrandom waves
13:06 <+postman> *wave*
13:06 < ant> <jnymo> hello
13:06 <@jrandom> brief status notes posted up @ http://dev.i2p.net/pipermail/i2p/2004-December/000535.html
13:07 <@jrandom> jumping in to 1) 0.4.2.5
13:07 <@jrandom> as mentioned, things are pretty much working
13:08 <+postman> yeah, quite impressive
13:08 <+postman> no more lease timouts on my systems at all
13:08 <@jrandom> a lot of people have seen what you've seen jnymo, with 0 participating tunnels, largely in part to the increased efficiency & peer selection (where we now know to leech off postman's machine ;)
13:08 < ant> <jnymo> me too
13:08 <@jrandom> nice
13:08 < ant> <jnymo> and eepsites are snappy
13:09 <+postman> :)
13:09 < ant> <jnymo> thanks postman :)
13:09 <+postman> totsl bw is 29kb / 30.1kb/s
13:09 < frosk> everybody feels less loved, but in reality the love is just being put more efficiently to work
13:10 < ant> <jnymo> wow
13:10 <@jrandom> b1tchin postman
13:10 < mule2> i don't think that is the preferred ideal. we'd better have some traffic through all nodes
13:10 < ant> <jnymo> i could handle that if people just loved me :(
13:10 <+postman> yep
13:10 < mule2> as kind of cover traffic
13:10 <@jrandom> mule2: its a matter of our load being much less than our network capacity
13:11 <@jrandom> i dont think we'll be able to keep the capacity greater than the load for long
13:11 < ant> <jnymo> mule2, postman is also act as i mixer.. so its hard to tell where you packets are going after they go in
13:11 <@jrandom> so i'm not too worried about not pushing any data through slower peers
13:12 < mule2> probably less perfect optimization would be good for anonymity
13:12 <@jrandom> otoh, it also gives incentive for more people to (implement &) use i2pcontent, so they can mirror as well as gain cover traffic ;)
13:12 < jdot__> i it a security issue that one router handles all(ish) tunnels?
13:13 <@jrandom> mule2: lets first get it as good as we can get it, then we can discuss proactively making it worse
13:13 <@jrandom> jdot__: we don't have one router handling all of the traffic, but we are seeing the grouping of routers who are on very fast connections (colo, etc) handling more than dialup/dsl/cable users
13:14 <@jrandom> plus the reduced tunnel failures means we're shifting & exploring less
13:14 < mule2> perhaps some traffic distribution would be possible, as long as we are far from the routers limits
13:14 <@jrandom> right, probabalistic tunnel rejection is in the router and can be enabled based on the router's bandwidth limits
13:15 < ant> <jnymo> yea, but such high throughput on postman's node makes it harder to analyze his node.. so it might be safer to send through him than for all nodes to do one KBs..
13:15 <@jrandom> (but if postman doesnt set any limits, we can't reject based on a % of that ;)
13:15 < ant> <jnymo> groupings of faster nodes cause something of a mix cascade structure, no?
13:15 <@jrandom> aye, that is one way to look at it
13:15 < lektriK> can I close the Start I2P window?
13:15 * postman is very sorry NOT to restrict his bandwidth
13:16 <@jrandom> lektriK: unfortunately, not really, unless you start i2p as a service (See http://localhost:7657/configservice.jsp)
13:16 <@jrandom> heh postman dont worry, we'll back off your router if/when we reach your router's capacity
13:17 < lektriK> Ok, it sais service started
13:17 < lektriK> can I close it now?
13:17 <@jrandom> lektriK: no/yes - you can shut down your router then start it again via start->run->"net start i2p"
13:18 < mule2> as it is, a few very big routers could handle all the tunnels, removing all cover traffic from all other routers. but lets continue with that after the meeting.
13:18 < mule2> don't want to complain about the network behaving to good :)
13:18 <@jrandom> hehe
13:20 <@jrandom> some further exploration will occur with 0.5, though there are anonymity related issues with spreading too far. there'll be further details to be worked through on that for 0.5 though (and in the doc which might be ready next week as a first draft)
13:21 <@jrandom> anyway, anyone else have something to bring up for 0.4.2.5?
13:21 <@jrandom> or shall we move on briefly to 2) 0.5?
13:21 <+postman> move
13:21 < ant> <jnymo> very stable... move
13:21 <@jrandom> consider us moved
13:22 <@jrandom> 2) 0.5
13:22 <@jrandom> yeah. still work in progress. more info when its ready.
13:22 < ant> <Quadn-werk> Sir Arthur C. Clarke is alive :P
13:22 < ant> <Quadn-werk> http://slashdot.org/articles/04/12/28/0120240.shtml?tid=99&tid=1
13:22 < ant> <jnymo> .5 is exciting
13:22 <@jrandom> ok, thats all i have to say on that - anyone have any questions / things to discuss about it?
13:23 <@jrandom> aye, there are definitely some important revamping going on, based on what we've learned over the last 16 months
13:23 <@jrandom> (or shit, 18)
13:23 <+postman> jrandom: so 0.5 will emnploy a new tunnel management system mostly?
13:23 < ant> <Quadn-werk> arg, i hope i didnt interrupt the meeting :/
13:23 <+postman> wow
13:23 < ant> <Quadn-werk> sorry heh
13:23 < ant> <jnymo> heh. i had a suggestion
13:24 <@jrandom> yeah postman, new management, pooling, and building
13:24 <+postman> quadn: look what you've done - your paste caused a netsplit :)
13:24 <@jrandom> you bastard!
13:24 < ant> <Quadn-werk> !
13:24 <@jrandom> sup jnymo?
13:24 <+postman> jrandom: will every tunnel be a separate local destination still?
13:25 <@jrandom> huzzawuzzah?
13:25 <@jrandom> there won't be any change to i2ptunnel in 0.5
13:25 <+postman> jrandom: ok
13:25 <@jrandom> (at least, i dont plan on any)
13:26 < mule> postman mounting an intersection attack?
13:26 < ant> <jnymo> for those who aren't getting /any/ bandwidth usage.. how bout letting routers build tunnels with them in it.. like ABCABCA
13:26 <+postman> mule: no, it was quadn's fault :)
13:26 < ant> <jnymo> and that would be a dummy tunnel
13:27 <@jrandom> jnymo: advertising a router as saying "hey i have excess bandwidth, use me" is a dangerous game
13:27 <+postman> jrandom: what issues will then be addressed by the redesign ( in a nutshell )
13:27 < ant> <jnymo> not sure i meant that, jrandom
13:27 <@jrandom> but what it looks like now is that we'll have two sets of tunnels - the normal ones, and then exploratory ones, where the later are built from randomly selected non-failing peers
13:28 < ant> <jnymo> jrandom: i meant creating a dummy tunnel, and putting my self in the middle of that tunnel just to simulate some traffic
13:29 <@jrandom> postman: making it much harder to correllate peers in a tunnel, allowing clients to effectively choose their outbound tunnel length, and providing the options necessary for addressing the predecessor attack (with various tradeoffs)
13:29 <@jrandom> (oh, and improving performance by getting rid of a lot of modPow calls)
13:29 <+postman> ok thanks
13:29 < ant> <jnymo> postman: and per hop tunnel ids is a big one
13:30 <+postman> modpow?
13:30 <@jrandom> ah jnymo. yeah, there's a lot of potential for various chaff traffic generation
13:30 < ant> <jnymo> that way, no two non-neighboring nodes can know there on the same tunnel, postman
13:30 <@jrandom> postman: modular exponentiation, heavy cpu usage & memory waste
13:31 < ant> <jnymo> jrandom: k cool
13:31 <+postman> k
13:31 < scintilla> jrandom, wrt to letting clients choose tunnel length: will there be anything in place to keep ppl from cranking it up to 99 (or whatever)?
13:31 < ant> <jnymo> cpu power
13:32 <@jrandom> when necessary we can add hashcash, but excessively long tunnels will just end up failing anyway
13:32 < scintilla> ah good point
13:32 <@jrandom> we could even add in some trickery - requiring that a tunnel have a valid tunnel message pumped through it within 60s of creation for it to be 'valid'
13:33 <@jrandom> (so if the tunnel was 20 hops long, it'd take them too long to build all those hops)
13:33 < scintilla> that's a great idea - that'll keep any such ridiculousness from lingering for very long
13:33 <@jrandom> but thats all vs the hackers. normal users will just use the exposed interface
13:34 < ant> <jnymo> right, which you'll cap off somewhere right?
13:34 < ant> <jnymo> we'll get higher than the maximum 2 as it is now, right?
13:34 <@jrandom> right, like the # hops drop down on /configclients.jsp or /i2ptunnel/edit.jsp
13:35 <@jrandom> oh i thought the max was 3 now? ok, but yeah, higher than 2 will be available
13:35 < ant> <jnymo> 3 tunnels, 2 hops
13:35 <@jrandom> ah 'k
13:35 <@jrandom> yeah, 0.5 will add in some important new tweaks, such as whether to randomize those lengths, as well as how much to randomize, etc
13:36 < frosk> the max is indeed 3
13:36 < ant> <jnymo> hmm
13:37 <@jrandom> ah its 3 on /configclients 2 on i2ptunnel
13:37 < frosk> is 0.5 still on track for january?
13:37 < ant> <jnymo> ah
13:37 <@jrandom> yeah frosk
13:37 < frosk> goodie
13:37 <@jrandom> i wont dawdle too much longer on the streaming lib, i promise ;)
13:37 < frosk> it just sounds like a lot of work :)
13:38 <@jrandom> its actually not so bad, the hard part is getting the algorithms right
13:38 <@jrandom> (details schmetails ;)
13:39 <+postman> frosk: and it's all on paper already
13:39 <+postman> :)
13:39 < ant> <jnymo> heh
13:39 < frosk> true :)
13:39 <@jrandom> mostly yeah ;)
13:39 <@jrandom> ok, anyone have anything else for 2) 0.5?
13:39 < ant> <jnymo> nada
13:39 < frosk> el zilcho
13:40 <@jrandom> 'k, swingin on to good old fashioned 3) ???
13:40 <@jrandom> hi
13:40 <@jrandom> anyone have anything else they want to bring up?
13:41 < ant> <jnymo> postman: there arent smtp/pop3 inproxies on i2pmail.org are there?
13:41 < cat-a-puss> I am still seeing weird delays on the client end...
13:41 <+postman> hrm no
13:41 < frosk> this is where i'd hand over the congratulatory bottle of wine for a fine year of development ;)
13:41 <+postman> jnymo: POP3 is only available for i2p users
13:41 <@jrandom> cat-a-puss: ah i missed those messages when you were around earlier
13:41 <+postman> jnymo: there IS a SMTP inproxy as MX for the domain i2pmail.org
13:42 <@jrandom> frosk: cheers
13:42 < ant> <jnymo> right right.. that's coo'..
13:42 < cat-a-puss> Like I can have two local Destinations and when one trys to connect to another there is a delay and it is not CPU bound
13:42 < mule> cat-a-puss: do you also hand over the bonus cheque ?
13:42 * postman donates a good whiskey
13:42 <@jrandom> cat-a-puss: right, you saw a .5-1.0s delay right?
13:42 < cat-a-puss> mule: what?
13:42 < cat-a-puss> jrandom: yeah
13:43 <@jrandom> cat-a-puss: perfectly normal, part of the deferred syn
13:43 < mule> sorry, the comment was from frosk
13:43 < ant> * jnymo pulles out that crappy box wine
13:43 < mule> frosk: do you also hand over the bonus cheque ?
13:43 <@jrandom> (it waits a bit to send the SYN and the related ACK in case there is more data to bundle)
13:43 < scintilla> oh fyi, i should be receiving the book with the fortuna algorithm spec in it soon... in the meantime i've been experimenting with trying to gather entropy in java without destroying a machine
13:44 <@jrandom> ah kickass
13:44 < ant> <jnymo> mmm, someone was wanting to mount some attacks on i2p
13:44 < ant> <jnymo> who was that?
13:44 <@jrandom> connelly
13:44 < cat-a-puss> Is there a way to prevent that, or do I just have to try to avoid short lived connections where I can?
13:45 < ant> <jnymo> any word on that, jr?
13:45 <@jrandom> cat-a-puss: yeah there are some options you can pass when creating the I2PSocketManager, lemmie pull 'em up
13:46 <@jrandom> jnymo: its a long term intersection attack, so after a while he'll have data to help identify what routers particular eepsites are on. i'm sure he's going to write up some summary data for us once he's got it
13:46 < ant> <jnymo> scintalla: what's the fortuna algorithm?
13:46 < ant> <jnymo> jrandom: aight
13:48 <@jrandom> cat-a-puss: i2p.streaming.initialResendDelay=50 i2p.streaming.connectDelay=100
13:48 < scintilla> it's a cryptographically secure pseudo-random number generator... something which is absolutely essential for trustworthy encryption
13:48 < jdot__> anyone volunteer for that attack yet?
13:48 <@jrandom> cat-a-puss: then be sure to flush() after write()ing to the I2PSocket
13:48 <@jrandom> jdot__: yeah, he has 7 volutneered sites
13:48 < cat-a-puss> jrandom: ok
13:49 < ant> <jnymo> wrt the great naming debate..
13:49 < ant> * jnymo snickers
13:49 <@jrandom> oh and i2p.streaming.initialAckDelay=1000
13:49 <@jrandom> or even =100
13:49 * jrandom flings mud at jnymo
13:50 < ant> <jnymo> i actually do work with x500 and my job lets me have free winSevers
13:50 < ant> <jnymo> so, perhaps i'll just set up a central DNS for testing purposes in a month or two
13:51 <@jrandom> heh, having a centralized naming server hosted on a .mil would be bloody hilarious
13:51 < ant> <jnymo> though hacking i2p addresses into winserver may be non-trivial.. dunno
13:51 < ant> <jnymo> heh.. dnsalias is the ticket
13:52 <@jrandom> nano has done some really cool work, integrating dnsjava with i2p
13:52 < ant> <jnymo> ooooh
13:53 <@jrandom> check out nano.i2p for more details
13:53 < ant> <jnymo> and no one was going to tell me.. ah, thanks
13:53 <@jrandom> but, as mentioned last time, people should post up their thoughts and ideas about naming to the wiki
13:54 <@jrandom> ok, anyone else have something to bring up for the meeting?
13:55 < ant> <jnymo> nope
13:57 <@jrandom> ok in that case
13:57 * jrandom winds up
13:57 * jrandom *baf*s the meeting closed