Topic: [~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More - page 52. (Read 379087 times)

That won't solve the "problem" because they will use the LP feature of the pool!

If the pool hoopers know when the rounds start in real time, they hurt the rest of the users. If they dont, then pool hooping becomes random and they can not profit and do not hurt others.

Pool hooping is only profitable if they know when the round is starting. So yes, delay the stats 1 hour (or whatever) and pool hooping problem is gone.

The point isn't that pool hopping isn't more money.  It is.  Putting your shares into pools with the shortest round is going to make you more money.

But my point is that in terms of BTC/minute, your payouts from BTC Guild are the same no matter what pool hoppers are doing:  Staying in the pool the whole time, jumping to another pool, or not being in the pool at all.

Technically, pool hopping does hurt the pool because long rounds take even longer than they should, so a higher percentage of your pool's time is functioning at a low BTC/minute from bad luck rounds.

However, this argument is only valid IF the pool hoppers were going to stay on the pool in the first place.  My argument is that nobody that has the setup to pool hop would bother being on the pool in the first place if we had a stat delay/score system.  There are many other proportional/real-time pools out there to hop on.  As such, pool hoppers not being on the pool at all will actually mean the long rounds do last slightly longer than if the pool hoppers were on them for the first couple of minutes.

sharky.. i forgot about the API/JSON stuff. "miner software" is just a sh/perl script in linux. trivial to write
if you want to and put your mind to it. the logic of when to switch around is the interesting part. not the
gathering of info from pool hopping friendly pools.

now we just need a pool hopping person to chime in with a test they did showing some proof.
that 600 mh/s left on btcguild for example earned this much. while another pool hopping 600 mh/s
earned this much over the same time period. And not just a few days.. but many days. accounting
for any downtime, pool outages, and whatever else can possibly ruin a test.

bah.. silly me. i forgot about the APIs. Very easy to gather info every second or what not.
that is the key ingredient to make pool hopping software easy to script in a linux shell compared
to screen scraping or miner with long polling.

all signs are pointing to pool hopping being more profitable but just how much more is unknown to me
on average over a week/month time frame.

Why would a hour delay really bother people? It doesn't seem like a big deal to me.

According to the other thread they do not have to scrape the screen. They have miner software that does all the data gathering for them and it switches them automatically.

Eleuthria, I agree also that the formula should not be modified for calculating payouts. But I do think that delaying stats by one hour would work just fine. Seems to work for Deepbit with over 4 Thash/s (as in it's not affecting their pool size at all by keeping the hoppers at bay).

Its easy to read the JSON. But yes, I dont know if they do it, as I said Im not a hooper. In this sense its probably easier for the hoopers to operate in smaller pools so the probability of a very short round is a lot lower.

i posted this above but relevant here after your last post.

"also... btcguild just had a very short round.. 1:15 seconds.. a pool hopper better be scraping
the screen at btcguild quite a bit to get in on those.. i am not clear how else they would know
a block is being solved by all these places otherwise... if they scrape every 30 seconds they just
lost out on a significant chance to make some BTC... regulars did quite well though."

so are people scraping btcguild's website every 2 seconds to make sure they can get in on these
super short ones?

otherwise you would need a miner connected to btcguild via long polling to get a message saying
time to work on a new block.. i think...

Hoopers, at least inteligent hoopers, only jump to pools that just started a round, and then leave to join another pool that just started their round. Im sure there will be better optimizations, I am not a pool hooper so I dont know them. But the key is that you know when a round starts, but not when a round ends, so by being at the beggining of each round in different pools you increase the probability of getting the more profitable shares while avoiding part of the less profitable shares.

They key is that you know when a round starts but not when it ends.

But pool hoopers get a bigger number of more profitable shares, while leaving the less profitable shares to the "legal" miners that have to assume its costs alone.

this is the assumption or ?fact? that makes pool hopping more profitable. i get it.
no need for me to debate it...

but does not luck play a role in all this? that a pool hopper could leave a long round
only to join another pool in a long round... only to hop again to another long round...
and eventually run out of pools.. with all that work stuck in long rounds loosing value
as they finally sit in a PPS pool.

now the flip side is that they could leave a long round and get a couple lucky short
ones in.. but that is not guaranteed.. and often short rounds are routinely discovered
by only the largest pools.. so you will run out pools to hop into quickly since some try
to defeat pool hopping...
so now you go to PPS pool and sit there until a round is solved... and start over again.

how does luck play into all this for a pool hopper. sometimes they get some short in..
sometimes they sit in a PPS... how does it even out over time.. how big of an advantage?
i heard 28% being spoken about.

just thinking out loud. no need to respond back if you do not feel like it.


also... btcguild just had a very short round.. 1:15 seconds.. a pool hopper better be scraping
the screen at btcguild quite a bit to get in on those.. i am not clear how else they would know
a block is being solved by all these places otherwise... if they scrape every 30 seconds they just
lost out on a significant chance to make some BTC... regulars did quite well though.

First, the "legal" user does not benefit from having the hoopers in the short runs or in the beggining of the long rounds. Yes, it will make the pool discover rounds quicker, but then the bitcoins have to be divided among more people, so there is no increase in profit from having the hoopers for the "legal" miner. Maybe the only advantage is a reduction on variance, but only maybe because they leave in the long rounds making them longer (Im not really sure about the net result on variance but its irrelevant, the point is that it does not increase the profits for the "legal" miner to have the hoopers).

Then, the shares in the quick rounds are more profitable than the shares in the long rounds. Ideally everybody would want to have luck and get quick rounds. But we know that over time things even out, so "legal" miners assume that they will get an even number of more profitable shares and less profitable shares. But pool hoopers get a bigger number of more profitable shares, while leaving the less profitable shares to the "legal" miners that have to assume its costs alone.

Is that clearer?

EDIT: Its easy to prove that hoopers are taking bitcoins from "legal" miners in other way: Since bitcoins are created at a predictable rate (lets ignore difficulty changes for this), and hoopers make more bitcoins by changing pools (and this can be demostrated easily), it means that there are less bitcoins for the rest. This is because the "legal" miners work more on the less profitable shares (the ones from the long rounds) than the hoopers.

but once the hopper leaves.. their payout slowly decreases on this btcguild long block... and if they jump to a pool and get caught up
in another long block.. their payout will be small there too. what was lost at BTCguild needs to be made up for at the other pool. seems there is a bit of luck involved in all this...
the maths is tricky.

i am not saying pool hopping cannot make you more.. but i am not clear on just how much more.. and luck
can go both ways.

Please point out why another pool's payouts during that time affect the normal BTC Guild user.  You quoted one of three scenarios.  In the end, the non hoppers make the same BTC/minute whether the hoppers were involved for all of the round, part of the round, or none of the round.

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

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...)

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.

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.

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.

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".