<p>13:08 <+postman> no more lease timouts on my systems at all</p>
<p>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 ;)</p>
<p>13:08 < ant><jnymo> me too</p>
<p>13:08 <@jrandom> nice</p>
<p>13:08 < ant><jnymo> and eepsites are snappy</p>
<p>13:09 <+postman> totsl bw is 29kb / 30.1kb/s</p>
<p>13:09 < frosk> everybody feels less loved, but in reality the love is just being put more efficiently to work</p>
<p>13:10 < ant><jnymo> wow</p>
<p>13:10 <@jrandom> b1tchin postman </p>
<p>13:10 < mule2> i don't think that is the preferred ideal. we'd better have some traffic through all nodes</p>
<p>13:10 < ant><jnymo> i could handle that if people just loved me :(</p>
<p>13:10 <+postman> yep</p>
<p>13:10 < mule2> as kind of cover traffic</p>
<p>13:10 <@jrandom> mule2: its a matter of our load being much less than our network capacity</p>
<p>13:11 <@jrandom> i dont think we'll be able to keep the capacity greater than the load for long</p>
<p>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</p>
<p>13:11 <@jrandom> so i'm not too worried about not pushing any data through slower peers</p>
<p>13:12 < mule2> probably less perfect optimization would be good for anonymity</p>
<p>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 ;)</p>
<p>13:12 < jdot__> i it a security issue that one router handles all(ish) tunnels?</p>
<p>13:13 <@jrandom> mule2: lets first get it as good as we can get it, then we can discuss proactively making it worse</p>
<p>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</p>
<p>13:14 <@jrandom> plus the reduced tunnel failures means we're shifting & exploring less</p>
<p>13:14 < mule2> perhaps some traffic distribution would be possible, as long as we are far from the routers limits</p>
<p>13:14 <@jrandom> right, probabalistic tunnel rejection is in the router and can be enabled based on the router's bandwidth limits</p>
<p>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..</p>
<p>13:15 <@jrandom> (but if postman doesnt set any limits, we can't reject based on a % of that ;)</p>
<p>13:15 < ant><jnymo> groupings of faster nodes cause something of a mix cascade structure, no?</p>
<p>13:15 <@jrandom> aye, that is one way to look at it</p>
<p>13:15 < lektriK> can I close the Start I2P window?</p>
<p>13:15 * postman is very sorry NOT to restrict his bandwidth</p>
<p>13:16 <@jrandom> lektriK: unfortunately, not really, unless you start i2p as a service (See http://localhost:7657/configservice.jsp)</p>
<p>13:16 <@jrandom> heh postman dont worry, we'll back off your router if/when we reach your router's capacity</p>
<p>13:17 < lektriK> Ok, it sais service started</p>
<p>13:17 < lektriK> can I close it now?</p>
<p>13:17 <@jrandom> lektriK: no/yes - you can shut down your router then start it again via start->run->"net start i2p"</p>
<p>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.</p>
<p>13:18 < mule2> don't want to complain about the network behaving to good :)</p>
<p>13:18 <@jrandom> hehe</p>
<p>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)</p>
<p>13:21 <@jrandom> anyway, anyone else have something to bring up for 0.4.2.5? </p>
<p>13:21 <@jrandom> or shall we move on briefly to 2) 0.5?</p>
<p>13:21 <+postman> move</p>
<p>13:21 < ant><jnymo> very stable... move</p>
<p>13:21 <@jrandom> consider us moved</p>
<p>13:22 <@jrandom> 2) 0.5</p>
<p>13:22 <@jrandom> yeah. still work in progress. more info when its ready.</p>
<p>13:22 < ant><Quadn-werk> Sir Arthur C. Clarke is alive :P</p>
<p>13:23 < ant><jnymo> heh. i had a suggestion</p>
<p>13:24 <@jrandom> yeah postman, new management, pooling, and building</p>
<p>13:24 <+postman> quadn: look what you've done - your paste caused a netsplit :)</p>
<p>13:24 <@jrandom> you bastard!</p>
<p>13:24 < ant><Quadn-werk> !</p>
<p>13:24 <@jrandom> sup jnymo?</p>
<p>13:24 <+postman> jrandom: will every tunnel be a separate local destination still?</p>
<p>13:25 <@jrandom> huzzawuzzah?</p>
<p>13:25 <@jrandom> there won't be any change to i2ptunnel in 0.5</p>
<p>13:25 <+postman> jrandom: ok</p>
<p>13:25 <@jrandom> (at least, i dont plan on any)</p>
<p>13:26 < mule> postman mounting an intersection attack?</p>
<p>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</p>
<p>13:26 <+postman> mule: no, it was quadn's fault :)</p>
<p>13:26 < ant><jnymo> and that would be a dummy tunnel</p>
<p>13:27 <@jrandom> jnymo: advertising a router as saying "hey i have excess bandwidth, use me" is a dangerous game</p>
<p>13:27 <+postman> jrandom: what issues will then be addressed by the redesign ( in a nutshell )</p>
<p>13:27 < ant><jnymo> not sure i meant that, jrandom</p>
<p>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</p>
<p>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</p>
<p>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)</p>
<p>13:29 <@jrandom> (oh, and improving performance by getting rid of a lot of modPow calls)</p>
<p>13:29 <+postman> ok thanks</p>
<p>13:29 < ant><jnymo> postman: and per hop tunnel ids is a big one</p>
<p>13:30 <+postman> modpow?</p>
<p>13:30 <@jrandom> ah jnymo. yeah, there's a lot of potential for various chaff traffic generation</p>
<p>13:30 < ant><jnymo> that way, no two non-neighboring nodes can know there on the same tunnel, postman</p>
<p>13:30 <@jrandom> postman: modular exponentiation, heavy cpu usage & memory waste</p>
<p>13:31 < ant><jnymo> jrandom: k cool</p>
<p>13:31 <+postman> k</p>
<p>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)?</p>
<p>13:31 < ant><jnymo> cpu power</p>
<p>13:32 <@jrandom> when necessary we can add hashcash, but excessively long tunnels will just end up failing anyway</p>
<p>13:32 < scintilla> ah good point</p>
<p>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'</p>
<p>13:33 <@jrandom> (so if the tunnel was 20 hops long, it'd take them too long to build all those hops)</p>
<p>13:33 < scintilla> that's a great idea - that'll keep any such ridiculousness from lingering for very long</p>
<p>13:33 <@jrandom> but thats all vs the hackers. normal users will just use the exposed interface</p>
<p>13:34 < ant><jnymo> right, which you'll cap off somewhere right?</p>
<p>13:34 < ant><jnymo> we'll get higher than the maximum 2 as it is now, right?</p>
<p>13:34 <@jrandom> right, like the # hops drop down on /configclients.jsp or /i2ptunnel/edit.jsp</p>
<p>13:35 <@jrandom> oh i thought the max was 3 now? ok, but yeah, higher than 2 will be available</p>
<p>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</p>
<p>13:36 < frosk> the max is indeed 3</p>
<p>13:36 < ant><jnymo> hmm</p>
<p>13:37 <@jrandom> ah its 3 on /configclients 2 on i2ptunnel</p>
<p>13:37 < frosk> is 0.5 still on track for january?</p>
<p>13:37 < ant><jnymo> ah</p>
<p>13:37 <@jrandom> yeah frosk</p>
<p>13:37 < frosk> goodie</p>
<p>13:37 <@jrandom> i wont dawdle too much longer on the streaming lib, i promise ;)</p>
<p>13:37 < frosk> it just sounds like a lot of work :)</p>
<p>13:38 <@jrandom> its actually not so bad, the hard part is getting the algorithms right</p>
<p>13:39 <+postman> frosk: and it's all on paper already</p>
<p>13:39 <+postman> :)</p>
<p>13:39 < ant><jnymo> heh</p>
<p>13:39 < frosk> true :)</p>
<p>13:39 <@jrandom> mostly yeah ;)</p>
<p>13:39 <@jrandom> ok, anyone have anything else for 2) 0.5?</p>
<p>13:39 < ant><jnymo> nada</p>
<p>13:39 < frosk> el zilcho</p>
<p>13:40 <@jrandom> 'k, swingin on to good old fashioned 3) ???</p>
<p>13:40 <@jrandom> hi</p>
<p>13:40 <@jrandom> anyone have anything else they want to bring up?</p>
<p>13:41 < ant><jnymo> postman: there arent smtp/pop3 inproxies on i2pmail.org are there?</p>
<p>13:41 < cat-a-puss> I am still seeing weird delays on the client end...</p>
<p>13:41 <+postman> hrm no</p>
<p>13:41 < frosk> this is where i'd hand over the congratulatory bottle of wine for a fine year of development ;)</p>
<p>13:41 <+postman> jnymo: POP3 is only available for i2p users</p>
<p>13:41 <@jrandom> cat-a-puss: ah i missed those messages when you were around earlier</p>
<p>13:41 <+postman> jnymo: there IS a SMTP inproxy as MX for the domain i2pmail.org</p>
<p>13:42 <@jrandom> frosk: cheers</p>
<p>13:42 < ant><jnymo> right right.. that's coo'..</p>
<p>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</p>
<p>13:42 < mule> cat-a-puss: do you also hand over the bonus cheque ?</p>
<p>13:42 * postman donates a good whiskey </p>
<p>13:42 <@jrandom> cat-a-puss: right, you saw a .5-1.0s delay right?</p>
<p>13:42 < cat-a-puss> mule: what?</p>
<p>13:42 < cat-a-puss> jrandom: yeah</p>
<p>13:43 <@jrandom> cat-a-puss: perfectly normal, part of the deferred syn</p>
<p>13:43 < mule> sorry, the comment was from frosk</p>
<p>13:43 < ant> * jnymo pulles out that crappy box wine</p>
<p>13:43 < mule> frosk: do you also hand over the bonus cheque ?</p>
<p>13:43 <@jrandom> (it waits a bit to send the SYN and the related ACK in case there is more data to bundle)</p>
<p>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</p>
<p>13:44 <@jrandom> ah kickass</p>
<p>13:44 < ant><jnymo> mmm, someone was wanting to mount some attacks on i2p</p>
<p>13:44 < ant><jnymo> who was that?</p>
<p>13:44 <@jrandom> connelly</p>
<p>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?</p>
<p>13:45 < ant><jnymo> any word on that, jr?</p>
<p>13:45 <@jrandom> cat-a-puss: yeah there are some options you can pass when creating the I2PSocketManager, lemmie pull 'em up</p>
<p>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</p>
<p>13:46 < ant><jnymo> scintalla: what's the fortuna algorithm?</p>
<p>13:48 < scintilla> it's a cryptographically secure pseudo-random number generator... something which is absolutely essential for trustworthy encryption</p>
<p>13:48 < jdot__> anyone volunteer for that attack yet?</p>
<p>13:48 <@jrandom> cat-a-puss: then be sure to flush() after write()ing to the I2PSocket</p>
<p>13:48 <@jrandom> jdot__: yeah, he has 7 volutneered sites</p>
<p>13:48 < cat-a-puss> jrandom: ok</p>
<p>13:49 < ant><jnymo> wrt the great naming debate.. </p>
<p>13:49 < ant> * jnymo snickers</p>
<p>13:49 <@jrandom> oh and i2p.streaming.initialAckDelay=1000</p>
<p>13:49 <@jrandom> or even =100</p>
<p>13:49 * jrandom flings mud at jnymo</p>
<p>13:50 < ant><jnymo> i actually do work with x500 and my job lets me have free winSevers</p>
<p>13:50 < ant><jnymo> so, perhaps i'll just set up a central DNS for testing purposes in a month or two</p>
<p>13:51 <@jrandom> heh, having a centralized naming server hosted on a .mil would be bloody hilarious </p>
<p>13:51 < ant><jnymo> though hacking i2p addresses into winserver may be non-trivial.. dunno</p>
<p>13:51 < ant><jnymo> heh.. dnsalias is the ticket</p>
<p>13:52 <@jrandom> nano has done some really cool work, integrating dnsjava with i2p</p>
<p>13:52 < ant><jnymo> ooooh</p>
<p>13:53 <@jrandom> check out nano.i2p for more details</p>
<p>13:53 < ant><jnymo> and no one was going to tell me.. ah, thanks</p>
<p>13:53 <@jrandom> but, as mentioned last time, people should post up their thoughts and ideas about naming to the wiki</p>
<p>13:54 <@jrandom> ok, anyone else have something to bring up for the meeting?</p>