Topic: Solo Mining (Read 2869 times)

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

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.

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

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

You can lead a horse to water....

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?

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

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.

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.

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.

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.

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

You are wrong. In proportional pools you get on average less than what you should. In hopping-proof pools you get on average exactly what you should. If you look at your rewards over, say, a month, you'll get more in a hopping-proof pool than in a proportional pool.

You may want to take a look at the analysis paper I'm working on.

In 6 months I've mined about 30 bitcoins total. According to deepbit and slush pool I've mined 3 blocks.

I've lost out on 115 bitcoins assuming I would have struck those blocks if I was solo mining at the time.

double lol - because of the different methods of reward, some pools give away unequal rewards and some non-hopping miners get less.  I'm not in one of those pools, so I don't suffer.

lol - I love that argument, however, it does not alter the rate at which I get coins for the work I do

Proportional pools are vulnerable to pool-hopping.

The days of solo mining with low Gh/s have gone the way of CPU mining. I found one block solo at the early part of this year but I've been pool mining ever since. I got really lucky with that block though since I found it less than 24 hours after starting solo. I have switched pools many times this year as they have gotten too big or for personal tastes. I'm currently on Mainframe.

If you like small pools with pplns payouts, maybe (that's what these pools look like on a quick scan).  Not sure of your reasoning against deepbit - reasonable size, proportional payout based on actual work contributed.

As for solo - if you wanted to try, test on one of the alt-coins, that would give better chances.

Run, don't walk to Deepbit

You need a pool, but deepbit is a poor choice. Some better alternatives are http://mining.mainframe.nl, http://eclipsemc.com, http://rfcpool.com, http://www.yourbtc.net/ .

Only if you ignore variance, which is a critical statistical attribute.

That may be true now. But it's possible to modify the way pools work to eliminate the concentration of power problem, and hopefully this will be done eventually.

Transaction fees vary but they seem to be around 0.1% of the block reward.