Mass DDOS part 2

[eleuthria]

Copied from my post on Slush's thread, relevant to this topic:

Better yet, everybody should hop to a small pool.  Everybody jumping to BTC Guild ends up screwing over our regular users.  I've been removing servers from our clusters the last month due to shrinking speeds/profits.  We cannot handle 2+ TH/sec like we used to, because it isn't worth keeping up the hardware at this time.  That's why I'm looking at cancelling signups (private pool) or a major payout structure change:  Get the botnets off and keep our regular users with a stable pool.

So please:  If you mine on Slush, Deepbit, or BTC Guild, set your backup to a SMALL pool.  Not only is it more reliable (the major pool outages are often related), but it avoids putting unexpected heavier load on an already large pool.  And of course it's safer for the network to have the hash split between a larger number of nodes.

[SolidBitShop]

Hmm that is all strange with that pools hope it will resolv quickly.

As for me coinotron.com is working just fine and gaining power, no ddos attempt so far.

[Mageant]

I thought DDOS attacks were "only because of the upcoming hashrate change deadline"?
So what's the explanation now?
Unless it really is the banking interests.

[Brian DeLoach]

I thought DDOS attacks were "only because of the upcoming hashrate change deadline"?
So what's the explanation now?
Unless it really is the banking interests.

Silly talk. I've never heard anyone say DDOS attacks only occur close to a re-target. If the goal was to lower difficulty it doesn't make a difference when to bring down the hashrate, only that you take it down for a significant amount of time. Not even going to touch the "banking interests" line.

[Mageant]

I thought DDOS attacks were "only because of the upcoming hashrate change deadline"?
So what's the explanation now?
Unless it really is the banking interests.

Silly talk. I've never heard anyone say DDOS attacks only occur close to a re-target. If the goal was to lower difficulty it doesn't make a difference when to bring down the hashrate, only that you take it down for a significant amount of time. Not even going to touch the "banking interests" line.

I read about 4 posts on these forums saying this last week.

[Matthew N. Wright]

The raptors are testing the fences.

[Mageant]

I thought DDOS attacks were "only because of the upcoming hashrate change deadline"?
So what's the explanation now?
Unless it really is the banking interests.

Silly talk. I've never heard anyone say DDOS attacks only occur close to a re-target. If the goal was to lower difficulty it doesn't make a difference when to bring down the hashrate, only that you take it down for a significant amount of time. Not even going to touch the "banking interests" line.

I read about 4 posts on these forums saying this last week.

What's the big mystery?

The raptors are testing the fences. Grow up.

It's no big mystery to me.
I'm just taunting the shills.

[sadpandatech]

I thought DDOS attacks were "only because of the upcoming hashrate change deadline"?
So what's the explanation now?
Unless it really is the banking interests.

Silly talk. I've never heard anyone say DDOS attacks only occur close to a re-target. If the goal was to lower difficulty it doesn't make a difference when to bring down the hashrate, only that you take it down for a significant amount of time. Not even going to touch the "banking interests" line.

I read about 4 posts on these forums saying this last week.

What's the big mystery?

The raptors are testing the fences. Grow up.

It's no big mystery to me.
I'm just taunting the shills.

Last change 149184 14/10/2011 01:44 1'468'844.65 x0.89
Last 120 149797-149917 19/10/2011 19:13 1'345'917.52 x0.92
Last 10 149907-149917 19/10/2011 19:13 839'020.17 x0.57
Next 151200 29/10/2011 12:35 1'330'841.97 x0.91

  The current estimate for Next change is 2 days sooner than it was 34~ hours ago.. An attack lasting any significant time will push that out past the current 10/29. With the already expected drop average of about 200k it would put it at about 17~ days. To repeat, we are currently ahead of that.(likely thanks to some awesome luck at some pools).(And possibly bots successfully solving a few before they broke everything over the past few days). Those shills be dumb..  

  And I noticed someone posted about an attack for the purpose of shifting the time to retarget, stating it would not matter 'when'. This is not entirely true. The 'length' of attack is certainly the heaviest weight in the formula but the 'when' matters also. Crunch the math of an attack dropping 40% of the global hash rate out during the first 500 blocks after retarget and then again on an attack that did the same for the last 500 blocks... In my head it would seem the earlier attack would have the bigger impact on time to next retarget.. My head is old and fuzzy though, so without giving a shit to punch in the numbers it is highly likely I am delusional...

  An ideal attack would be to push the Dif back up as much as possible right before a retarget and then drop the added hash out. This would have the immediate impact of making the first few days of blocks after retarget take unusually long to solve. Variance aside, of course.

  Cheers, Shill Poker, Mageant

TL;DR Rabble Rabble, I like cheese!    

[rotrott]

Why don't the botnet operators simply run their own pool server?

Or maybe they are already and they're trying to run everyone else off so their pool can take more of the pie.

[sadpandatech]

Why don't the botnet operators simply run their own pool server?

  Probably because that would require actual work to code and pay for hosting for servers that could handle all the connections. And, it would not allow them to force their agenda on everyone.....


  Edit;  The pie doesn't work that way. Each solution has a chance to be a correct block. Best case scenario they chase off all the lazies and 'EVENTUALLY', very slowly and painfully the difficulty will drop a bit more than it would be otherwise in the long run.. It really only delays the time to retarget if sustained long enough. It wouldn't take more than a few brain cells put to the profibilaty calculations of such a prospect to see they would just extend the 'time to profitability' at what their target difficulty would be to be profitable. If they of course were thinking that. I highly doubt it and am certain their agenda is much more obvious...

[phillipsjk]

