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

[pickle]

Yeah there's definitely something wrong, I'm mining at about 50% capacity on US West.

Unfortunately I can't provide diagnostic information as I'm not anywhere near the miners at the moment.

[eleuthria]

Yeah there's definitely something wrong, I'm mining at about 50% capacity on US West.

Unfortunately I can't provide diagnostic information as I'm not anywhere near the miners at the moment.

The problem is somewhere in the ISP's network based on traceroute information.  The traceroute dies before it even reaches the server.  It is possible that US West has enough IPs pointed at it that the long poll is causing enough packets to flood in/out in a very short timespan and its tripping the DDoS filtering.  Or it could simply be an unrelated hardware issue at the ISP that needs fixing.  Will know more once I get a response.

I know for the miners out there it sucks to see these dips of efficiency due to idles (luckily not too long), but the good news is that this time the problem is not in server hardware or software configuration.  If this is an accidental trigger of the DDoS filters,  it may be as simple as the ISP whitelisting our IP from the DDoS filters unless we ask for it to be turned on.

[pickle]

Yeah there's definitely something wrong, I'm mining at about 50% capacity on US West.

Unfortunately I can't provide diagnostic information as I'm not anywhere near the miners at the moment.

Looks like the miners are back at 100% capacity now. I will update if I see any more changes. Thanks.

[fcmatt]

we need this almost 3 hour block solved! someone turn the knob to 11!

[Tx2000]

we need this almost 3 hour block solved! someone turn the knob to 11!

I have my turned to 99 

[eleuthria]

I've been pressing my button to toggle the luck switch but I swear it's not working.  I guess those guys didn't install the switch properly!  I'll have to drive there myself to flip it >_<

[wolftaur]

I've been pressing my button to toggle the luck switch but I swear it's not working.  I guess those guys didn't install the switch properly!  I'll have to drive there myself to flip it >_<

They just inverted it to mess with all of our heads!

[fcmatt]

I've been pressing my button to toggle the luck switch but I swear it's not working.  I guess those guys didn't install the switch properly!  I'll have to drive there myself to flip it >_<

that was brutal.. glad it is over.

and then the pool scores a couple minute block to cut that 4 hour in half to a 2 hour :-)

[nixpins]

I've been pressing my button to toggle the luck switch but I swear it's not working.  I guess those guys didn't install the switch properly!  I'll have to drive there myself to flip it >_<

I think I've found the problem.

https://i.imgur.com/neYaa.jpg

[eleuthria]

How did you get into my house to find my miner control switch!

Update on the idles earlier today:  Host has modified the DDoS filtering to allow a higher packet flow before it trips on our mining server's IP.  The problem seems to have stemmed from when all 4 pools triggered a long poll within 1-2 seconds (remember that bitcoind = p2p network, and has to write to disk when a new block is found, causing minor variations in each bitcoind knowing the block chain has moved).

When all 4 subservers triggered the LP within about 1 second of each other, it launched out the new information to all miners at once.  The server is averaging about 3.5k workers right now.  Some workers are actually 2-10 miner instances, some have even more for the people who setup computers at their office to mine while idle.  Each one has its own long poll connection, and its own work queue.  The LP pushes the new work to everybody, and people re-established connections.  Many miners will request at least one additional piece of work at the same time.  This is on top of the usual getwork/share submission traffic.

The end result was a rare chance of the server triggering the DDoS filter which adapts to the traffic flooding in.  Those who were around for the old US West know that this can get much worse with how frequently miners try to reconnect when a connection is rejected.  This is why some people were still mining happily and others were disconnected.  The DDoS filter knew certain connections were "good" because they weren't spamming for connections.  The people that got disconnected however were repeatedly hitting the server, and the filter was keeping them locked out during the "attack".

[phelix]

quote from the bithopper pool hopping tool thread:

Well in terms of revenue it should mathematically be 28% more if you are hopping all the time. Earlier someone said they got ~20% more. At the worst case you'll get the same revenue you'd get normally and be stuck mining at eligius all day.

