IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2025/03/30
@eyedeekay
&eche|on
&zzz
+R4SAS
+RN_
+StormyCloud
+T3s|4
+cumlord
+dr|z3d
+eche|off
+hagen
+orignal
+postman
+qend-irc2p
+snex
+wodencafe
Arch
Birdy
Daddy
Danny
FreefallHeavens
Irc2PGuest20240
Irc2PGuest23513
Irc2PGuest6381
Irc2PGuest77981
Irc2PGuest94709
Irc2PGuest98458
Onn4l7h
Onn4|7h
Over
Sisyphus
Sleepy
SlippyJoe
Stormycloud_
aargh2
ac9f
acetone_
anontor
b3t4f4c3__
dr4wd3
duanin2
duck
gellegery
leopold
makoto
mareki2p_
n1
nilbog
noidea
not_bob_afk2
nyaa2pguy
onon_
poriori_
profetikla
r00tobo
rapidash
shiver_
solidx66
thetia
u5657
uop23ip
user1
vivid_reader56
w8rabbit
x74a6
zelgomer
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?