IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#ls2
/2022/11/28
@eyedeekay
+R4SAS
+RN
+RN_
+Xeha
+acetone
+orignal
+weko
Irc2PGuest5995
Irc2PGuest94373
Leopold
Onn4l7h
Onn4|7h
T3s|4_
aargh2
anon2
eyedeekay_bnc
hk
not_bob_afk
profetikla
shiver_
u5657
x74a6
zzz 0) Hi
RN aloha
zzz what do you have for the list today?
zzz buenos dias
orignal I think time to talk about compressed addresses
orignal and release results
zzz ok 1) is compressed addresses
zzz 2) is release results
orignal another thing you have mention on zzz.i2p
zzz whats that?
dr|z3d I've got a small one to throw into the mix. More a suggestion than a full blown topic.
orignal about eliminating ElGamal and I would add LS1
zzz ok 3) is eliminating elg / ls1
dr|z3d java i2p publishing ssu2 as ssu2 instead of ssu v2.
zzz 4) is drz's small thing which is... ?
zzz I;'ll add 5) DDoS prevention / PoW
zzz 5) includes increase to 16 lease limit
zzz anything else?
zzz ok, good list
zzz 1) compressed addresses, aka proposal 161, right?
orignal where are you with it?
orignal I can turn it on any time
zzz I posted my code about 2 months ago; I checked it in a few days ago, pretty much unchanged
dr|z3d running on a small platoon of routers here without issue.
orignal so your trunk contains this change and will be in the next release?
zzz correct
orignal I will do the same
zzz so you can enable it whenever, wait a while if you want some more java folks to have it
orignal yes, I know
zzz ok, let's see how it goes
orignal not today. maybe in couple weeks
zzz anything else on 1) ?
zzz 2) release results
orignal I see much more SSU2 sessions now
zzz I think bigly flipped their switch about 6 hours ago
orignal and more SSU2 traffic
zzz last night I saw more SSU2 connections than SSU1 connections for the first time
zzz not sure why because network was still only about 20% updated
orignal also I removed SSU1 code completely from trunk
zzz back to more like 40/60 split now
zzz but not really conclusive, just eyeballing it
orignal and this change makes a great improvement
orignal also another reason
orignal i2pd now has random priority between NTCP2 and SSU2
zzz I'm getting more and more disconnects on irc.ilita.i2p lately, getting worse... any ideas?
orignal before NTCP2 always had a priority
zzz how is ilita for you?
orignal 100% reliability
orignal you should have a disconnect 2 days ago
orignal because I was updting there
zzz I've had 6 disconnects since this morning
orignal but it's strange
orignal let me check
zzz I haven't looked closely, may not mean anything
orignal I see tunnel build success rate goes down
orignal maybe that th issue
orignal I will inverstigate
zzz anyway, no major problems with the release so far, as far as I can see
orignal yes, looks good
zzz still a little early to know for sure, will have better info in a few weeks
orignal right
Xeha it will get better once we have ssu2 vs ssu v2 fixed, but thats a later topic :)
zzz anything else on 2) ?
orignal I also have something to say about that topic ))
zzz 3) removing ElG / LS1
zzz go ahead orignal, this is your item
orignal I would start from LS1 on destinations
orignal and then switch server tunnels to 4 by default
zzz if a dest is ElG-only we do LS1
orignal then HTTP proxy to 4
orignal but why you do it?
orignal you can use LS2 even for Elg-only
zzz because might as well be compatible with old routers if we're ElG-only, no reason to do LS2
orignal another problem will be SAM
zzz dr|z3d, you and not bob have any data on % of servers that are ElG-only?
orignal my stats
orignal nobody uses LS1 at Ilita now
orignal I'm going to swith to 4 only for the next reastrt
zzz The biggest chunk of old routers is 0.9.29, that we think are old Vuze routers, but we aren't sure
dr|z3d yeah, zzz, ok.. rough numbers.. ElG, 20, Elg + ECIES, 341, ECIES, 312.
dr|z3d 99% are SHA1. so I don't think it would be a major issue losing those tbh.
orignal it's not related to SHA1
dr|z3d sure, just saying.
dr|z3d about 1/4 belong to str4d.
zzz client-side compatibility is one thing; network compatibility (storing to floodfills) is another
zzz I don't think we want to remove ElG or LS1 support from the floodfills
orignal I'm not going to remove it from FF's netdb
zzz we can definitely let all the str4d abandonware-sites burn
orignal just for desatinations
orignal flibusta is good
orignal usually they are slow with upgrades
zzz there's definitely a benefit to removing ElG from the LSes and going to 4-only, it shrinks the LS by 256 bytes, plus the overhead of trying both on inbound messages
dr|z3d inr.i2p is on that list, orignal. perhaps you can talk to slow?
orignal haven't seen him for a long time
dr|z3d otherwise, I can't see any other site there that's worth pursuing. mostly shit-ware.
zzz dr|z3d, perhaps you can put up a name-and-shame post on zzz.i2p?
orignal we consider inr as dead anyway
zzz might have done it before, can't remember
dr|z3d I believe you did, zzz, I vaguely recall. something along those lines.
dr|z3d look at scanner.linuxfarm.i2p/cgi-bin/defcon.cgi?filter=ElG and I think you'll agree there's nothing there worth making a noise about.
zzz back more to the topic
zzz does making an ElG-only dest LS2 make sense? or not?
orignal 0,4 is slower than 4 only
orignal in my inplemntation
orignal I always use 3 in this case
orignal e.g. LeaseSet2 type 3
orignal I'm even not sure if newer version of i2pd can publish LS1
orignal netplit
zzz kaboom
zzz ok, we do things differently, probably doesn't matter much
zzz let's discuss again in a future meeting, maybe we will think of some good reason
zzz anything else on 3) ?
orignal so I don't publish LS1 and want to stop honouring it for destinations
zzz 4) java publishing as ssu2
zzz your item dr|z3d, go ahead
orignal seems we lost him
dr|z3d thanks, zzz. yeah, as convenient as it is to tell an i2pd router from a java one in the netdb, they should both be publishing the same data re ssu2.
zzz sure, part of the plan
orignal same story as with NTCP2
dr|z3d which also brings me to a related issue.
orignal zzz promised to publish SSU2 later
orignal everybody knows this "secret" )))
orignal about cost
orignal also i2pd might publish some strange mtu
dr|z3d more reason to standardize on the cost, then. is there any advantage to differentiation, or different values? is there a philosophical difference in what the cost should be?
orignal dr|z3d it's easy
zzz but I know 6 other ways to tell even if you get rid of those two
orignal historically i2pd publoshed NTCP cost less than SSU
orignal me too )))
dr|z3d well now would be a good time to start thinking about eliminating those markers where possible, zzz, no?
zzz it's not worth the effort to hammer out every small detail. we'd all be miserable, or more than we are now
orignal what for?
dr|z3d avoiding segmentation attacks or related issues.
dr|z3d if it's huge effort, fine, nevermind then.
orignal Xeha your turn
zzz I think the segmentation is a lot worse along the other axis, aka router version
orignal also I'm thinking to set cost evern random
Xeha nothing to add from my side now
zzz heterogenous network just a fact of life, even if I can't figure out how to spell it
zzz anything else on 4) ?
dr|z3d 4, no, I'm done.
zzz 5) DDoS / PoW / max leases
zzz let's keep it brief, big topic
zzz interesting discussion over on zzz.i2p
zzz no where close to any good ideas
zzz one simple proposal is increasing max leases, currently 16
zzz 40 bytes each in LS2
dr|z3d yeah, all stems from Tor's DDOS and, somewhat related, dread.onion's ongoing DDOS, to give some context.
orignal about 4
orignal for now consider all SSU as SSU2 if v=2 is presented
orignal e.g. single address
orignal hence not difference for me if it's published as SSU or SSU2
zzz any increase would take two releases, possibly 3-4 releases (one year) for everybody to update, so easy change, but long leadtime
zzz the issue is not spamming the ffs or your connections, because it's O(n**2) as I explain in the thread
zzz right orignal
orignal also another thing
orignal I'm not happy that lease is 40 bytes
orignal no room for options/flags
zzz ok, back to 5)
zzz yeah, I thought of that the other day. No per-lease options
zzz you could do it in the main properties, like key.1=xxx key.2=yyy key.3=zzz
zzz a little messier but not terrible
orignal I can tel you why
orignal when I publish lease I publish only router ident
zzz so LS2 without ElG is 256 bytes smaller, so that's as much as 6 more leases for the same size
orignal but also would be nice to publish transports
orignal to let client choose compatible OB and lease pair
orignal pplease exaplin what are trying ot acheieve?
zzz not sure that makes sense, to copy over RI data into the LS... that's the other router's job
zzz here's the idea:
zzz DDoS attacks all the IBGWs. If you have more leases, you have more IBGWs, harder to DDoS
zzz so, maybe 16 is easy to DDoS and 64 is hard to DDoS? or maybe that's bullshit. discuss :)
orignal not RI
orignal just bitmask of trsnaports
dr|z3d 16 probably takes some effort, 2, not so much. do we need max 64 leases, or would 32 be enough to require a bunch of resources? or is 16 enough to make things non-trivial?
orignal I disagree about "other router's job"
orignal because it leads to deanon
zzz sure, but could also do a property transports=base64(transport bitmask bytes, one per lease)
orignal I publish some fake ident in lease
orignal and force client to lookup
orignal if I also a FF closest to this ident
dr|z3d and re lease count, why settle on static values? scaling count based on usage could also serve to frustrate DDOS attempts while not expending needless resources when no DDOS.
orignal I will identify router
zzz prefer IBGWs already in netdb; don't lookup unknown IBGWs unless you don't know any of them
zzz and actually you don't need to look them up at all. just pick one
dr|z3d I'm also wondering whether huge leasesets could be distributed in sections so not all leases go to a single floodfill. maybe in bundles of 8 or whatever works?
zzz it's one byte lease count so max is 255 leases would be about 10.5 KB
orignal but what I don't have that IBGW in netdb
zzz so that gets split up into 11 or so tunnel messages, good luck
orignal it means I can't pick proper OB
zzz my point is, because of O(n**2) issue, have to make sure your impl doesn't behave like that before increasing limit
zzz don't try to pick "proper OB", just pick at random
zzz not worth the delay to lookup IBGW RI
orignal tell me do we have actual ddos of IBGW
zzz no we do not
orignal or it's theoretical thing?
zzz just theory. Tor's problem today may be our problem tomorrow. Or maybe not.
orignal then wouldn't sucj ddos flood next in tunnel router rather than destination?
zzz the idea is, IBGW enforces some PoW or access rules, doesn't send it down the tunnel unless "verified"
orignal then it comes back to my idea
orignal that we need room for more data in a lease
zzz too much for last agenda item :) please read zzz.i2p thread, comment there if you like, let's discuss again later
orignal like task, etc.
zzz we have workarounds in the properties, if we want
zzz no need for #ls3 just for that
orignal no it's not needed
zzz think about what we need in there per-lease, bring a list to next meeting
zzz foo.1=xxx bar.2=yyy, or bitmask=base64(all leases)
zzz lots of ways to do it if we want
zzz ok, long meeting, shall we call it here?
zzz please participate in IBGW PoW thread on zzz.i2p
dr|z3d just a quick q, zzz. bundling up leases in batches, viable or a non-starter?
zzz not sure what that buys you drz if everybody is going to the same ff
zzz I don't have a histogram of ff target vs. distance-to-key or even any clue
dr|z3d it means if everyone goes to the same ff, then they only get a percentage of the actual leases available, no? so ff's don't get hammered if you're publishing 256 leases, and you can't disocver all leases just hitting 1 ff.
zzz yeah but nobody ever gets any of the the other leases so why did you bother?
zzz I don't know if closest ff gets 100% of the lookups, or 70, or 50, or 20. no idea.
dr|z3d because we're assuming everyone gets the same leases from the same ff. surely that's not likely to happen in practice?
dr|z3d if everyone got the same leases, multi-homing wouldn't work.
zzz but if I send LS a to ff A and LS b to FF b, then A floods a to B and B floods b to A ant it's a pointless mess
zzz but that's temporal randomness, not due to which ff you think is closest
dr|z3d yeah, but if A has, a, then it can just drop b.
dr|z3d "no thanks, I have enough"
orignal hmm, ilita's router has 3000+ transit tunnels now
dr|z3d you'd just check the timestamps.
zzz at this point it's a strange solution to a vague problem, can't nail jello to a tree
zzz don't make me pull out the baffer
dr|z3d well, the entire problem is hypothetical, but if we're discussing increasing the lease limit, it's something to think about. :)
zzz thanks everybody
zzz sure, not like 64 leases nails the jello either
dr|z3d bundles + dynamic scaling, that's my vague proposal, anyways.
dr|z3d 3000 tunnels is a high watermark, orignal?
orignal just checking what's worng with Ilita
dr|z3d still seeing the occasional spikes on the network, but they're very short-lived.
orignal see higher memoery usage but it's result of transit tunnels
dr|z3d on the subject of SSU1/2 connection ratios, I'm seeing 4 to 1 roughly on a fast router.
dr|z3d status and limits would be handy things to display on /peers, zzz.
zzz maybe
dr|z3d ideally that page would supplant the individual transport pages for average user, but probably would need some averages there and more stats.
dr|z3d you know, break down of connections by bw tier, ff, country etc. that sort of thing.
zzz none of that really helps the goal of 'help users identify network/censorship problems', but maybe that's not the only goal
dr|z3d I think the censorship goal is probably secondary to summarizing peer connections.. I mean, it's a handy feature, but if you think of that page as a summary instead of a "am I censored" page, maybe you can recalibrate
zzz 'summarizing peer connections' is not a goal, or shouldn't be, nobody cares
dr|z3d it would make those transprot stats a lot more accessible. as they are, you're probably right. too informationally dense for most.
dr|z3d the SSU transport page is especially offensive in that respect :)