Stats are slowly in the process of going up. There is a stat dump file which records shares, difficulty, and server.

I originally wanted the stats to be integrated into the server but I might just write a program which allows you to enter you rewards from each server and calculates its efficiency.

EDIT: I did some quick calculations on btcguild and I have 9362 shares. I expected to get 0.299 btc for those shares. I got 0.384 for those shares. So I got about 28% more that I should have. Which is actually pretty amazing.

[sharky112065]

quote from the bithopper pool hopping tool thread:

Well in terms of revenue it should mathematically be 28% more if you are hopping all the time. Earlier someone said they got ~20% more. At the worst case you'll get the same revenue you'd get normally and be stuck mining at eligius all day.

Stats are slowly in the process of going up. There is a stat dump file which records shares, difficulty, and server.

I originally wanted the stats to be integrated into the server but I might just write a program which allows you to enter you rewards from each server and calculates its efficiency.

EDIT: I did some quick calculations on btcguild and I have 9362 shares. I expected to get 0.299 btc for those shares. I got 0.384 for those shares. So I got about 28% more that I should have. Which is actually pretty amazing.

Damn. Just when I was about to bring my workers/miners back to BTC Guild I see this. I will wait until something is done to prevent pool hopping on BTC Guild. Basically they are stealing from other miners by doing this, IMO.

Delayed stats needs to be implemented.

[Peao]

Delayed stats needs to be implemented.

+1

[phelix]

quote from the bithopper pool hopping tool thread:

Well in terms of revenue it should mathematically be 28% more if you are hopping all the time. Earlier someone said they got ~20% more. At the worst case you'll get the same revenue you'd get normally and be stuck mining at eligius all day.

Stats are slowly in the process of going up. There is a stat dump file which records shares, difficulty, and server.

I originally wanted the stats to be integrated into the server but I might just write a program which allows you to enter you rewards from each server and calculates its efficiency.

EDIT: I did some quick calculations on btcguild and I have 9362 shares. I expected to get 0.299 btc for those shares. I got 0.384 for those shares. So I got about 28% more that I should have. Which is actually pretty amazing.

Damn. Just when I was about to bring my workers/miners back to BTC Guild I see this. I will wait until something is done to prevent pool hopping on BTC Guild. Basically they are stealing from other miners by doing this, IMO.

Delayed stats needs to be implemented.

projects like bithopper are very valuable because they bring bad stuff that others have been doing for a long time to the surface.

those that hop earn more, the others earn less - yep, stealing is an adequate term. Still I consider it the pool operators' duty to prevent it.

[fcmatt]

i am not so sure that pool hopping is a really big issue for me as a miner personally.

take a look at quick/short block solve time stats...

sometimes i get more then average.. sometimes i get less. but it tends to even
out over time to the median value i normally get for longer blocks (which in general get
me more then short blocks overall).
It is all about luck to me for these short blocks if I squeeze in enough shares in such a short time...
also one has to consider how much pool power is in play at each time to get accurate
numbers.

solve time  shares      my shares    payout
0:02:53       90744   113   0.06226306
0:02:18       67598   67   0.04955767
0:02:54       91315   96   0.05256529

one was lower... one was higher.. .0525 is a touch under my average of .055 at a approx pool speed of ~2100 gh/s.

the average was (.06226306 + .04955767 + .05256529) / 3 = 0.05479534

my estimated rewards on this current 37 minute long block being solved is 0.05364367
so i did pretty well on those short blocks.

Now on longer blocks my payout is generally higher then short blocks! Almost everyone
I look at.. longer blocks that is.. i get more then short blocks almost every single time
in the stats i am briefly looking at right now as i type this.

now i am not saying pool hopping does not work if implemented correctly.
i am not saying if we delay stats by several/some minutes it will not help.

but i am just not seeing a big difference in payout from short blocks averaged out compared
to longer blocks.

EDIT: I did some quick calculations on btcguild and I have 9362 shares. I expected to get 0.299 btc for those shares. I got 0.384 for those shares. So I got about 28% more that I should have. Which is actually pretty amazing.

