What happened to Dread?

[bbgate]

Hi all, who knows what happened to Dread? It doesn't work...

 

[Saul]

they are under attack DDOS

 

[manistrying]

dread should prolly be bck soon

 

[KokosDreams]

they are under attack DDOS

SaulYeah 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

 

[Saul]

it is taken to long already for a market to exit .
we dont know who is behind it
it takes a lot of money and resources to run such a powerful DDOS
it has been going on for 1 week now so we can conclude that it is not a market that DDOS dread

 

[KokosDreams]

it is taken to long already for a market to exit .
we dont know who is behind it
it takes a lot of money and resources to run such a powerful DDOS
it has been going on for 1 week now so we can conclude that it is not a market that DDOS dread

SaulYeah probably right, could be LE too tbh

 

[bbgate]

Doesn't that have something to do with the fact that the canary hasn't been updated there since September 5? Is there somewhere to read comments about what's going on from the Dread admins?

 

[KokosDreams]

Doesn't that have something to do with the fact that the canary hasn't been updated there since September 5? Is there somewhere to read comments about what's going on from the Dread admins?

bbgateThat makes sense.

I am not sure if there are other places outside of dread where it would be possible to catch a statement.

A colleague of mine actually was able to access dread earlier today, but it started to get bad again some hours ago

 

[bbgate]

The hell with it, I didn't like him much anyway.

 

[KokosDreams]

The hell with it, I didn't like him much anyway.

bbgateIt would be a great loss to the whole DN community if dread would remain down.

 

[Saul]

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 ?

 

[Gerald Cotten]

ip2 should be up and running. Also Paris provided new onion links from which you can enter. But i failed to safe them.

He is very sure that the main links will start to work again in the next couple of days.

 

[Saul]

ip2 should be up and running. Also Paris provided new onion links from which you can enter. But i failed to safe them.

He is very sure that the main links will start to work again in the next couple of days.

Gerald Cotten
they are back online

 

[KokosDreams]

RIP Dread! Hope they'll be back soon, got some business to do there lol

 

[breathing]

İ hope they will back soon.damnnn it was good forum.ngl

 

[KokosDreams]

İ hope they will back soon.damnnn it was good forum.ngl

breathingYeah man, DN is not the same without Dread.

But at the same time, we'll hopefully get more users over here..

I am still wondering who did this DDOS!

 

[Saul]

Message from Paris admin off dread ( source tor.taxi )

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.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.

 

[KokosDreams]

Message from Paris admin off dread ( source tor.taxi )

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.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.

SaulThanks for sharing Saul,

someone must be very mad man!!

Good they're back

 

[Gerald Cotten]

Message from Paris admin off dread ( source tor.taxi )

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.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.

SaulJust tested to access the i2p. It seems to be offline.

But i was able to access dread via the mainlink!!

http://dreadytofatroptsdj6io7l3xptbet6onoyno2yv7jicoxknyazubrad.onion/

 

[Gerald Cotten]

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-----