IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2023/10/15
@eyedeekay
&kytv
&zzz
+R4SAS
+RN
+RN_
+T3s|4
+dr|z3d
+hk
+orignal
+postman
+wodencafe
Arch
DeltaOreo
FreeRider
FreefallHeavens
Irc2PGuest19353
Irc2PGuest46029
Irc2PGuest64530
Irc2PGuest77854
Nausicaa
Onn4l7h
Onn4|7h
Over1
Sisyphus
Sleepy
Soni
T3s|4_
Teeed
aargh3
acetone_
anon4
b3t4f4c3
bak83_
boonst
cancername
cumlord
dr4wd3_
eyedeekay_bnc
hagen_
khb
mittwerk
not_bob_afk
plap
poriori_
profetikla
rapidash
shiver_
solidx66
u5657_1
uop23ip
w8rabbit
weko_
x74a6
RN 2.3.0-7 available for easy testing deployment at I2Peek-a-Boo.i2p
orignal zzz, it looks like we have scalability issue
orignal I have 16K router on a floodfill
orignal and since it's floodfill I can't cleanup more agressively then 1 hour expriration
orignal what is the network grows more?
zzz as long of the ratio of ff:non-ff stays the same, it won't make a difference
orignal 16K/1.5K
orignal no it's not
orignal basicallly number of non-FF grow more
orignal it consumes resources
zzz we discussed this and did a lot of work back in the attack days early this year
orignal say we have the networks 5x more tommorow. what are we goping to do?
orignal it's not about attack now
orignal they seem real routers
zzz right, the changes are still helping us
orignal how many routers you have on a FF?
zzz if you're ff, you can expire routers that aren't close-to-your-key faster than 1 hour. That's what we do now
zzz I'm not running a ff now
orignal hmm, interesting
orignal didn't know that you even CAN expire faster
zzz it's not ideal, but if the RI isn't in your keyspace then you really don't need to keep it
orignal good point
orignal will try to implement it
orignal thanks
zzz basically a probabalistic drop if older than 30 minutes if we're over 4000 routers
zzz like this:
zzz private static final int LIMIT_ROUTERS = SystemVersion.isSlow() ? 1000 : 4000;
zzz long cutoff = now - 30*60*1000;
zzz boolean isFF = _facade.floodfillEnabled();
zzz byte[] ourRKey = isFF ? us.getData() : null;
zzz // chance in 128
zzz int pdrop = Math.max(10, Math.min(80, (128 * count / LIMIT_ROUTERS) - 128));
zzz int removed = 0;
zzz if (_log.shouldLog(Log.INFO))
zzz _log.info("Expiring routers, count = " + count + " drop probability " +
zzz (count > LIMIT_ROUTERS ? pdrop * 100 / 128 : 0) + '%');
orignal probabalistic or based on DHT?
zzz foreach router {
zzz if (e.getDate() < cutoff) {
zzz if (isFF) {
zzz // don't drop very close to us
zzz byte[] rkey = gen.getRoutingKey(key).getData();
zzz int distance = (((rkey[0] ^ ourRKey[0]) & 0xff) << 8) |
zzz ((rkey[1] ^ ourRKey[1]) & 0xff);
zzz // they have to be within 1/256 of the keyspace
zzz if (distance < 256)
zzz continue;
zzz if (almostMidnight) {
zzz // almost midnight, recheck with tomorrow's keys
zzz rkey = gen.getNextRoutingKey(key).getData();
zzz distance = (((rkey[0] ^ ourRKey[0]) & 0xff) << 8) |
zzz ((rkey[1] ^ ourRKey[1]) & 0xff);
zzz if (distance < 256)
zzz continue;
zzz if (getContext().random().nextInt(128) < pdrop) {
zzz _facade.dropAfterLookupFailed(key);
zzz removed++;
orignal great
zzz so if they're within 1/256 of our routing key, we let them stay until 1 hour; otherwise we do a probabalistic drop if older than 30 minutes
orignal so absolute minimum is 30 minutes now
zzz yeah that's what we have now
orignal the problem I see you will build tunnel through close to your only
zzz I did this on Feb. 11, haven't really looked at it much since
zzz nah because the pdrop is pretty low, it doesn't keep it at 4000; more like 8000-10000 max, iirc
orignal then you have the same problem
orignal if the network grows you will see much more routers in the netdb
zzz sure, it's just one part of the defenses. But most of the routers in any ff are just ones that connected to you. They're not in your keyspace
zzz 16K / 1.5K = 10:1 x 4 redundancy from flooding is only 40 routers per ff in your keyspace
zzz I;m sure the code above could be tweaked, you could change the 30 minutes, change the 1/256 number, change the probabilities and the threshold, etc
zzz but thats the idea
orignal I mean 30 minutes if not a final value
orignal it should depend on total number of routers
orignal say if you have 50K it might be reduced to 15 minutes
zzz sure
zzz iirc even during the attack, when i2pds were seeing 50K RIs, most java ffs were < 10K with this change
zzz but everything can be tweaked
orignal fake routers is another problem
zzz it was good enough for us in February
zzz but if you have 16K RIs and only 40 are in your keyspace, you can gain a lot by expiring the others faster
orignal I know