now how is a person suppose to draw any real conclusion from that data without knowing their
hashing speed, time of blocks that were solved, the amount of pool power during that time on average,
etc... I just randomly grabbed some blocks.. some short.. some longer.. and my average payout per
share was more then that persons... Now if i toss in some of the huge block solve times i would be
less then their average. it just depends on the sample time frame. hopping away from a 2-4 hour
block obviously has advantages but i am unclear if it is worth my time and effort. I am not hashing
with 50 gh/s here...

so am i going to get stressed out over 2-10 cents of loss per block? really? i have other things
to worry about and i can make more picking up change at the drive through on the way to work
getting my 2 dollar ice coffee in the morning :-P

i have not double checked my math and could have made some mistakes.
i have read pool hopping threads and some people claim it works while others do not seem
to have the same "luck".

[eleuthria]

Here's a theoretical scenario.  I'm using simple math, just to make it easy to follow:

This scenario assumes the following:
  10% of the pool is hopping
  The total pool speed WITH the hoppers is 100k shares per minute. (So 10k/minute from hoppers, 90k/minute for "legit users")
  The hoppers are swapping at 1 million shares (AKA: 10 minutes/100k shares)
  The hoppers are efficient enough to join rounds/leave rounds at the exact start of a new round/1m share mark on a long round.

Scenario 1)
We solve our first block at 500k shares.  Pool hoppers get 5 BTC (10%), rest of the pool gets 45 BTC.  So pool hoppers get 1 BTC/minute, rest of the pool gets 9 BTC/minute.

We then have a long block, 3 million shares.  The pool hoppers contributed 100k, or 3.3%.  Hoppers get 1.66 BTC, the rest of the pool received 48.34.  Because the last 2 million shares were running at 90% normal speed, it took 22.22 minutes to finish the block after they left, or 32.22 minutes total. The pool hoppers got 0.166 BTC/minute (10 minutes of work).  The rest of the pool got 1.50 BTC/minute (32.22 minutes of work).  What the pool hoppers earned on other pools during the other 22.22 minutes is irrelevant to BTC Guild's users payouts.


Scenario 2)
Now lets say I implement a system that makes it impossible to hop.  For example a 24 hour stat delay, meaning they could NEVER know if we were having long rounds (unless we were so unlucky it lasted 24+ hours).  There are plenty of pools out there to hop on.  If a pool hopper is looking for max rewards, they simply WONT USE our pool.  As I stated in the IRC chat:  "Hoppers gonna hop.  If they can minimize the effect of bad luck, they will ignore a pool that doesn't allow them that opportunity."


So in the 500k share block, we take 5.55 minutes to complete the block, giving the normal users 9 BTC/minute for their time.
In the 3m share block, we take 33.33 minutes to complete, giving normal users 1.50 BTC/minute for their time.


Scenario 3)
Pool hoppers say:  "I guess I can't hop, I'll just STAY in BTC Guild".  That 3 million round then takes 30 minutes.  Pool hoppers contributed 10% and got 5 BTC, the rest of the pool got 45 BTC.  In this case, hoppers made 1.666/minute on the 3 mil round, and non hoppers made 1.5 BTC/minute, exactly the same as before.


As you can see, the NON hopping users will make the same BTC/minute:  
  Scenario 1 vs 2 - 500k block) Hoppers in a pool for a whole a round vs not in the pool at all.  Non hoppers make 9 BTC/minute either way for that round.
  Scenario 1 vs 2 - 3 mil block) Hoppers in the pool for part of a round vs not in a pool at all.  Non hoppers make 1.5 BTC/minute either way for that round.
  Scenario 1 vs 3 - 3 mil block) Hoppers in the pool for a whole round vs only part of a round.  Non hoppers make 1.5 BTC/minute either way for that round.


In the end, the worst case scenario is that pool hopping makes a bad round take longer to complete.  However, a pool hopper would not be participating at all if the pool does not have the ability to be hopped into/out of.  In which case, NOT having the pool hoppers will make that round take even longer than it would with the hoppers.

