IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2023/10/15
@eyedeekay
&eche|on
&kytv
&zzz
+R4SAS
+RN
+T3s|4
+acetone
+dr|z3d
+orignal
+polistern
+postman
An0nm0n
Arch
FreefallHeavens
Gid
Hikari
Irc2PGuest2974
Irc2PGuest4253
Irc2PGuest47041
Irc2PGuest51959
Leopold
Minogami
Onn4l7h
Sleepy
Soni
T3s|4_
Teeed
aargh1
admin
anon
apt0110
b3t4f4c3__
cheddah
eyedeekay_bnc
itsjustme
j6
limak
not_bob_afk
pihole2
poriori
profetikla
qend-irc2p
rapidash
tbqdrn
theglitch
u5657
user101
w8rabbit
weko
x74a6
yourtrueself
zer0bitz
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