@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
zzz
hi
orignal
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
orignal
nice
zzz
5) includes increase to 16 lease limit
zzz
anything else?
zzz
ok, good list
zzz
1) compressed addresses, aka proposal 161, right?
orignal
yes
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
fine
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
ok
zzz
anything else on 1) ?
orignal
no
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
zzz
ok
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 ))
orignal
no
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
no
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
orignal
yes
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
orignal
no
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
zzz
i2p-projekt.i2p/spec/proposals/159 0.9.59 2023-08
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
dr|z3d
:)
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
wait
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)
orignal
yes
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
orignal
fine
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
no
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 :)