Topic: Analysis of Bitcoin Pooled Mining Reward Systems - page 4. (Read 36536 times)

This is sort of what I've attempted to do with poclbm-autohop (there's a thread about it in the mining software forum). The only thing that's ultimately pulled directly from the pools is the list of solved blocks. The biggest problem is that it relies on an API I compute on my own machine and update online when it changes. This makes me (and my computers) a major point of failure.

Actually, for each block that could possibly be each pool's last block, it calculates the expected efficiency if that block, and then does a weighted average of the efficiencies over all possibilities for the latest block.

Results from BTC Guild suggest that it works relatively effectively, but collecting enough data to be sure (or automating the data collection) is more work than I have yet wanted to do. Also, the system would have to be modified to handle hopping a pool that doesn't report any of its blocks.

In short: stat delays make hopping slightly more difficult, but they won't eliminate the problem, especially as techniques such as this become more common in the various hopping softwares.

This falls under the scope of "something happens to the pool". Doesn't have to be a bad thing! I recommend he uses a hopping-proof method.

I read your predictions about ARS and the negative buffer a while back.
I guess it all comes down to luck and patience of the Users.

or maybe Burningtoad  will change the system before it happens as he said he might.

Well, one could delay the stats by 3 hours which on BTCguild would cover the majority of rounds(at this difficulty)
but since there are very many rounds in the area of an hour  it basically keeps most hoppers away.
Maybe if/when there are no more other good PP pools the hoppers would work harder and try to hop there as well.

Actually, I was thinking about hopping without using the pool's published stats at all. When a block is found on the network which is not by any of the transparent pools, assign a certain probability to it in being from each of the delaying pools based on their hashrate. Calculate expected efficiency for such pools based on these probabilities. When efficiency is higher than other pools mine there (this will usually be when several hidden blocks are found in a relatively short time).

And that's without using technical methods to figure out block origin, of which I know very little (something to do with network traffic, long polling, etc.)

It's true. You can still hop it in exactly the same manner as before, it just is less effective. To make proportional hopper proof you need a delay that is longer than a round could ever conceivably be.

I doubt that, hoppers are just too lazy to hop it properly.

Patience, it will collapse eventually (unless something happens to the pool due to unrelated matters first).

All this math is way over most of our heads ( at least mine)

But the 2 simplest reward systems -PPS and Proportional are Implemented very nicely
by two of the bigger pools.

BTCguild with their 1 hour delay on stats makes the simplest PP system practically hopper proof. (Basically possible on fast pools only)
ARSbitcoin  and their SMPPS seems to be very good  and so far has  "survived " having a negative Buffer for short periods.

Due to real or perceived demand, I've written a complementary paper Summary of mining pool reward systems.

I've added a section and appendix about PPS, thus completing chapter 2.

Yeh, hyperbole is not really my strong point. 

I haven't made much progress with this lately, partly because I was too busy inventing a new reward system. But I hope to be able to resume work soon.

Not really that surprising. The expected gain per share decreases with the age of the round. If you stick through the whole round (and there are no other hoppers) the efficiency will be 1. So if you leave early, even if this "early" is pretty late, you'll always get more than 1.

Kano, I think you're confusing efficiency over one round with efficiency over many rounds. Your example only works over one round, or many rounds where a pool finds a block at the exact same difficulty level.

The whole point to pool hopping is that with the type of random number we deal with here and a proportional payout, there is a way to maximise your payout by leaving early. The reward for shorter rounds will over time be greater for those who leave early than for those who leave later or not at all.

Take the extreme example of a pool hitting a 10x difficulty block. You don't know this will happen, but if you hop off even at 1*difficulty, you might have had 9 rounds worth of other PPS payouts by the time the round at the original pool starts again. You've submitted the same number of shares as you would staying at the original pool, but ended up with a much greater reward. The same applies to a less extreme example - even if the pool hits a 2*difficulty block and you hop at 1*difficulty, you'd get a full rounds worth from PPS.

