IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2025/03/30
@eyedeekay
&Irc2PGuest88200
&zzz
+R4SAS
+RN
+StormyCloud
+T3s|4
+acetone
+dr|z3d
+eche|off
+hagen
+mareki2p
+orignal
+postman
+radakayot
+segfault
+snex
+wodencafe
Arch2
Danny
DeltaOreo
FreeB
FreefallHeavens
Irc2PGuest53192
Irc2PGuest59134
Irc2PGuest59581
Irc2PGuest64993
Irc2PGuest96449
Onn4l7h
Onn4|7h
Sisyphus
Sleepy
T3s|4_
aeiou
ardu
b3t4f4c3___
b4dab00m
bak83_
boonst
cumlord
death
dr4wd3
duck
enoxa
eyedeekay_bnc
not_bob_afk
onon_
phil1
phobos_
pisslord
poriori_
profetikla
qend-irc2p
rapidash
shiver_1
solidx66
u5657
uop23ip
w8rabbit
x74a6
orignal 2.9.0 e.g. major release?
orignal when?
zzz <eyedeekay> mid-late may then?
zzz <orignal> fine for me
dr|z3d *** smiles. ***
dr|z3d stay off the crack, orignal, it's making you forgetful! :)
EKCKABATOR54 Hello, zzz. I've been thinking a bit about congestion control in i2p. The main thing that worries me, and what prevents me from moving on to testing the effectiveness of specific algorithms, is the probability of opening attacks aimed at deanonymization due to an incorrectly chosen CC algorithm. Do you have any thoughts on this? I've skimmed through several articles from Tor about CC and I got the impre
EKCKABATOR54 d to be a more dangerous class of algorithms, although personally I don't understand why this does not apply to delay-based algorithms to the same extent.
zzz Not familiar with the papers, your threat model, or where you're poking around, so can't offer any advice
zzz eyedeekay, you're doing the website, right?