Solo Mining

[PatrickHarnett]

I'm obviously not going to sway your opinion and I've done this argument elsewhere.  Of interest, I did find one of ideas behind hop-proofing actually makes hopping more attractive.  Those pay on last N share pools encourage people to jump in once N has been reached.

Still, if I do one share in a solved block that took a million shares, I simply can not know if people have jumped in early, late, 24/7'd or turned off or on, I get 1/1000000 of the reward.  (btw - I think I have about 100 mined coins over three months and 2.7 million shares.)

[Meni Rosenfeld]

Of interest, I did find one of ideas behind hop-proofing actually makes hopping more attractive.  Those pay on last N share pools encourage people to jump in once N has been reached.

If you're talking about PPLNS then no. It pays shares from previous rounds so it doesn't matter at all how many shares are in the current round.

Still, if I do one share in a solved block that took a million shares, I simply can not know if people have jumped in early, late, 24/7'd or turned off or on, I get 1/1000000 of the reward.  (btw - I think I have about 100 mined coins over three months and 2.7 million shares.)

But more of your shares will be in longer rounds than should be. For example, if you are 1% of the pool and the pool has a round with 1000000 shares and a round with 3000000 shares, you'd want to have 10000 shares in the first and 30000 shares in the second. But in reality it will be more like 5000 shares in the first and 35000 shares in the second, because the hoppers quit early on the long round. So your total payment will be 50*5000/1000000 + 50*35000/3000000 = 0.83 BTC instead of 2*50*1% = 1 BTC.

[PatrickHarnett]

So, using your example, I do 5000 blocks for 0.25 BTC reward in round one and 35000 blocks for 0.583BTC in round two.  Neither of these has 1% of pool power.  In the first it is 0.5% and the second 1.166%.

40,000 blocks out of 4,000,000 would be 1%, but that ignores the simple fact that sum(Xi * Yi) <> avg(Xi) * avg(Yi)  Given the 1% is not constant, you can't really use that to underpin the argument.  If you could maintain 1%, then you would achieve the theoretical 1 BTC payment, irrespective of hoppers.

Might also be worth while to point out that pool size has something to do with the equation as well, as if 95% of the pool disappears gives a different result to a 5% drop.

[Meni Rosenfeld]

So, using your example, I do 5000 blocks for 0.25 BTC reward in round one and 35000 blocks for 0.583BTC in round two.  Neither of these has 1% of pool power.  In the first it is 0.5% and the second 1.166%.

40,000 blocks out of 4,000,000 would be 1%, but that ignores the simple fact that sum(Xi * Yi) <> avg(Xi) * avg(Yi)  Given the 1% is not constant, you can't really use that to underpin the argument.  If you could maintain 1%, then you would achieve the theoretical 1 BTC payment, irrespective of hoppers.

Might also be worth while to point out that pool size has something to do with the equation as well, as if 95% of the pool disappears gives a different result to a 5% drop.

Your own hashrate is fixed. The pool's hashrate varies because hoppers come and leave. You have 1% of the pool's average hashrate, but this means you'll have less than 1% early in the round and more than 1% late in the round. That's the whole point.

If you maintain 1% of the pool at all times it means you're doing partial hopping yourself, reducing your hashrate late in the round.

[PatrickHarnett]

I'm obviously not going to sway your opinion and I've done this argument elsewhere.  Of interest, I did find one of ideas behind hop-proofing actually makes hopping more attractive.  Those pay on last N share pools encourage people to jump in once N has been reached.

That isn't how it works.  N is "always reached".  The pool simply looks backwards at the last n shares irregardless of blocks.

So when a block is found your share is (your shares in last n)/(n)*50.

Thanks for pointing that out - I went back and re-read the payout system stuff.

p.s. Meni - the 1% issue is a red herring

[Meni Rosenfeld]

p.s. Meni - the 1% issue is a red herring

The issue where your own hashrate is fixed, but the pool's hashrate changes and is higher early in the round, so less of your shares are in shorter rounds than would have been without hoppers, is not a red herring. It's the crux of the whole matter, and if you don't understand it you won't understand why pool-hopping causes continuous miners in proportional pools to earn less per unit of work than they should.

I can write tables with actual numbers if you think this will help you understand. But if you won't listen to theory, simulation, practice, and thought experiments, what else can I do?

[jjiimm_64]

You can lead a horse to water....

[PatrickHarnett]

I suspect we are coming at this from quite different theoretical perspectives, and it's entertaining.

ok, did a nice little simulation based around a constant rate of single miner hashing.  eg 10 per unit time out of 1000 total at the beginning
It was interesting that the reward was invariant as to when miners hopped.
Reward per block was influenced by the proportion who hopped.
Miner reward per time unit was invariant - and that's the metric I'm interested in.

So, if lots of people hop on a long round, my percentage goes up (maybe to 100%), and my share of the reward increases up to 100%, but the time increases too.  At the top limit, it's solo mining, and expected reward per time is the same

[PatrickHarnett]

You can lead a horse to water....

Why is why I hop.  Proportial based systems are inherently unfair and easily exploitable.  Yet still lots of miners refuse to believe.  As long as they don't they won't move to "fairer" systems.  If they want to be exploited then I will exploit them.

Over the last 70 days my yield has been 27% higher than normal.   Mining is a zero sum game.  If I am making 27% then who is making 27% less. . .

btw - I believe there are lots of exploits available, especially with those pools that are either small or have special reward features.
I took the time yesterday to re-look at some of vladimir's work on pools and the relative performance of a pool with a decent history that was available - certainly there were some periods where reward rates suffered and that was probably a result of hopping where reward was only for the solved block, as opposed to pools that carry forward shares across blocks until one is solved - the descriptions don't make it explicitly clear, but that probably doesn't matter.

another consideration to bear in mind is saturation - if 99% of people hopped out of Slush, deepbit and BTC Guild, they would have difficulty finding other pools to hop to - just part of the fun

[Meni Rosenfeld]

Miner reward per time unit was invariant - and that's the metric I'm interested in.

Indeed that's what you should be interested in, specifically over a sufficiently long period of time. But if this quantity didn't drop with presence of hoppers, you have a bug in your simulation. If you post the code I'll try to find it.

[PatrickHarnett]

Hi Meni,

Actually it was fairly simple, and I wouldn't even consider it code.  In fact, after I put it together I considered doing a set of deterministic equations and putting it in a table, but that wouldn't solve our respective different positions, and it's that variety that makes the discussion good (and helps break up my day while I'm doing more complicated stuff).  I may yet do the equation/table idea and send via a pm rather than cluttering up this thread as it's move a bit away from the original topic.  I'll probably also test it different distributions, but that may not have much impact either given a  reward/time metric.

I would also have to complement you on your level-headed and reasonable responses given some of the other statements I've seen around the place.  In addition, I respect that you have done a lot of work into the pool-hopping issue and have contributed a scoring algorithm to at least one pool. 

Anyway, I don't think it's any secret that I chose deepbit when I started mining and it's size was a consideration in terms of variance of block solve times, but I was never too worried about that and like the stochastic nature of the binomial trials that make up hashing.  A couple of coins a day does not actually make much difference other than a small trickle in the background somewhere (and I'm actually wasting my hash power on a different project the next few days).