[eleuthria]

I'm listening for arguments/flaws in my scenarios above.  If I can get concrete proof that pool hopping actually -hurts- the pool payouts for non hoppers, I will introduce a stat delay (I refuse to implement any score based/SMPPS system, they are not user friendly).

As far as I can see, the effect of pool hopping is it increases the duration of long rounds.  But as I pointed out above, the duration of long rounds is still shorter -thanks- to the pool hoppers being there for a portion of the round.  If the pool were not hopper friendly, the unlucky round would have been even longer because the hoppers would simply ignore the pool and go somewhere that they can hop without penalty.

[hugolp]

Here's a theoretical scenario.  I'm using simple math, just to make it easy to follow:

This scenario assumes the following:
  10% of the pool is hopping
  The total pool speed WITH the hoppers is 100k shares per minute. (So 10k/minute from hoppers, 90k/minute for "legit users")
  The hoppers are swapping at 1 million shares (AKA: 10 minutes/100k shares)
  The hoppers are efficient enough to join rounds/leave rounds at the exact start of a new round/1m share mark on a long round.

Scenario 1)
We solve our first block at 500k shares.  Pool hoppers get 5 BTC (10%), rest of the pool gets 45 BTC.  So pool hoppers get 1 BTC/minute, rest of the pool gets 9 BTC/minute.

We then have a long block, 3 million shares.  The pool hoppers contributed 100k, or 3.3%.  Hoppers get 1.66 BTC, the rest of the pool received 48.34.  Because the last 2 million shares were running at 90% normal speed, it took 22.22 minutes to finish the block after they left, or 32.22 minutes total. The pool hoppers got 0.166 BTC/minute (10 minutes of work).  The rest of the pool got 1.50 BTC/minute (32.22 minutes of work).  What the pool hoppers earned on other pools during the other 22.22 minutes is irrelevant to BTC Guild's users payouts.

But this is not true.

Because the "legal" miner gets to colaborate more in the long rounds, the ones that are less profitable, while the pool hoppers jump to a new one and stop collaborating. In the more profitable rounds, the pool hoopers get their complete share.

Supposedly you are collaborating in the long rounds because it gets compensated in the short rounds and with time its even. But if some of the miners only collaborate fully in the short runs and only a part collaborate in the long rounds, the less profitables, there is a problem where some are benefiting at the expense of others.

[fcmatt]

well we just solved that long 2+ hour block and the pool speed was reported as approx 2257
in a window i had open but now is closed. it is a pretty good estimate to work with.

well we are now a few minutes into a new block..

2:44 into it. pool speed is 2213... (went down from when block was solved???)
7:39 into it. pool speed is 2255... (back to where we were. long poll delay and people caught back up???)
8:23 into it. pool speed is 2263...
9:25 into it. pool speed is 2272...
11:14 into it. pool speed is 2285...
13:52 into it. pool speed is 2302...
15:44 into it. pool speed is 2321...
17:00 into it. pool speed is 2341... (almost 100 gh/s more then when long block was solved.)
18:04 into it. pool speed is 2333... (now it went down. 527922 shares submitted. block diff is 1563027)
19:20 into it. pool speed is 2324... (sloping down but i thought pool hopping magic was 40% diff?)
20:13 into it. pool speed is 2319...


and i looked away and the block was finished...

3:07 into new block. pool speed is 2289...
4:11 into new block. pool speed is 2291...
5:23 into new block. pool speed is 2291...
5:57 into new block. pool speed is 2280... (going down.. yet we just started a new block..)
8:05 into new block. pool speed is 2278...
13:36 into new block. pool speed is 2298...
15:54 into new block. pool speed is 2311... (back up now...)

[flower1024]

you convinced me!

but: 10% of TH are 200GHash.

if they where hopping around... just imagine

at the moment i think they are approx 50GHash hopping through your and other (smaller) pools (estimations just from watching pool stats, no math behind that number)

i like it very much that you don't want to switch another system. prop-payouts are for me a warm feeling