Yeah they assume it could either be because of one of the following reasons:
1. Some people discussed carrying out a DDOS attack on Gasprom, some expect this to be a reaction to that as the DDOS on Dread started in the following days.
2. A big DNM trying to hide an exit scam.
I think the first assumption is BS because a big corporation like Gasprom probably has other issues rn than DDOSSing Dread lol
1. Some people discussed carrying out a DDOS attack on Gasprom, some expect this to be a reaction to that as the DDOS on Dread started in the following days.
2. A big DNM trying to hide an exit scam.
I think the first assumption is BS because a big corporation like Gasprom probably has other issues rn than DDOSSing Dread lol
They are still under heavy DDoS
http://dreadytofatroptsdj6io7l3xptbet6onoyno2yv7jicoxknyazubrad.onion -
Last Online: Sun Sep 18 15:44:26 2022 UTC
is there ip2 also down ? who have that link ?
http://dreadytofatroptsdj6io7l3xptbet6onoyno2yv7jicoxknyazubrad.onion -
Last Online: Sun Sep 18 15:44:26 2022 UTC
is there ip2 also down ? who have that link ?
Message from Paris admin off dread ( source tor.taxi )
i2p is up and stable.
Money was burnt. But anything to fuck the DDOSERs mom. We don't give a single fuck what it takes. Dread stays up.
Edit (14th): More adjustments and cost savings!
We could have been just straight up and stable but watching money burn in the front of my eyes hurt too much. So I focused today on optimizing the circuit handshakes process (side stepping the single thread pool and spreading the requests over multiple independent tor process with basically the same memory state to prevent the SINGLE thread pool from blocking everything [TorProject why is there only... one... single... fucking... thread... pool for all this onion handshake shit? Modern cpus have cores for days. DAYS! fuck your cpuworker.c library. Spaghettied all over the place. GIVE ME TRUE THREADING. EAT THE COMPUTE. Just because people can container this shit to sidestep your asshole design doesn't mean this is okay. OKAY?])
Tor values have been tweaked. I did a solid for the Tor network too by statistically spreading the load over basically all the guards. Otherwise there would have been a lot more guard nodes dying all over the place. POW is coming and this attack will be just a bad time in the past. But right now we be optimizing.
Edit (16th): The Tor network is starting to have ripple effects:
metrics.torproject.org
While generally this won't result in failures of the circuits at this point. The extra circuit building load has shown to be extremely taxing on the network hurting the overall throughput. There is good news though. After a lot of testing I have a onionbalancing design which should be effective at equally spreading introduction the load over many fronts. With the limits of introduction points on a single V3 descriptor being 20 it's not enough to get uptime. Pushing distinct descriptors on the network is the only way to get these servers up under an attack like this. The current design of distinct descriptors leave a lot wanting because the load isn't as equally spread out as it needs to be. Specifically to introduction points that are controlled by me so no foolishness can happen (and descriptor rejections can be minimized/eliminated as much as possible). After I'm done with it there will be effectively minimal descriptor rotation even under excessive load.
This will be my crown achievement. Protocol layer flaw avoidance by overtaking the entire onion introduction process.
i2p is up and stable.
http://dreadtoobigdsrxg4yfspcyjr3k6675vftyco5pyb7wg4pr4dwjq.b32.i2p
Money was burnt. But anything to fuck the DDOSERs mom. We don't give a single fuck what it takes. Dread stays up.
Edit (14th): More adjustments and cost savings!
We could have been just straight up and stable but watching money burn in the front of my eyes hurt too much. So I focused today on optimizing the circuit handshakes process (side stepping the single thread pool and spreading the requests over multiple independent tor process with basically the same memory state to prevent the SINGLE thread pool from blocking everything [TorProject why is there only... one... single... fucking... thread... pool for all this onion handshake shit? Modern cpus have cores for days. DAYS! fuck your cpuworker.c library. Spaghettied all over the place. GIVE ME TRUE THREADING. EAT THE COMPUTE. Just because people can container this shit to sidestep your asshole design doesn't mean this is okay. OKAY?])
Tor values have been tweaked. I did a solid for the Tor network too by statistically spreading the load over basically all the guards. Otherwise there would have been a lot more guard nodes dying all over the place. POW is coming and this attack will be just a bad time in the past. But right now we be optimizing.
Edit (16th): The Tor network is starting to have ripple effects:
Performance – Tor Metrics
metrics.torproject.orgWhile generally this won't result in failures of the circuits at this point. The extra circuit building load has shown to be extremely taxing on the network hurting the overall throughput. There is good news though. After a lot of testing I have a onionbalancing design which should be effective at equally spreading introduction the load over many fronts. With the limits of introduction points on a single V3 descriptor being 20 it's not enough to get uptime. Pushing distinct descriptors on the network is the only way to get these servers up under an attack like this. The current design of distinct descriptors leave a lot wanting because the load isn't as equally spread out as it needs to be. Specifically to introduction points that are controlled by me so no foolishness can happen (and descriptor rejections can be minimized/eliminated as much as possible). After I'm done with it there will be effectively minimal descriptor rotation even under excessive load.
This will be my crown achievement. Protocol layer flaw avoidance by overtaking the entire onion introduction process.
Here are some links Paris has shared. Those onse should work fine.
/u/Paris
A
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Seems the other ones got focused hard now. Being that my goal is to get the main Dread url back online and not spent too many resources into the testing servers I've rotated them yet again.
Here are some new URLS (again signed by my /u/Paris PGP key), vist them and use them over the Dread url at this time.
frz6q5lqfrixg6vto2iy7v7lvq3i3jhet5oddyhg6tyuusq3t7k37nqd.onion
yl4mvqmgze2hti3t3x7mos2262ts2z4crshcdeurslkzhselu5bg3qad.onion
p5xdo22k72vofu4lqh5vv4hrxaucqh2kadporinh2tnbpfzzdl27fpid.onion
n7bpmxvqhct4eyuqlhckhnxhqskyoicncomj7xsx3adx7m7nacsuk4ad.onion
tswquihqsswt6pxgjzfzkltvrth53zcmzpktrjzaafo3q7wemvwdsuid.onion
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEbfleES3oPdbct1q5DE1JcU+sN9gFAmMkBFwACgkQDE1JcU+s
N9jcmxAA5jrqP5ShBLRFphi3k5eHHESBwF72Dl4CQPFzl8FFBUrwckE4ayztGeBg
lkkRex4p2Q2EZYfyf9AumTJQMVwxH04XrAk5A/DCFXKh6MA8sx86Tj3TnqbOy35w
H0G6icJeiPyrdaiCwg5O3U4tt90aBeBP/MMaUziGEAU27KRqZ5ASS2GVOMMCHXyY
5Hm8egi5224+RcUFL4Ajkd4YX37rqjaHFh6rQfyViul2NnUNa/glqcLss9zoE8HK
ssEQd1mcKYBjOSpjJZpfKE1tFi3ydtOkDefWhK6z4ZqGjYE7O4dXXuV6kvCl+fnH
43vD2fUnkEhicfFTh9w+XqdelHgezDdqtZF2aD9yvaPHS5gjIMa6PTFoHoRENGcr
zJEl+MDsTmcEWn4mIdWvySOYmEKO3/hX/D2SWnZ+btKIPe4MRDeVw9w22iLIS9X6
ep9MZqw+wEZiYmF0NIKsg4q5NVkH7gVRqSco4WKdLJQnoYXBc7ZGP3V4tXO0LLuO
bEdIsAg9ksuqXticSbXwsZMjTsV89+PvPYjH+BdaOKrHghO6s4TU+W4I2LsMnfRn
NaQFRUYvanFMe/vyvXuaJinHGTF6sA3U/W+894Xl6V6ZZgWGWTQTh44CkzVn+ofb
Za6nBMFCaZ1Yd/a+5Xp3n+7/CctrG8DkmF2AiPniqVkUPYqq8f8=
=XeGa
-----END PGP SIGNATURE-----
/u/Paris
A-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Seems the other ones got focused hard now. Being that my goal is to get the main Dread url back online and not spent too many resources into the testing servers I've rotated them yet again.
Here are some new URLS (again signed by my /u/Paris PGP key), vist them and use them over the Dread url at this time.
frz6q5lqfrixg6vto2iy7v7lvq3i3jhet5oddyhg6tyuusq3t7k37nqd.onion
yl4mvqmgze2hti3t3x7mos2262ts2z4crshcdeurslkzhselu5bg3qad.onion
p5xdo22k72vofu4lqh5vv4hrxaucqh2kadporinh2tnbpfzzdl27fpid.onion
n7bpmxvqhct4eyuqlhckhnxhqskyoicncomj7xsx3adx7m7nacsuk4ad.onion
tswquihqsswt6pxgjzfzkltvrth53zcmzpktrjzaafo3q7wemvwdsuid.onion
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEbfleES3oPdbct1q5DE1JcU+sN9gFAmMkBFwACgkQDE1JcU+s
N9jcmxAA5jrqP5ShBLRFphi3k5eHHESBwF72Dl4CQPFzl8FFBUrwckE4ayztGeBg
lkkRex4p2Q2EZYfyf9AumTJQMVwxH04XrAk5A/DCFXKh6MA8sx86Tj3TnqbOy35w
H0G6icJeiPyrdaiCwg5O3U4tt90aBeBP/MMaUziGEAU27KRqZ5ASS2GVOMMCHXyY
5Hm8egi5224+RcUFL4Ajkd4YX37rqjaHFh6rQfyViul2NnUNa/glqcLss9zoE8HK
ssEQd1mcKYBjOSpjJZpfKE1tFi3ydtOkDefWhK6z4ZqGjYE7O4dXXuV6kvCl+fnH
43vD2fUnkEhicfFTh9w+XqdelHgezDdqtZF2aD9yvaPHS5gjIMa6PTFoHoRENGcr
zJEl+MDsTmcEWn4mIdWvySOYmEKO3/hX/D2SWnZ+btKIPe4MRDeVw9w22iLIS9X6
ep9MZqw+wEZiYmF0NIKsg4q5NVkH7gVRqSco4WKdLJQnoYXBc7ZGP3V4tXO0LLuO
bEdIsAg9ksuqXticSbXwsZMjTsV89+PvPYjH+BdaOKrHghO6s4TU+W4I2LsMnfRn
NaQFRUYvanFMe/vyvXuaJinHGTF6sA3U/W+894Xl6V6ZZgWGWTQTh44CkzVn+ofb
Za6nBMFCaZ1Yd/a+5Xp3n+7/CctrG8DkmF2AiPniqVkUPYqq8f8=
=XeGa
-----END PGP SIGNATURE-----