Send me a donation and this round will end
Oh please...........
|
|
|
Did someone just add 100TH to BTCG? ...........
|
|
|
I kept searching for an ignore button on Reddit
|
|
|
(.......) How the attack was done
I believe that this is how the attack was done: After the 2011 hack of the forum, the attacker inserted some backdoors. These were removed by Mark Karpelles in his post-hack code audit, but a short time later, the attacker used the password hashes he obtained from the database in order to take control of an admin account and insert the backdoors back in. (.......)
Anyone care to summarize the 2011 annoyance. Was that the Bill Cosby incident?
|
|
|
......... Once you have started mining successfully, you should not have instability, and that is well reflected by the pool speed over the last few days..........
umm, I assumed the attacking morons gave up......... BTC Guild is awesome, but we already knew that.
|
|
|
Anyone else experiencing huge lags accessing unit via browser? I switched the Ethernet cable around and I'm sure my router works fine. I'm r38031. PING 192.168.0.100 (192.168.0.100) 56(84) bytes of data. 64 bytes from 192.168.0.100: icmp_req=1 ttl=63 time=9.14 ms 64 bytes from 192.168.0.100: icmp_req=2 ttl=63 time=2.09 ms 64 bytes from 192.168.0.100: icmp_req=3 ttl=63 time=2.66 ms 64 bytes from 192.168.0.100: icmp_req=4 ttl=63 time=4.32 ms 64 bytes from 192.168.0.100: icmp_req=5 ttl=63 time=2.60 ms 64 bytes from 192.168.0.100: icmp_req=6 ttl=63 time=2.71 ms 64 bytes from 192.168.0.100: icmp_req=7 ttl=63 time=3.92 ms 64 bytes from 192.168.0.100: icmp_req=8 ttl=63 time=2.66 ms 64 bytes from 192.168.0.100: icmp_req=9 ttl=63 time=2.13 ms 64 bytes from 192.168.0.100: icmp_req=10 ttl=63 time=2.69 ms 64 bytes from 192.168.0.100: icmp_req=11 ttl=63 time=2.72 ms 64 bytes from 192.168.0.100: icmp_req=12 ttl=63 time=2.61 ms 64 bytes from 192.168.0.100: icmp_req=13 ttl=63 time=24.4 ms 64 bytes from 192.168.0.100: icmp_req=14 ttl=63 time=2.68 ms 64 bytes from 192.168.0.100: icmp_req=15 ttl=63 time=2.49 ms 64 bytes from 192.168.0.100: icmp_req=16 ttl=63 time=2.37 ms 64 bytes from 192.168.0.100: icmp_req=17 ttl=63 time=2.72 ms 64 bytes from 192.168.0.100: icmp_req=18 ttl=63 time=2.72 ms 64 bytes from 192.168.0.100: icmp_req=19 ttl=63 time=6.63 ms 64 bytes from 192.168.0.100: icmp_req=20 ttl=63 time=2.72 ms 64 bytes from 192.168.0.100: icmp_req=21 ttl=63 time=4.69 ms
|
|
|
well I got 4 fail overs now. have you been able to figure out where this is coming from?
Who stands to gain from this disruption? Follow the money? Yea. Looks like a classic block grab.
|
|
|
well I got 4 fail overs now. have you been able to figure out where this is coming from?
Who stands to gain from this disruption?
|
|
|
.............. What's that button for...........
That's the button you click to change the pool luck. You didn't press it did you?!?!?!
|
|
|
.............. What's that button for...........
|
|
|
Do the world a favor Tim Worstall, quit.
|
|
|
Yeah, I have around 30GH at the moment, with another 19GH on it's way/ordered. It'll keep the house warm over winter if nothing else. That's about all they're good for ATM. Your place is warm even when you're not there as opposed to coming home to turn on the heater then wait.
|
|
|
For whatever reason I read that entire Forbes nonsense......... Short answer, Time Management. All they’re going to do is buy a pile of Bitcoins and then sit on them until they’re worth more. And that’s something that you can do just as well as they can: thus it makes no sense at all to be paying them fees for doing it.
|
|
|
You know you're a server admin when...
FTFY ....never sleeps
|
|
|
How is that even possible? With that much Gh, Slush shouldn't go more than 3 hr without a block..............btw, has anyone check the orphan rate That is absolutely not true.It is within the realm of possibility for Slush to go a week without finding a block. Not very likely, but possible. It is also possible for Slush to find a block within seconds. Also not very likely, but it does happen from time to time. First off, this is the Slush we're talking about here. Nuff said. "realm of possibility" doesn't apply to Slush. Other than that, I suspect high orphan rate to be the cause. Can anyone confirm recent orphan ratio?
|
|
|
Accessing ava via browser now takes longer. What may be the issue?
define longer. Does it take a while to start loading? If you ping the machine, do you see high latency or dropped packets? You might just suffer from a DNS issue (timeouts before load) .....longer to load any page after login. Everything seems to work fine now. I'd recently update firmware to 20130923 and changed default Chip Frequency (on Cgminer Configuration Page) to 300. I lower the Frequency to 285. Unit access via browser interface now load as it should. A fresh firmware update had the Chip Frequency at somewhere below 300 (don't remember exactly), so because "Default: 300" is stated right there on the Cgminer Configuration page, and the previous firmware was at 300 CF, naturally, anything < 300 was unacceptable.
|
|
|
How is that even possible? With that much Gh, Slush shouldn't go more than 3 hr without a block..............btw, has anyone check the orphan rate
|
|
|
Have you experience any delays while accessing unit via browser interface?
|
|
|
Accessing ava via browser now takes longer. What may be the issue?
|
|
|
Later this week the public stratum servers for BTC Guild will be extended from 3 US servers to 5 US servers in order to give a better balance of the load, and extra redundancy in the event of an attack. That upgrade will be completely transparent and users will not experience even a brief moment of downtime when the new servers are added.
This is what I like about BTC Guild, it's an absolutely professional service on every level. Thanks very much eleuthria, excellent work. Yep. eleuthria always answer my moronic questions. Very surprising for someone running a pool this long. As for that other pool with eternal blocks and an admin with unicornic characteristics.........
|
|
|
|