Just want to say I support both Slush and Eleuthria, you guys both run two of my favorite pools and have both made huge contributions to Bitcoin. I dont believe either one of you has done anything wrong, your both trying desperately to keep your pools running just like anyone else would do.
Websites of mine have also been attacked and because of those attacks I am currently looking for new hosting, and although I am not sure why the attacks happened - I think that being a part of Bitcoin makes us all targets in some ways.
One thing that is a cold hard fact about these DDoS attacks is they are based from greed, and as long as it is profitable for someone to attack - attacks will continue.
Topic: BTCGuild and it's relation to DDoS attackers (Read 10857 times)
Replied in the relevant thread, but one question though - do solidcoin (and hypothetical bot-buddeh) estimations account for behaviors associated with pig blocks trusted nodes ?
Anyway, methinks it would be best to wait and see, just gotta not to forget to check SC2 hashrate if / when next DDoS spree happens...
Anyway, methinks it would be best to wait and see, just gotta not to forget to check SC2 hashrate if / when next DDoS spree happens...
Kind gentlemen here might find this interesting: https://bitcointalksearch.org/topic/sc2-diff-drop-related-to-the-recent-attacks-on-bitcoin-pools-49255
That is a very interesting read. No, I don't think it points to SC2 owner, etc. But whoever this 'Dick' person was, I would like more info....
Are you able to do the math on just how much hash power they had mining SC2 prior to the BTC pool attacks and them not mining SC2 any more??
As I indicated in that thread it was roughly 800 cpu. Network hashing power was ~50MH/s.
SC2 gets about 30KH/s on average 4 core CPU.
50,000 KH / 30KH per CPU = ~ 1600 CPU. "Dick" had 50% of hashing power (that should be scary right there, a single miner has 50% of network hashing power) so ~800 CPU.
The DDOS attacks against Bitcoin were magnitudes larger is the incoming bandwidth floods reported by pool operators are accurate.
Much agreed, I replied more on the numbers in the other thread, m8.
Kind gentlemen here might find this interesting: https://bitcointalksearch.org/topic/sc2-diff-drop-related-to-the-recent-attacks-on-bitcoin-pools-49255
That is a very interesting read. No, I don't think it points to SC2 owner, etc. But whoever this 'Dick' person was, I would like more info....
Are you able to do the math on just how much hash power they had mining SC2 prior to the BTC pool attacks and them not mining SC2 any more??
As I indicated in that thread it was roughly 800 cpu. Network hashing power was ~50MH/s.
SC2 gets about 30KH/s on average 4 core CPU.
50,000 KH / 30KH per CPU = ~ 1600 CPU. "Dick" had 50% of hashing power (that should be scary right there, a single miner has 50% of network hashing power) so ~800 CPU.
The DDOS attacks against Bitcoin were magnitudes larger if the incoming bandwidth floods reported by pool operators are accurate.
A lot of interesting things
Kind gentlemen here might find this interesting: https://bitcointalksearch.org/topic/sc2-diff-drop-related-to-the-recent-attacks-on-bitcoin-pools-49255
That is a very interesting read. No, I don't think it points to SC2 owner, etc. But whoever this 'Dick' person was, I would like more info....
Are you able to do the math on just how much hash power they had mining SC2 prior to the BTC pool attacks and them not mining SC2 any more?? Even then it could be coincidence but would be nice to be able to validate if there was even enough hash power there. There was a TON of zombies pointed at BTC pool servers, etc. Enough so, that even if all were only cpu miners they would make quite a huge combined hash on SC2. So, we really must know this number and any other info, links, etc on said miner..
Quote
Then you are pretty weak sysadmin because DNS server change can easily take over 24 hours for busy server.. it usually takes much less time with small web sites.
What the hell are you talking about?
Then you are pretty weak sysadmin because DNS server change can easily take over 24 hours for busy server.. it usually takes much less time with small web sites.
I don't think you have the faintest idea of what you are talking about. Are you suggesting a busy website makes DNS take longer to propogate? Really?
Tell me how the webserver affects DNS.
Well, it might be that Guild was chosen by someone as a "convenient scapegoat" due to persistent rumors that seem to be associated with them (that makes framing easier)
P.S.:
Full disclosure:
Lolcust mines @ simplecoin.us out of cointriotism and pooltriotism
P.S.:
Full disclosure:
Lolcust mines @ simplecoin.us out of cointriotism and pooltriotism
I doubt the person behind DDoS specifically wrote the bots to resolve the domain name every now and then while sending packets. Why add such overhead? I don't know many programmers who ever need to write anything like that. Actually it is usually even the opposite, people force their software to automatically use IP addresse after resolving the IP for the very first time to reduce overhead.
Most likely all the machines behind DDoS had the domain name IP locally cached and with most router/computer configurations if you are actively using some addresse it takes very long time to flush the local cache. In fact it might never happen if you constantly query something from that domain.
Saying that the attack didn't go over to btcguild and because of that they are to blame is funny. You must really hate them very much slush.
Most likely all the machines behind DDoS had the domain name IP locally cached and with most router/computer configurations if you are actively using some addresse it takes very long time to flush the local cache. In fact it might never happen if you constantly query something from that domain.
Saying that the attack didn't go over to btcguild and because of that they are to blame is funny. You must really hate them very much slush.
Um that would be the worst botnet operator in the history of computing industry.
To defeat this "idiot botnetter"
Step 1: change local IP address of server being attacked. Setup a dummy server to take the DDOS attack and assign it the attacked IP address.
Step 2: update DNS so attacked domain points to new IP address.
Step 3: you winz because the idiot is now targetting nothing.
Obviously the botnet needs to periodically use DNS to keep the attack "on target". If you read Slush indicated (both in this thread and durring the attack) that he changed the DNS record to point to new servers multiple times and EVERY SINGLE TIME the attack followed the updated DNS. He also added new domains pointing to new servers and the attack expanded to include those.
There was one exception .... when he pointed the DNS to BTC Guild servers. Then and only then the attack didn't follow the DNS change.
I am not saying BTC Guild was behind it but it is at least "interesting".
Kind gentlemen here might find this interesting: https://bitcointalksearch.org/topic/sc2-diff-drop-related-to-the-recent-attacks-on-bitcoin-pools-49255
Most likely all the machines behind DDoS had the domain name IP locally cached and with most router/computer configurations if you are actively using some addresse it takes very long time to flush the local cache. In fact it might never happen if you constantly query something from that domain.
Saying that the attack didn't go over to btcguild and because of that they are to blame is funny.
Saying that the attack didn't go over to btcguild and because of that they are to blame is funny.
For people who has problem with reading:
Quote from: slush
But *everytime* when I changed DNS records to new IP or even when I created yet another DNS record (do you remember my post about new DNS api3.bitcoin.cz last week?), attack followed those changes in DNS or posts on forum almost immediately
So your post about caching of DNS is teoretically correct, however in real life it work differently.
^^^
Most likely all the machines behind DDoS had the domain name IP locally cached and with most router/computer configurations if you are actively using some addresse it takes very long time to flush the local cache. In fact it might never happen if you constantly query something from that domain.
Saying that the attack didn't go over to btcguild and because of that they are to blame is funny.
Saying that the attack didn't go over to btcguild and because of that they are to blame is funny.
For people who has problem with reading:
Quote from: slush
But *everytime* when I changed DNS records to new IP or even when I created yet another DNS record (do you remember my post about new DNS api3.bitcoin.cz last week?), attack followed those changes in DNS or posts on forum almost immediately
So your post about caching of DNS is teoretically correct, however in real life it work differently.
DNS propogation is not instant, it can take hours in some cases for the new ip's to propagate to all the DNS servers in the world, especially if the server is caching it can take up to 24hrs for the clients to get the new IP, so the DNS test you did doesn't really prove much.
Sorry, this is nonsense. slush said in his post he has a 5 minute timeout on his zone and this is easily verifiable:
$ dig mining.bitcoin.cz
; <<>> DiG 9.7.3 <<>> mining.bitcoin.cz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59770
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 4
;; QUESTION SECTION:
;mining.bitcoin.cz. IN A
;; ANSWER SECTION:
mining.bitcoin.cz. 300 IN A 178.79.183.97
See that 300? 300 seconds, 5 minutes.
No DNS server (unless deliberately misconfigured) will hold onto that value for more than 5 minutes.
It is conceivable that if a client is going through a long chain of DNS servers each with their own cache, that you will see old data for slightly more than 5 minutes, but I would guess this is rare. And it certainly wouldn't be 24 hours.
It is also conceivable that the botnet attacking software could have done one lookup when it started then kept the value until told to do otherwise, but then it would require babying by the operator to keep up with his previous DNS changes when trying to evade them. I doubt this is the case.
Everything slush said about DNS was correct. Yes, I am a sysadmin.
Then you are pretty weak sysadmin because DNS server change can easily take over 24 hours for busy server.. it usually takes much less time with small web sites. But in this context I don't think it even matters. I doubt the person behind DDoS specifically wrote the bots to resolve the domain name every now and then while sending packets. Why add such overhead? I don't know many programmers who ever need to write anything like that. Actually it is usually even the opposite, people force their software to automatically use IP addresse after resolving the IP for the very first time to reduce overhead.
Most likely all the machines behind DDoS had the domain name IP locally cached and with most router/computer configurations if you are actively using some addresse it takes very long time to flush the local cache. In fact it might never happen if you constantly query something from that domain.
Saying that the attack didn't go over to btcguild and because of that they are to blame is funny. You must really hate them very much slush.
A withholding attack causing the pool to have -4% luck would mean the person doing it is reducing their rewards by 4%. That is a lot when we're talking about 80-100 GH/s worth of hashing power.
What if it came from the PPS side of the house? Or did the analysis exclude the PPS pool?
Witholding attack is far more "efficient" against a PPS (or SMPPS variant) pool. The attacker gets paid for every share except the one which is worth something so @ current difficulty they would get all but 1 share in 1.5 million hashes.
wwwwwwwwwwoooooooooooooooooooooowwwwwwwwww...
pool operators cutting deals with botnet operators? pool operators accusing eachother of sabotage? deflecting DDOS attacks?
methinks jack bauer might be running a bitcoin pool in the next season of 24, since this story is a little over the top crazy. what a dark spot on the bitcoin community.
i guess we can thank slush for at least bringing this all to light.
pool operators cutting deals with botnet operators? pool operators accusing eachother of sabotage? deflecting DDOS attacks?
methinks jack bauer might be running a bitcoin pool in the next season of 24, since this story is a little over the top crazy. what a dark spot on the bitcoin community.
i guess we can thank slush for at least bringing this all to light.
Pretty bad analogy. Slush is not in control of the gun, he is using a shield and analyzing the bullets bouncing off of it.
This whole thing got pretty grey when some pools started allowing botnets on board. I am not faulting them, they have very little choice. But once that line was crossed, pools that down allow them and are being attacked at least have the right to try to figure out what is going on.
Totally agree.
+1 And, to add atleast some partial defense, which is not to state right or wrong. But, it was a completly 'faith' based action, in that Slush had faith that it would not cause direct harm and if it did work as he thought it would, that it would help narrow down the list of perps quite a bit.....
Again the only person that would have any breathing room to be angry about it would be Eleuth. And, he is not from best can be garnered from the forum. Anyone else jumping on a finger pointing bandwagon is not seeing the bigger picture or is angry for other reasons......................
I've updated the top ten list.
deepbit, btcguild, ars, slush, bitclockers, abcpool, mmc, btcmine, bitcoins.lc, nmcbit
It seems the ddos hit the four largest pools, and then a few of the rest.
deepbit, btcguild, ars, slush, bitclockers, abcpool, mmc, btcmine, bitcoins.lc, nmcbit
It seems the ddos hit the four largest pools, and then a few of the rest.
Pretty bad analogy. Slush is not in control of the gun, he is using a shield and analyzing the bullets bouncing off of it.
This whole thing got pretty grey when some pools started allowing botnets on board. I am not faulting them, they have very little choice. But once that line was crossed, pools that down allow them and are being attacked at least have the right to try to figure out what is going on.
Totally agree.
next time point it at M$...let them hunt down the botnet 
LOL, or NIST or DoD, etc etc. That would be some funny shit.
Except the first thing they would find would be the dns entry and would likely track who made the change. *sadface* Hopefully they wouldn't just stop there. But its more likely they'd come and lock Slush up in a bamboo cage and poke him with a little stick until he raged!
lol a dns entry of 127.0.0.1 then
let them ddos themselves.
hmmmmm *runs off to see if Dyndns will allow such an entry* Would be very funny if a 'public' dns service will allow it. =) It would certainly atleast make the zombie aware if they were to try and use their high speed internet and the friggin webpages took 10 minutes to load... =)
Jump to: