Just get some sleep/go to work/go have drinks with your friends and stop refreshing your account page every few minutes
Topic: [4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool - page 1070. (Read 4382653 times)
April 20, 2011, 02:30:51 AM
I've seen blocks take 10 hours to find. Granted that was back when the pool was around 80 Ghash/s. It is very unlikely, but still possible to have a block take 6+ hours. It would have to be a very clever attack for this sort of thing to be accomplished.
Just get some sleep/go to work/go have drinks with your friends and stop refreshing your account page every few minutes
Just get some sleep/go to work/go have drinks with your friends and stop refreshing your account page every few minutes
April 20, 2011, 01:50:12 AM
yep... maybe it is possible, but very strange that pool can't find block for so long
Current shares CFD: 99.98 % - and still no block
Current shares CFD: 99.98 % - and still no block
April 19, 2011, 03:51:22 AM
Quote
I prefer ping flooding:
hping3 --flood 69.72.189.147
Unfortunately neither methods would be very successful, that attack was from a corporate line (cirtex corp), But I fully support the name and shame policy you suggested.
April 19, 2011, 03:18:00 AM
Yes, I blocked him with iptables, too. Easiest solution. Currently site has rate limiter and iptables blacklist.
Nice idea, I'll join this effort if fairuser & tycho agree (and I already published the one IP.
Can you please create a list of the attackers?
Nice idea, I'll join this effort if fairuser & tycho agree (and I already published the one IP
. 
April 19, 2011, 01:36:15 AM
Or just blocking all IP addresses from the home of capitalism might solve the problem 
, of course that might not be so open an fair and break the spirit of bitcoin. 
, of course that might not be so open an fair and break the spirit of bitcoin. Hey now...I can assure you that my IP address and my politics have not a damn thing to do with one another.
April 19, 2011, 12:50:43 AM
Yes perhaps a little extreme to block a whole country especially such a big one (not a serious suggestion) although a block on isp like suggested by iptables post could be considered in case of consistent repeated attack.
but.... is it fair to block a whole isp i would also ask, perhaps one individual is ruining it for others, i would probably stick with individual ips until more attacks from the same range where detected. The fact that only 1 ip was used for the attack shows its the intent of 1 at the moment and not some botnet attack.
but kudos to slush as he managed to keep the mining running, but i think it does have confidence hit on miners, when the site is not visible, as we could see that last night of bitcoinwatch as people went back to slush after the site was back up.
but.... is it fair to block a whole isp i would also ask, perhaps one individual is ruining it for others, i would probably stick with individual ips until more attacks from the same range where detected. The fact that only 1 ip was used for the attack shows its the intent of 1 at the moment and not some botnet attack.
but kudos to slush as he managed to keep the mining running, but i think it does have confidence hit on miners, when the site is not visible, as we could see that last night of bitcoinwatch as people went back to slush after the site was back up.
April 18, 2011, 08:08:04 PM
Or just blocking all IP addresses from the home of capitalism might solve the problem , of course that might not be so open an fair and break the spirit of bitcoin.
, of course that might not be so open an fair and break the spirit of bitcoin. And block actual miners as well?
Capitalism... Don't you mean corporatism? And how nice of you to lay the blame on everyone, simply because of where they are born. Not all citizens support the actions of their government. And I would imagine the motives of anyone using or promoting bitcoin should speak for themselves.
Sorry, this has nothing to do with this thread but I couldn't resist myself.
April 18, 2011, 07:08:46 PM
Suggestion...
iptables -A INPUT -s -j DROP
Problem solved. I even blocked a whole ISP because someone was jumping around their IP space.
We've been getting attacked off and on for two weeks now. Looks like someone has it out for the bitcoin pools indeed.
iptables -A INPUT -s
Problem solved. I even blocked a whole ISP because someone was jumping around their IP space.
We've been getting attacked off and on for two weeks now. Looks like someone has it out for the bitcoin pools indeed.
April 18, 2011, 05:24:38 PM
Attacker flooding the server had IP 69.72.189.147
Glove's are off for that botnet bastard now.
2 words "LOIC HIM" or you can chant "LOIC HIM....LOIC HIM" if you are participating in an angry mob.
April 18, 2011, 05:22:06 PM
Attacker flooding the server had IP 69.72.189.147
http://www.dnsstuff.com/tools/whois/?ip=69.72.189.147&j=1&email=onhttp://www.dnsstuff.com/tools/ipall/?tool_id=67&token=&toolhandler_redirect=0&ip=69.72.189.147
http://www.fortressitx.com/index.php?tpl=contact
http://www.web-hosting-top.com/companies/fortressitx.com
It may help...........
Or just blocking all IP addresses from the home of capitalism might solve the problem
, of course that might not be so open an fair and break the spirit of bitcoin. 
April 18, 2011, 05:11:53 PM
Attacker flooding the server had IP 69.72.189.147
Glove's are off for that botnet bastard now.
April 18, 2011, 05:07:21 PM
Really, so easy to dismiss just trying to contribute, Varnish is an HTTP cache engine, Memcached is an engine that allows storage of data to memory, they’re not the same so they can’t be compared so black and white me thinks. In fact surely they idea is not that idiotic , i.e if a visitor has no login session cookie then nginx will serve the page cache from Varnish, and then additionally even with the session cookie you can serve content generated from memcache but stored in varnish all offloading work from nginx and most likely reducing cpu usage and internal network bandwidth. Its highly configurable and you shouldn't treat is a dumb cache.
But its a bit hard to make a sweeping statement without knowing the internal bottlenecks generated by the attack.
just another 2 cents to the original 2 cents. or should i say 0.02 btc.
April 18, 2011, 04:51:28 PM
Attacker flooding the server had IP 69.72.189.147
http://www.dnsstuff.com/tools/whois/?ip=69.72.189.147&j=1&email=onhttp://www.dnsstuff.com/tools/ipall/?tool_id=67&token=&toolhandler_redirect=0&ip=69.72.189.147
http://www.fortressitx.com/index.php?tpl=contact
http://www.web-hosting-top.com/companies/fortressitx.com
It may help...........
April 18, 2011, 04:30:03 PM
Attacker flooding the server had IP 69.72.189.147
April 18, 2011, 03:47:12 PM
tl; dr; but if you are considering changing technology be sure to check redis. I love memcache but I wouldn't like my shares to stay just in memory.
huh? Nobody has suggested that.
The normal pattern is for database writes to do as the name implies -- write to the database (and memcached). Database reads are served from memcached. That means the database is used almost exclusively for storing data. This is known as write-through caching.
Quote from: colossus
Excellent but why don't you also split your site into to 2 parts, use varnish to cache the mundane stuff for a much longer period and set the more realtime stuff to have a shorter ttl
April 18, 2011, 03:35:37 PM
tl; dr; but if you are considering changing technology be sure to check redis. I love memcache but I wouldn't like my shares to stay just in memory.
April 18, 2011, 01:55:48 PM
Including real time stats like last submit time?
If they are in a database... yes. memcached is fantastic for stats. It even has special protocol command such as 'incr' that might be used.
Many large mysql installations wind up using memcached as the primary for all read operations.
Excellent but why don't you also split your site into to 2 parts, use varnish to cache the mundane stuff for a much longer period and set the more realtime stuff to have a shorter ttl, although i'm a bit of an f5'er myself i'd be willing to wait a defined period for my status to be updated.
I've seen varnish work wonders with very high traffic sites much more so than nginx, and i mean high traffic. Those DoS loosers would have to work much harder to bring you down with varnish as a shield.
April 18, 2011, 01:50:05 PM
A bit more relaxed?
How about a TON more relaxed!
Personally, I rely on slush's great work and the feedback I get there.
Seeing my miner(s) churning away early this AM when I left the house is little consolation throughout the day...!
I'll be very happy (as I'm sure slush and we all will be) when the site id back up.
I sure hope the fargin bastiches (*) that did this are caught! (anybody else see 'Johnny Dangerously' - LOL).
Thanks to slush, all the best to all of us, and have a good day, in spite of it all!
-digdug
I missed something. Where did anybody say that somebody "did something" to cause the site outage? Yesterday, slush indicated it was because bitcoind hung up (seems like that code needs some refinement I suspect).
Slush's website is being actively hit with a Denial of Service attack that is/was taking 40Mbps of bandwidth.
April 18, 2011, 01:19:40 PM
A bit more relaxed?
How about a TON more relaxed!
Personally, I rely on slush's great work and the feedback I get there.
Seeing my miner(s) churning away early this AM when I left the house is little consolation throughout the day...!
I'll be very happy (as I'm sure slush and we all will be) when the site id back up.
I sure hope the fargin bastiches (*) that did this are caught! (anybody else see 'Johnny Dangerously' - LOL).
Thanks to slush, all the best to all of us, and have a good day, in spite of it all!
-digdug
I missed something. Where did anybody say that somebody "did something" to cause the site outage? Yesterday, slush indicated it was because bitcoind hung up (seems like that code needs some refinement I suspect).
April 18, 2011, 01:12:22 PM
Just FYI, I got a payment just now. So that at least demonstrates that unconfirmed rewards are getting properly confirmed after the requisite number of blocks. I see no reason to switch to another pool at the moment.
Jump to: