IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2025/03/30
@eyedeekay
&zzz
+FreefallHeavens
+R4SAS
+RN_
+Romster
+StormyCloud
+cims
+eche|off
+hagen
+nilbog
+nyaa2pguy
+orignal
+postman
+qend-irc2p
+rednode
+snex
+wodencafe
Arch
Birdy
Danny
Holmes
Irc2PGuest17692
Irc2PGuest28384
Irc2PGuest57320
Irc2PGuest80681
OfficialCIA
Onn4l7h
Onn4|7h
Over1
Sleepy
T3s|4_
U1F642
Wikk_0
Zapek
aargh4
ac9f
acetone_
ahiru
ananas_
anontor2
dr4wd3_
duanin2
eyedeekay_
eyedeekay_bnc
leopold
mahlay
makoto
marek
n2_
not_bob_afk
poriori_
profetikla
r00tobo
rapidash
sahil
test3847473
uop23ip
urist_
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?