[~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More

[m3ta]

Stats issue for US West miners fixed (new load balancer = new port/address for the website to communicate with the scripts on US West).  Miner speed estimates for US West will take 15 minutes to correct.  You didn't suddenly stop mining, I just wiped the temporary table used to calculate your speeds.

Is that the cause of this?

Code:

2316
	140695	2011-08-12 17:36:33	4:13:57	356984	89 until confirmed	None	None	None

Because I was looking at the up and downs during this block, workers sometimes connected for some minutes, submitted shares, so I surely should have more than "None" earned.

So, data loss happened?

The block you linked is the one when the servers were going up/down.  The DDoS caused the servers to de-sync so one server was still working on an old round.  Not that many people could access the servers at all during the DDoS.

Ok. Thanks for the info.

[m3ta]

So what is the time frame when mining data was lost?
Just so people know to expect loss if they mined shares during that time frame ...

The one referred in the post immediately above your question. You know, the one that proves you didn't even try to find an answer before asking.

[eleuthria]

Still some residual attacks going on, been working with the ISP to continue filtering out bad traffic.  Just added a large blacklist to the perimeter of the ISP's network which should help.

[Xephan]

not only is the botnet owner an asshat, he's also retarded. not smart enough to setup his own pool.

It's probably because he's a botnet owner that's why he doesn't want to setup his own pool
It would make too obvious a target for the authorities looking for him

[kano]

So what is the time frame when mining data was lost?
Just so people know to expect loss if they mined shares during that time frame ...

The one referred in the post immediately above your question. You know, the one that proves you didn't even try to find an answer before asking.

Well that block was from 2011-08-12 13:22:36 to 2011-08-12 17:36:33
So anything mined outside that time range you guarantee was not affected?
And anything mined during those 4h 13m 57s could be lost?
Or was it a smaller time range? Or did it actually affect any before or after?

Yeah I sorta thought someone from the guild would clearly state the time range without even being asked ... rather than ignore the question asked.
Seems a pretty important answer to clearly let people know ...

[eleuthria]

The effects of the DDoS should have been limited to Rounds 2315, 2316, and 2317.  Most miners were unable to communicate with the server between 2315 and 2316, meaning they could not submit shares.  One server was stuck on 2316 for about 15 minutes while the other was on 2317 as the DDoS was dying down and the servers were able to come back up.  So the people on that server had more shares counted during 2316, and fewer on 2317.

Outside of those rounds, no data has been lost, though the servers have still had some residual attacks hitting it, which caused higher levels of idles and stales.  These issues have since gone away, and thanks to the attack I was able to implement the better load balancer on US West while the servers recovered.  For the last few hours, the servers have been functioning better than ever.

[kano]

Thanks - that's what I wanted to know.

[PcChip]

in between refreshes of my workers:

24 Hour Luck      4,353,849

[Kermee]

in between refreshes of my workers:

24 Hour Luck      4,353,849

Yeah... Looks better now though!



Cheers,
Kermee

[mc_lovin]

I liked the % +/- luck indicator better IMHO.

[brandon@sourcewerks]

Is the site being DDOS'ed again?  I cant connect to API or the website.

[useful_idiot]

Is the site being DDOS'ed again?  I cant connect to API or the website.

Same here, I havent been able to access the website since about Thursday last week. Miners seem OK though...

[eleuthria]

Are you forgetting to put www. on the URL?  The DDoS only took us down for a few hours.  Site and API have been working fine ever since.

[useful_idiot]

well wash my arm, i feel stupid.

By the way, thanks for all your efforts on running such an awesome pool.

[Coolhwip]

Is there any way to know for certain if a block will become invalid before it gets confirmed? Does the pool keep internal time down to the millisecond? Maybe that would settle it. I ask because block 141008 was found by both us and simplecoin:

[jjiimm_64]

Is there any way to know for certain if a block will become invalid before it gets confirmed? Does the pool keep internal time down to the millisecond? Maybe that would settle it. I ask because block 141008 was found by both us and simplecoin:

I'm still new to this stuff, but let me take a stab at this.

the bitcoin client, or bitcoind  will declare which block is valid.  Since the bitcoin software is open source, I suppose it is possible to go into the source code, figure out which block would be valid. ( I believe it is strictly timestamp, not sure here) and do the same thing that the bitcoin client would do.


::hoping a bitcoin guru will chime in here.

[[Tycho]]

Is there any way to know for certain if a block will become invalid before it gets confirmed? Does the pool keep internal time down to the millisecond? Maybe that would settle it. I ask because block 141008 was found by both us and simplecoin:

Reporting blocks by numbers is a bit wrong because you can't be sure what number it will take.
Correct way is to report blocks by it's hashes. It's unique and will allways be correct, so you'll see if it's valid or not.

[gentakin]

The simplecoin frontend is known for getting block numbers wrong. Ask BurningToad from ArsBitcoin, he uses that frontend (probably heavily modified) as well and tried to fix these problems. Sometimes the simplecoin frontend also misses a found block when two blocks are found within a certain time frame.

[kjj]

If two blocks are found at nearly the same time, and both of them end up on the network, each will be correct on a fraction of the network.  That means that part of the network will be working on the next block following one of them, and the rest of the network will be working on extending the other.  If there is a clear winner when the next block is found by one side, the race is over in favor.  Or, if the next round is another tie, the network remains split and goes on to the next round.

Because finding blocks is somewhat random, if the initial split isn't perfectly even, one side or the other will have a considerable advantage, and that advantage will grow quickly.  I don't think that any splits caused by honest block races have gone past a third round.

[Coolhwip]

Very interesting. Thanks for the explanations everyone.