Ironically, botnet operators can not easily switch their nodes to solo mining. Even if UPnP is employed for firewall piercing, many users will likely notice 12 hours of disk activity as their node catches up to the block-chain.

[sadpandatech]

Ironicly, botnet operators can not easily switch their nodes to solo mining. Even if UPnP is employed for firewall piercing, many users will likely notice 12 hours of disk activity as their node catches up to the block-chain.

 Oh yea, on that note, so will the zombie's internet providers. Atleast if they are with ATT.. I received an interesting email from ATT;


  IMPORTANT COMPUTER SAFETY NOTICE from AT&T Internet Services Security Center -“IRC Traffic Detected”

Our investigation shows that the following IP was assigned to your log-on session at the indicated time and was using IRC connections to a computer network which is possibly a Botnet.

Date: (UTC) => Your IP:
2011-10-18 04:45:24 => My Business T1 IP
2011-10-17 04:23:13 => My Business T1 IP
2011-10-16 02:47:36 => My Business T1 IP


IRC Botnet infected systems commonly send or receive commands that can SPAM email, spread malicious software, and perpetrate identity theft.

IRC traffic on ports other than those normally used by IRC can be an indication of backdoor trojans or bots.


IRC Botnet infected systems commonly send or receive commands that can SPAM email, spread malicious software, and perpetrate identity theft.

IRC traffic on ports other than those normally used by IRC can be an indication of backdoor trojans or bots.

Although the activity is likely unintentional, it is still in violation of AT&T's Acceptable Use Policy. To review the AT&T Acceptable Use Policy, go to:  http://www.corp.att.com/aup/


   It was certainly news to me that they had a 'policy' against connecting to IRC servers on non default ports.  The times they reference are in direct correlation to my firing up the Bitcoin Client.. ;p
  I made sure to contact them on it none the less, because they do have a history of disabling accounts if they truely do suspect one of being 'zombiefied'.  I did not mention Bitcoin or anything but basicly told them that unless they had something in their policy about what remote IRC ports I am allowed to connect to, to please not send me further messages about it. I'm an asshole when it comes to them people. I pay for a home connection and 2 businesses worth of internet and phone servicve with them. Total about 4 grand a month, so they can kiss my shiny, white ass....

  But, it does make me wonder if they have jumped on the security bandwagon that has it in mind to flag Bitcoin related communications as infectious transmissions...?  And, will they decide to block it? They certainly are more than capable with their NAT setup to do so....  The next release of Bitcoin will have to include a built in http proxy just to fuggin work if something like that were to happen. Something to think about.

   And, also something for you agenda pushing Botnet fuckers to think about. I will be extremely pissed if because of your agenda you get 'Bitcoin' traffic in general banned..... Or is that your true goal!?!? hmmm *tinfoil hat feels warm*

[Shevek]

We cannot handle 2+ TH/sec like we used to, because it isn't worth keeping up the hardware at this time.  That's why I'm looking at cancelling signups (private pool) or a major payout structure change:  Get the botnets off and keep our regular users with a stable pool.

I have an idea that could help: instead of accepting bare shares, pools may accept shares over a given small difficulty; say 4, 8, 16... of course accepted shares should count up as 4, 8, 16... "normal" shares. This countermeasure should get down the legal flood and make easier to identify the DDoS flow.

I don't know how much miner software should be amended to avoid alarming high rates of states if such solution is implemented.

[eleuthria]

We cannot handle 2+ TH/sec like we used to, because it isn't worth keeping up the hardware at this time.  That's why I'm looking at cancelling signups (private pool) or a major payout structure change:  Get the botnets off and keep our regular users with a stable pool.

I have an idea that could help: instead of accepting bare shares, pools may accept shares over a given small difficulty; say 4, 8, 16... of course accepted shares should count up as 4, 8, 16... "normal" shares. This countermeasure should get down the legal flood and make easier to identify the DDoS flow.

I don't know how much miner software should be amended to avoid alarming high rates of states if such solution is implemented.

Changing difficulty won't affect pool traffic as much as people think.  Your miner will ask for work exactly as often as it already does.  It simply will submit fewer shares.  The vast majority of pool traffic is obtaining new work, not submitting shares.

The biggest issue of pool overhead is in longpoll connection handling.  When you have large numbers of active connections, things start to randomly slow down.

[MagicalTux]

MtGox was hit with ~11Gbps of ddos.

Peak Bits Per Second: 11.67 Gbps
Attack Types: UDP Flood, UDP Fragment
Event Time Start: Oct 19, 2011 15:00:00 UTC

No downtime to report.

[322i0n]

it would've great to get one of these hooked up https://en.bitcoin.it/wiki/P2Pool

[2112]

No downtime to report.

Are you allowed to report how much you pay per month to Barret Lyon and his friends?

Edit: Oh, noes, it looks like Barret had sold Prolexic.

[sadpandatech]

MtGox was hit with ~11Gbps of ddos.

Peak Bits Per Second: 11.67 Gbps
Attack Types: UDP Flood, UDP Fragment
Event Time Start: Oct 19, 2011 15:00:00 UTC

No downtime to report.

 Upstream side UDP filter ftw? Or you got mad moxy on your side?


 

[MagicalTux]

MtGox was hit with ~11Gbps of ddos.

Peak Bits Per Second: 11.67 Gbps
Attack Types: UDP Flood, UDP Fragment
Event Time Start: Oct 19, 2011 15:00:00 UTC

No downtime to report.

 Upstream side UDP filter ftw? Or you got mad moxy on your side?

All connections are going through prolexic, which protects us from ddos attacks. It's expensive, but considering the loss (in trade fee revenue and image) generated by the website going down, it's worth it.

[BitcoinPorn]