The real mind twister for me is that even without hopping to PPS, even if you turn your miners off at some arbitrary hop point before then end of a round, efficiency for the submitted shares will always be better than 1.0 in the long run. In the short term, variability can hide this, though.

Hope that helps.

Very nice so far. Can't wait to read the finished paper.
Thanks!

I might have to reword this sentence in a way which is less dramatic but also less ambiguous.

What I meant is that, if a future event is random and independent of the past, you can't predict it better than the prior probability.

But if the event is not independent of the past, you certainly can improve upon the prior.

"Number of shares remaining until round end" is independent on the past. "Eventual total number of shares at the end of current round" is certainly dependent on the past. At round start, "probability that the round will have >3D shares" is 5%. If 2D shares have already been found, this probability is 37%. If 2.9D have been found it's 90%, and if 3D or more have been found it's 100%.

And, pertinently, the eventual total number of shares at the end of current round (denoted N) is what matters, since your payout for every share you submit is B/N. If E[B/N] is less than what you could get per share elsewhere (which is B/D), you should mine elsewhere.

And I'll repeat the simple example - if 2D shares have already been found, then necessarily N>2D so E[B/N] < B/(2D), so you want to mine elsewhere.

So, if I say something which is true, and which was already said before many times, and I'm properly citing an influential paper about it, redoing the calculations myself and adding calculations and results which were never published before, then I'm "copying"?

You'll have 5% of the shares. You'll have more than 5% of the reward because you will have more shares in short rounds than in long rounds.

What? If a round already has two million shares, and difficulty is two million, your estimate for the round is that it will be four million shares. The two million already mined are important.


True


What? This isn't true at all. Statistics is not high school science. A single counterexample proves nothing. We are talking about what should happen over large timeframes.


I have no idea what you are trying to say here. But I am positive it doesn't make sense, because it is an indisputable fact that you make money by hopping proportional pools.

Let's say there are two pools, one with 0 blocks mined this round, and one with 10 million blocks mined. You are claiming it doesn't matter which one you mine.

If you are going to be 10% of the hashrate of each pool, and difficulty is 2 million, in theory if you choose pool A, you will make 200000 / 12000000 * 50  = .83 btc

If you choose pool B you will make 200000 / 5000000 * 50 = 5 btc.

Go back to my first point. That seems to be what you don't get. The number of blocks mined already does affect the average number of blocks that it takes the solve a block this round.

No he didn't. He said the past affects your estimation for the future.


That is true. It is also obvious, which is why nobody is disputing it.


"a gain between 28% and 22%" - going from 28% to 22% is a LOSS, not a gain.


This is not correct. You cannot use the average number of shares (from any point) needed to find a block to determine the average length of a round from the start of the round given that the round is already in progress. This is the obvious point you made earlier.

Umm - how can you start a sentence with a fact and end it with the exact opposite of that factual statement?

You've just stated correctly that you cannot predict the future, but then said the past affects the future.

Simplest link to verify it: http://en.wikipedia.org/wiki/Gamblers_fallacy

I'll put it this way:
Once you have mined n shares, there is absolutely no change in the probability of finding a block in the next share than there was in all of the previous shares back to the first.

Secondly, regarding your copy of Roulo's suggestion that pools that pay based on share% mined are affected detrimentally by hoppers
(or: hoppers make more BTC by hopping)

Let me use the simplest way to disprove a theory: An example that fails the theory will show it to be false.

Take this statement from Roulo's document:

Thus stating that from 43.5% to 100% (λ = 1) there is a gain between 28% and 22%

Yet a simple example with 50% shows this to be false:
If you mine with a share% of 10% at a site for 50% of the expected time to find a block, then, your shares will be worth on average 5% instead of 10% (since your % will slowly drop, after you leave, to 5% (on average) until the block is found)
During this time you can go to another pool with the same hash rate and do the same thing ... and thus get a total of 10% (5% from each) ... which is what you would have got to start with - not anywhere near 20% extra ...

I'll get to that too, eventually. But my already busy schedule just got a whole lot busier now that I've decided to attend the NYC conference. So it will take some time.