Bitcoin Forum

"How to hop" has moved

Since hoppersden.info is closing :verysadface:  I've moved 'How to hop' to:

http://howtohop.blogspot.com.au/2012/03/introduction.html

I wish 'myself' the best of luck in his future endeavours.


###########################################################

New posts How to hop 10 (http://hoppersden.info/entries/28-How-to-hop-10-Bitclockers.com-amp-spurious-round-lengths-part-1), How to hop 11 (http://hoppersden.info/entries/29-How-to-hop-11-Bitclockers.com-amp-spurious-round-lengths-part-2) and How to hop 12 (http://hoppersden.info/entries/30-How-to-hop-12-Bitclockers.com-amp-spurious-round-lengths-part-3) on how Bitclockers.com have been paying some miners more at the expense of others.


Earlier posts:

How to hop 9: Simulating miner earnings (http://hoppersden.info/entries/27-How-to-hop-9-Simulating-miner-earnings)

How to hop 8: Determining 'c' (http://hoppersden.info/entries/26-How-to-hop-8-Determining-Slush-and-BTCMine-s-c)

How to hop 7: Expected values (http://hoppersden.info/entries/24-How-to-hop-7-Expected-share-values)

 How to hop 6: Basic probability for bitcoin miners (http://hoppersden.info/entries/25-How-to-hop-6-Basic-probability-for-bitcoin-miners), rewritten with updated information

How to hop 5: Back to basics (http://hoppersden.info/entries/20-How-to-hop-5-Back-to-basics) also rewritten with errors corrected.

How to hop 4: BTCMine and more (http://hoppersden.info/entries/19-How-to-hop-4)

How to hop 3: the 50-50 tax (http://hoppersden.info/entries/18-How-to-hop-3-the-50-50-tax)

How to hop 2: More on score. (http://hoppersden.info/entries/17-How-to-hop-part-2-More-on-score.)

How to hop 1: Slush's pool. (http://hoppersden.info/entries/15-How-to-hop-part-1-Slush-s-pool.)

News:
Important Slush pool news https://bitcointalk.org/index.php?topic=47411.msg603675#msg603675 (https://bitcointalk.org/index.php?topic=47411.msg603675#msg603675)

Since you may be unable to comment at the actual website, I also welcome any questions or comments about its contents here.

Any suggestions for topics to cover are also welcome.

Excellent work.

I have just invented a simple game for miners.  I believe it clarifies the problem with the proportional reward system (at least for people who are more comfortable with words than with formulae).  If you think that I've missed the point or made a subtle error then please correct me.  Also, feel free to use/extend this as you see fit.

This is a 4-player game.  There is a central pot into which each player must deposit a bitcoin to play.  A fair coin is flipped repeatedly.  If a tails comes up at any point then the game ends immediately and the 4 players split what is left in the pot evenly.
If the coin comes up heads on the first flip then player 1 takes a bitcoin from the pot.
After the second head, player 2 takes a bitcoin.
After the third head, player 3 takes a bitcoin.
After the fourth head, player 4 takes a bitcoin.

This game comes with the question: If you were invited to play this game, which player would you like to be?

Of course, the idea is that:

• Honest 24/7 proportional miners will be happy as player 3 or 4.
• People who have an ethical problem with pool hopping will be disgusted with the game and refuse to have any part in it.
• Pool hoppers will ask to be player 1.

Thanks for posting your game teukon - it kept me busy for quite a while. I like the fact that it's easily understandable, and it's something that makes for a simple thought experiment - and it's clear to see that it's unfair. It's not a good analogy of proportional pool hopping vs full time mining since the sequential payout part = which I think you intend to mimic the skew toward smaller block sizes - has a much too large an effect. But generally it's a good introduction to proportional pool mining, moral judgements aside.

It got me to thinking for the last day or so - how could I change your game to be a better analogy of prop pool mining and at the same time keep it a simple thought experiment? The short answer is that I couldn't. But your game did inspire me, and I extended it into a dice game that mimics proportional pool mining quite well. It's no longer a good thought experiment, but I think it would be a good teaching tool.

Dicecoin

Dicecoin is a dice game played at the Zero Sum Casino. It uses a 10 sided die, and there can be any number of players.

Rules:
1. A die is thrown until a '10' appears.
2. Each throw costs a total of $10, which is split evenly among all players present for the throw.
3. When the '10' appears, the prize of $100 is split proportionally amongst all players, per throw played.
4. Players can leave or join a game at any time.
5. There must be more than one player for a game to continue.

Assumptions:
1. Gamblers at the Zero Sum Casino are just as irrational about gambling as anyone else - they will stay in a game that lasts a long time and costing a lot because they want to recoup or at least offset their losses. They also jump into a game in progress because it has been going on for a while and "it's due for a '10' ".
2. More rational players also play to the end of a game because they know that at the Zero Sum Casino game rules are written so that on average their wins = losses.
3. There are never any shortage of players.

Example: A game lasts for 20 throws. There are ten players and all players stay until the end of the game and no one else joins. Each throw costs each player:

$10 divided by the number of players = $1, for a total cost of $20 per player.

Each player wins $100 divided amongst the players proportional to the number of throws they played:

$100/10/20 = $0.50 per player per throw played = $10 per player. The total profit = winnings - loss = -$10. So for this example, the players lose $10 each.

Question: is there a winning strategy for this gambling game? What is it?

Extra credit questions: What is the percentage improvement in winnings (winnings for  your strategy/winnings for no strategy), and what is your expected profits in dollars per game? Frame your answer in mathematical terms as per  How to hop 6: Basic probability for bitcoin miners (http://hoppersden.info/entries/25-How-to-hop-6-Basic-probability-for-bitcoin-miners).

 

So here's a competition for everyone:

Post your strategy here, with your reasoning. If you can answer the first question, have the winning strategy and your reasoning is sound, you'll win 1 btc from me. The winner for the extra credit questions will be the poster with the simplest, clearest and most informative explanation, will win 4btc from me. Good chartporn will be helpful but not necessary.

Rules:

• The winner will be the first poster with a correct answer before midnight 19-10-2011 UTC.
• You can post multiple answers if you think your first answer might be incorrect, but only the most recent answer will be considered.
• Feel free to discuss each other's answers.

I'll post hints here from time to time.

A read of How to hop 5: Back to basics (http://hoppersden.info/entries/20-How-to-hop-5-Back-to-basics) and  How to hop 6: Basic probability for bitcoin miners (http://hoppersden.info/entries/25-How-to-hop-6-Basic-probability-for-bitcoin-miners) might be helpful.

Thanks again for such a great idea, teukon!

Cool!

My idea was to try to distill the essential problem of the proportional reward system to the point where most people can quickly read it and see the problem as obviously as we do.  Unfortunately it has warped so much that I feel most people will see only a loose connection with the proportional reward system.

Dicecoin fills a big gap here.  You really do have something which closely reflects the proportional reward system but have neatly stripped away talking about hashes, shares, and difficulty (which just confuse the issue).  Unfortunately the game is quite a bit more complicated than mine but is certainly more accessible than the proportional reward system and likely will become more so with a little tidying up.  I like the idea of phrasing it as a problem but it very much reminds me of 1st year undergraduate probability questions ;).

Some thoughts:

Point (2) begins with "Each each".

I personally slightly prefer using a 6-sided dice for it's ubiquity and for shorter games but I see that 10 allows for simpler costs and rewards.  The "5" in $50 and $500 is just noise in my opinion and I'd be tempted to go with $10 and $100.

Perhaps some of the wording can be cleaned up to make the game quicker to understand.  I only suggest little things like replacing "goes" with "lasts" in "Example: A game goes for 20 throws."

Your rewards for solving these problems are generous.  I would instead promise to reward particularly elegant and well explained solutions as these have real value.  This is however my opinion as a maths tutor and I'm known for being harsh :).

Best of luck with this.  Feel free to use my game on your blog as a simple thought experiment if you like.  There is no obligation of course, I merely wish to point out that it should be considered public domain information.

Thanks for the props, teukon.

Ooops! Fixed.


I actually started with a six sided die but I saw that there were so many online dice generators I figured people wouldn't have to brave their local D&D store to try some experiments if I used a 10 sided die. I used ten sided because, as you say, it makes working with the mean values easier. The $500 vs $50 started as the 50 btc reward we're used to, but I had to make the game seem a bit more enticing so I just increased it by an order of magnitude. $100 vs $10 would be better, and might distract people less - important since the actual reward doesn't even matter for the first question (hint here, folks!).


I agree. I'll change that.

That well expressed. It's what I'd hoped for the 'extra credit' answers, but I think I'll use your phrasing.


I'm already planning a post on mining-like games. Plus 'Dicecoin' is only an extension of your game, so i'm already using it - thanks for making the game public domain.

Ah! I see.

One thing I've been wondering about this morning is pool hopping with merged mining.  Calculating when it is profitable to mine in a proportional pool taking into account the Bitcoin and Namecoin blocks is an interesting extension.  One could also try factoring in fees and promotions but I don't think this would be as much fun.

Interesting idea. I think it's doable - I already have multipool sims that can calculate efficiency of a hopped round, and the difference in D (at current nmc D) isn't a problem.  It would have to be vanilla, because like you say the extraneous stuff is just annoying and it changes from time to time so I'd just ignore it.

At the current namecoin D the 1.0 efficiency share should still be at 0.43xD. The only difference is the expected value of a share. The number of rounds and reward per round would be built into the share value. Then you have to make a function relating btc share value to nmc share value which would allow you to hop at the right time. I already made a function for determining the best time to hop from prop to slush and back, so i think a similar function for nmc to btc might work.

But I don't really know enough about it yet, and there's bound to be complications and issues I haven't thought of. If enough people want a strategy for merged mining I'll spend some time on it - unless you come up with an answer first?

Winning strategy:

Play five throws per game only, starting at the beginning of a round and then stop until a 10 is rolled. Repeat.

Assumptions:

A. The number of players participating in the game is relatively stable and big enough so that your participation or your non participation does not make a significant difference (say number of players N=100,000)

B. Based on the first assumption, the reward is 100/N and your cost per round is 10/N, therefore the reward is 10 times your cost per round.

In the link below, you will find an spreadsheet detailing the results that a player would expect to get if they would stay in for a number of throws (1 to 10 throws) and then leave and the results they would get if they would stay and play throughout the game without leaving for any throw. There are therefore 11 sheets (for 1 throw, for 2 throws, ..., for 10 throws, for all throws) which are 11 different strategies.

https://docs.google.com/spreadsheet/ccc?key=0Ar02Q-JTJDS8dG5wblRYUTVzeUVhaUMtQjlwUXJwWlE&hl=el

Explanation for the sheet :

1. Column 1 is the number of throws until a 10 is rolled, distinct possibilities. I have put numbers up to 50 throws, the reason will become clear in column 3

2. Column 2 is the probabiltity of this number of throws happening. The probability of rolling a 10 after 1 throw is 1/10. The probability of rolling a 10 after exactly 2 throws is (9/10)*(1/10) that is, anything else but a 10 is rolled in the first throw and a 10 is rolled in the second. The probability of rolling a 10 after exactly 3 throws is ((9/10)^2)*(1/10) and so on

3. Column 3 is the accumulated probability of rolling a 10 with UP TO the specified number of throws. So, the accumulated probability of throwing a 10 after at most 2 throws is (1/10)+((9/10)*(1/10)) which is the probabilty of the first throw rolling a 10 and the second throw rolling a 10, as calculated in column 2. As seen on the tables, the probability of rolling a 10 after at most 50 throws is about 99.5%, so this is why I stopped it there and did not calculate further results for a greater number of throws

4. Column 4 is the cost to the player if they play only for the number of throws which is referred in the Sheet name. So for the "1 throw" sheet, the player only plays during one throw. Notice for example that for the "4 throws" sheet, the cost increases by 1 unit up to the 4th throw and then remains the same. The cost of one throw is calculated as 1 unit, because, given the assumption B above, the reward can be very easily calculated as 10 units, regardless of the actual amount and the number of players present at the game.

5. Again according to assumption B above, the reward is calculated as follows: (Total reward of 10 units for each player) divided by (number of throws until a 10 is rolled) and then multiplied by the number of throws in which the player has participated (which is exactly his cost for these number of throws in cost units).

6. Finally in column 6 (or more specifically in the Sum of column 6 which is found above the table in each sheet) the truth is revealed: Multiplying the probability of a number of throws until a 10 is rolled by the difference between Reward and Cost for this number of throws and this particular strategy gives the expected value in pure profit of each outcome. In short (Reward-Cost)*Probability. Obviously for a round which takes 10 throws to roll a 10 the expected value is 0 which means everybody gets exactly their money back. For a round greater than 10 throws the expected value is negative, and for a round with less than 10 throws the expected value is positive.

Now look at the number at the top right of each sheet which sums up all the expected values of the possible outcomes (1 to 50 throws to roll a 10). For the player participating in all throws the expected value converges to 0 after a long number of rounds (if I had calculated the results up to 200 throws it would be more obvious).

The best number is given by the strategy of playing 5 throws and then leaving. In this case the expected value for a large number of rounds is 2.64 which means that for every unit of betting currency you get 2.64 units as a profit.

To answer the extra credit question, with typical calculations:

A player with no strategy that just stays in for all throws and all rounds until he gets bored, can expect to receive 1 unit for every 1 unit that they play with. 0% return

A player playing the optimal strategy can expect to receive 3.64 units for every 1 unit that they play with. (3.64-1)/1=2.64 = 264% return. In other words, he gets an improvement of 264% over having no strategy.

Really enjoyed the challenge and the analysis, which proved the basic pool-hopping premise also to myself. I suppose that taking this analysis to the Bitcoin mining conditions, a similar result can be made plain, with much larger numbers of course.



Feel free to use the spreadsheet if you find it useful. And thanks for the very informative posts you've done so far.

I just hope I win this competition, as I have little luck mining lately  ::).

3phase: you misunderstood the game
the prize is distributed per amount of throws you play

so after 20 throws, the people who played 20 will get a larger share than the person who played 5

Please have a look again. Maybe my explanation is not good enough, but the spreadsheet shows this.

after 10 throws total the person with 5 throws gets a better share of the pot than at 20, so your conclusion that 5 any consecutive trials is best cannot be possibly true

EDIT: I will leave the post as is, as it might be useful for discussion, but I just want to say that my conclusion is wrong. iopq is correct. If you enter in the 11th throw, the probability of the next throw rolling a 10 is 1/10 as stated, but your expected reward is much smaller, because 10 throws have already been played.

This says to me that for pure prop pools, only hopping at the beginning of the round is beneficial. It also however points to a curious tweak with score based pools such as Slush, where the value of the previous shares is gradually diminished to zero over time, and might provide an opportunity to hop there, even later than the start of the round. I am currently thinking on this.

I also edited my first post to remove the mistaken conclusion

ORIGINAL POST:

Please consider the simple question for this simplified game that was proposed:

I play for 5 throws in a round with 20 throws. I invest 5 units of money. I receive as a reward (10/20)*5=2.5 units according to my initial assumption. Of course if the round has only 10 throws to roll a 10, I will receive 5 units (as much as I had invested).

But on the 20-throw round, does something change if I participate in throws 1-5 or if I participate in throws 11-15 (after having seen the first 10 unsuccessful throws)? No, it doesn't. The reward is the same.

My point is that if you get to the gaming table during a round which already has 10 unsuccessful throws, this fact does not affect the probabilities of the next throws at all due to the independence of events. So you are perfectly fine to follow the proposed strategy (playing for the next 5 throws, throws 11-15 that is) and if the round ends with 20 throws you receive the same amount of reward as someone who followed the same strategy from the beginning of the round (playing in throws 1-5).

You cannot know in advance the number of throws that will be needed. For the first two throws, the probability of rolling a 10 is 0.09.

If there have already been 10 unsuccessful throws in a round, the probability of rolling a 10 in the next two throws (throw 11 and throw 12) is again 0.09.

What might also help perception-wise would be to consider a more "strange" strategy whereby a player only plays on throws 11-15 every round. This strategy still has positive expected value, but it would be pointless, as they will miss many rounds (65% of them actually) which will be shorter than 10 throws, meaning that they don't exploit the positive expectancy of the strategy fully. But what if there were another 20 tables around at different stages of the round (in terms of number of throws)? Table-hopping would enable a player to fully exploit the positive expectancy if his strategy, regardless of his starting throw number.

Sorry, I give up, I can't explain this in English any better.

We have our first entrant! Looks like you did a whole lot of hard work there 3phase.

I have clarified the rules of the competition, see the competition post (https://bitcointalk.org/index.php?topic=47411.msg567737#msg567737).

2nd hint for the competition - if you don't have the probability theory chops to to answer the first question and if you have some time, a 10 sided die(or online dice generator), a pencil and lots of paper you should be able to answer this question by playing the game and recording the results.

I would probably just generate lots of rolls and then calculate results for different strategies you think might work. Post your best strategy and the results and working out and see if you win!

If you do have the enough knowledge of probability to calculate results, I would probably check your conclusions using dice and a pencil, or a simulator if you can make one.

It only took half an hour with Excel. My probability 101 class was 25 years ago, so I don't remember much, but I can still understand certain things.  And yes, a simulator would be best, but it is beyond my means.

Thanks.

Try using this online dice generator (http://dicelog.com/dice) to generate data. Or this webpage (http://www.mathwave.com/articles/random-numbers-excel-worksheets-p2.html) shows you how to generate a bunch of geometrically distributed random numbers in Excel. Give it a try. 50 games worth of data will be enough to allow you check the accuracy of your strategy to your own satisfaction.

You did have a good idea about how to solve it though, only your expected value calculations were wrong. 'How to hop 7' will be done soon and might be helpful.


The solution is actually very interesting. Check out How to hop part 1: Slush's pool (http://hoppersden.info/entries/15-How-to-hop-part-1-Slush-s-pool.),  How to hop part 2: More on score. (http://hoppersden.info/entries/17-How-to-hop-part-2-More-on-score.), and  How to hop 4 (http://hoppersden.info/entries/19-How-to-hop-4).

Now, back to the competition - ready for another try? :)

with two players the game goes as following:

player 1 pays $5
player 2 pays $5

then player 1 leaves the game, player 2 keeps playing
if the game ends on the...

first toss
player 1 gets 1/2, pays $5, so wins $50
same for player 2

second toss
player 1 gets 1/3, pays $5, wins $33.(3)
player 2 pays $15, gets 2/3, wins 66.(6)

nth toss
player 1 gets 1/(n+1), pays $5, wins 100/(n+1)
player 2 pays $10n + $5, gets n/(n+1), wins 100n(n+1)

there's 10 outcomes, 1 of which is a win, and 9 of which is wait until next toss
player 1 - win for the nth toss

win(n) =  (100/(n+1) + 9*win(n+1))/10 = 10/(n+1) + 9/10*(win(n+1))
n starts at 1

so win(1) = 5 + 9/10*(win(2))
win(2) = 3.(3) + 9/10*(win(3))

10/2 + 9/10*(10/3) + (9/10)^2 * (10/4)
5 + 3 + 2.25 + ...

win(n) = (9/10)^n * (10/n+2)
Sum[(9/10)^n * (10/(n+2)),{n, 0, Infinity}] = 100/81 (-9+10 log(10)) ~= 17.3

so he profits a little over 12.3 dollars every time he plays if he only plays the first game which is 246% profit!

if he plays the first two:
toss 1: pays 5, wins 50
toss 2: pays 10, wins 50
toss 3: paid 10, wins 2/5 * 100 = 40
toss 4: paid 10, wins 2/6 * 100 = 33.3
toss n: paid 10 if n=>2, win 2/(n+2) * 100

but now let's include profit calculations into the series because the first time we only paid 5 but second time ten
1/10(50 - 5) + (9/10)*1/10 (50 - 10) + (9/10)^2 * 1/10 (40 -10) + ...
5-0.5 + 9/10*(10*2/4-1) + (9/10)^2(10*2/5-1) + (9/10)^3(10*2/6-1) + ...

profit(n) = 4.5 + (9/10)^n(10*2/(n+3) - 1)
Sum[(9/10)^n(10*2/(n+3) - 1),{n, 1, Infinity}] ~= 11.7
11.7 + 4.5 = 16.2 which is higher than 12.3, but we had to invest more money on the subsequent throws, but still a higher EV, so throw at least twice

first three:
toss 1: paid 5, wins 50, profit 45
toss 2: paid 10, wins 50, profit 40
toss 3: paid 15, wins 50, profit 35
toss 4: paid 15, wins (3/7 * 100), profit 3/7 * 100 - 15

4.5 + 9/10(4) + (9/10)^2(3.5) + (9/10)^3(10 * 3/7 - 1.5) + ...
n>=3, profit(n) = (9/10)^n(10*3/(n+4) - 1.5) + 4.5 + 9/10(4) + (9/10)^2(3.5)
Sum[(9/10)^n(10*3/(n+4) - 1.5),{n, 3, Infinity}] + 4.5 + 9/10(4) + (9/10)^2(3.5) ~= 17.6

which is higher than 16.2, so we will keep going
first four:
toss 1: paid 5, wins 50, profit 45
toss 2: paid 10, wins 50, profit 40
toss 3: paid 15, wins 50, profit 35
toss 4: paid 20, wins 50, profit 30
toss 5: paid 20, wins (4/9 * 100), profit 4/9 * 100 - 20

4.5 + 9/10(4) + (9/10)^2(3.5) + (9/10)^3(3) + Sum[(9/10)^n(10*4/(n+5) - 2),{n,4, Infinity}] = 17.7

keep going

first five:
4.5 + 9/10(4) + (9/10)^2(3.5) + (9/10)^3(3) + (9/10)^4(2.5) + Sum[(9/10)^n(10*5/(n+6) - 2.5),{n,5, Infinity}] ~= 17.3

we could keep going, but 5 is worse than 4, so the solution is stay for the first 4 tosses vs. one player who keeps on playing

so we get the EVs here:
1 toss: 12.3
2 tosses: 16.2
3 tosses: 17.6
4 tosses: 17.7
so the first throw has the expectation of 17.3 (346% expected), second throw has the expectation of 8.9 (178% expected), third throw has the expectation of 6.8 (136% expected), fourth throw has the expectation of 5.1 (102% expected) and all throws afterwards have below 100%

throwing every time gives you 0 expected value vs. an every time thrower as you just split the winnings 50-50 and negative expected value vs. someone who throws only the first few

now let's calculate the same for a three player game because there's a constraint that there has to be more than one player for the game to continue

player 1 pays $3.(3)
player 2 pays $3.(3)
player 3 pays $3.(3)

let's calculate the EV of the one toss strategy by player 1

toss 1: paid 3.(3), wins 33.(3), profit 30
toss n: paid 3.(3), profit 100/(1+2+2n) - 3.(3)

EV = 3 + Sum[(9/10)^n((10*1/(1+2+2n)) - 1/3),{n, 1, Infinity}] ~= 6.85

two toss strategy
toss 1: paid 3.(3), wins 33.(3), profit 30
toss 2: paid 6.(6), wins 33.(3), profit 26.(6)
toss n: paid 6.(6), profit 100/(2+2+2n) - 6.(6)

EV = 3 + 2.4 + Sum[(9/10)^n((10*2/(2+2+2n)) - 2/3),{n, 2, Infinity}] ~= 9.32

three toss strategy
toss 1: paid 3.(3), wins 33.(3), profit 30
toss 2: paid 6.(6), wins 33.(3), profit 26.(6)
toss 3: paid 10, wins 33.(3), profit 23.(3)
toss n: paid 10, profit 100*3/(3+2+2n) - 10

EV = 3 + 2.4 + 1.89 + Sum[(9/10)^n((10*3/(3+2+2n)) - 1),{n, 3, Infinity}] ~= 10.3

four toss strategy
toss 1: paid 3.(3), wins 33.(3), profit 30
toss 2: paid 6.(6), wins 33.(3), profit 26.(6)
toss 3: paid 10, wins 33.(3), profit 23.(3)
toss 4: paid 13.(3), wins 33.(3), profit 20
toss n: paid 13.(3), profit 100*4/(4+2+2n) - 13.(3)

EV = 3 + 2.4 + 1.89 + 1.458 + Sum[(9/10)^n((10*4/(4+2+2n)) - 4/3),{n, 4, Infinity}] ~= 10.5

five toss
toss 1: paid 3.(3), wins 33.(3), profit 30
toss 2: paid 6.(6), wins 33.(3), profit 26.(6)
toss 3: paid 10, wins 33.(3), profit 23.(3)
toss 4: paid 13.(3), wins 33.(3), profit 20
toss 5: paid 16.(6), wins 33.(3), profit 16.(6)
toss n: paid 16.(6), profit 100*5/(5+2+2n) - 16.(6)
EV = 3 + 2.4 + 1.89 + 1.458 + 1.0935 + Sum[(9/10)^n((10*5/(5+2+2n)) - 5/3),{n, 5, Infinity}] ~=10.4
which is less than the previous strategy, so four throws is better

first throw has 206% efficiency, second throw has 174% efficiency, third throw has 129% efficiency, fourth throw has 106% efficiency, fifth has below 100%

notice that it costs us less to play, but the three player scenario is worse because we put in less money overall and because our edges are smaller

four player game one toss strategy

toss 1 profit: 100*1/(1+3) - 2.5 = 22.5
toss i(=n+1) profit: 100*1(1+3i) - 2.5 = 100*1(1+3+3n) - 2.5
EV = 2.25 + Sum[(9/10)^n((10*1/(1+3+3n)) - 1/4),{n, 1, Infinity}] ~= 4.76

two toss strategy
toss 1 profit: 100*1/(1+3) - 2.5 = 22.5
toss 2 profit: 100*2/(2+3+3) - 5 = 20
toss i profit: 100*2(2+3+3n) - 5
EV = 2.25 + 1.8 + Sum[(9/10)^n((10*2/(2+3+3n)) - 2/4),{n, 2, Infinity}] ~= 6.55

three toss strategy
toss 1 profit: 100*1/(1+3) - 2.5 = 22.5
toss 2 profit: 100*2/(2+3+3) - 5 = 20
toss 3 profit: 100*3/(3+3+3*2) - 7.5 = 17.5
toss i profit: 100*3(3+3+3n) - 7.5
EV = 2.25 + 1.8 + 1.4175 + Sum[(9/10)^n((10*3/(3+3+3n)) - 3/4),{n, 3, Infinity}] ~= 7.29

four toss strategy
toss 1 profit: 100*1/(1+3) - 2.5 = 22.5
toss 2 profit: 100*2/(2+3+3) - 5 = 20
toss 3 profit: 100*3/(3+3+3*2) - 7.5 = 17.5
toss 4 profit: 100*4/(4+3+3*3) - 10 = 15
EV = 2.25 + 1.8 + 1.4175 + 1.0935 + Sum[(9/10)^n((10*4/(4+3+3n)) - 4/4),{n, 4, Infinity}] ~= 7.51

five toss strategy
toss 1 profit: 100*1/(1+3) - 2.5 = 22.5
toss 2 profit: 100*2/(2+3+3) - 5 = 20
toss 3 profit: 100*3/(3+3+3*2) - 7.5 = 17.5
toss 4 profit: 100*4/(4+3+3*3) - 10 = 15
toss 5 profit: 100*5/(5+3+3*4) - 12.5 = 12.5
EV = 2.25 + 1.8 + 1.4175 + 1.0935 + 0.820125 + Sum[(9/10)^n((10*5/(5+3+3n)) - 5/4),{n, 5, Infinity}] ~= 7.43

again, the result is four toss strategy is best, but again our edge is lower, and we pay less so we win less
first toss is 190% efficiency, second toss is 172% efficiency, third toss is 130% efficiency, fourth toss is 122% efficiency, fifth toss is 97% efficiency

let's analyze what the players who enter the game "when it's due for a 10" do for you
they actually just act to decrease the contribution of the "play from beginning to end" players because they will pay less part of the fee for the round, but they also get a share so they cut into your profits if you're no longer putting any more money in while not "helping" to get a 10
this is different from late hoppers in bitcoin mining because those people actually let the pool find a block faster

A more faithful game design would be:

Each person pays $1 to throw two ten-sided dice. When the two dice come up snake eyes (1 and 1 on both dice, which happens 1/100 of the time) the $100 prize is shared by everyone who threw dice in this game proportional to the amount of throws they've made. After how many throws since the game started should you stop throwing, given that the game will keep on going without you?

I am not sure you are taking into account the fact that the probability of a round ending after 1 throw is 0.1 which is greater than the probability of a round ending after 2 throws (0.09) and so on.

Therefore if you want to calculate the expected profit from each strategy, the profit for each round length (which is a known) should be multiplied by the probability for this round length (also known) and then all these profits summed up to n=infinite:

Expected profit = Sum{profit(n)*probability(n)} where n is the round length and varies from 1 to infinity.

I am, that's why I divide everything by ten (1/10 probability of success) and multiply each round by 0.9 (which 9/10 probability of fail on previous rounds)

so my summation goes like this

1/10*P(1) + 9/10*1/10*P(2) + (9/10)^2*1/10*P(3) etc.

Nice layout iopq, you explained your thinking so I could follow what you were doing. I noticed that you are assuming the correct strategy is to leave the game at a particular throw. Wouldn't it be better to start from the point of view of not knowing what the strategy is and instead calculate the expected value of each throw?

While I'm at it, here's the third hint for the competition: There's a way of finding the expected profit for a particular throw that makes  the number of players irrelevant.

Great game - much more faithful to bitcoin, and a lot simpler. Wish I'd thought of it.

"Dicecoin" has a few things added in to make it look more difficult than it really is, so while it makes a good exercise in calculating expected values, it's not too easy to follow for someone who is not familiar with bitcoin already. But without having checked your game out properly, it's much more faithful to teukon's original idea for a game, teaching people about how bitcoin mining works.

Just a note on your question phrasing, I think it's better to ask if there *is* a strategy and then ask what it is, rather than to explain what the strategy is and to ask what the variable should be. You're giving away the fact there is one.

For example, if the payout was paid proportionally only to the people making the last ten throws - including the ones in the last game, if it's a short game - is there a winning strategy and what would it be? (no prizes for that answer!)

Assuming that there were at least 9 past throws and will be at least 9 future throws, a throw gives the player an expected return of exactly $1.  This is because a throw has a total payout expected value of $100/100 = $1 and a player will receive 1/10 of the payout for their throw and 1/10 of the payout for each of the 9 future throws.  If there are fewer than 9 past throws then you receive a large proportion of the payout for your throw so on average you will profit.  If there will be fewer than 9 future turns then you clearly lose on average.

Consequently, in most real world cases, the winning strategy is to make as many of the first 10 throws as possible and then leave (unless there is a real chance that there will be fewer than 20 throws in total).

For miners this means joining new PPLNS pools that you think have implemented the reward system in this naive way and leaving after the first N shares have been found (again, banking that the pool will receive at least 2N shares).  Hopefully new PPLNS pools will not be so basic.

I don't think that's possible

consider this:

you throw 4 times when there are 4 players in the game
after 4 throws a group of friends come back from lunch and now there's 10 people in the game for throws 5 and up (you stop playing if you win before 4 throws and leave)

EV = 2.25 + 1.8 + 1.4175 + 1.0935 + Sum[(9/10)^n((10*4/(4+9+9n)) - 4/4),{n, 4, Infinity}] ~= 2.76

suddenly, your EV more than halved because the amount of players in the later rounds doubled

Sorry I don't have time to respond properly just now. I did want to let everyone know that How to hop 7: Expected values (http://hoppersden.info/entries/24-How-to-hop-7-Expected-share-values) is posted.

No hints today, since 'How To hop 7' has lots of hintyness inside. I hope to be able to respond to you all tonight.

Cheers!

I wrote: not
See the difference? Ignore the players, they are irrelevant to the game itself.

ten thousand players scenario
one toss strategy:

toss 1 profit: 100*1/(1+9999) - 10/10000 = 0.009
toss i(=n+1) profit: 100*1(1+9999i) - 1/1000= 100*1(1+9999+9999n) - 1/1000
EV = 0.0009 + Sum[(9/10)^n((10*1/(1+9999+9999n)) - 1/10000),{n, 1, Infinity}] ~= 0.00156

two toss:
toss 1 profit: 100*1/(1+9999) - 10/10000 = 0.009
toss 2 profit: 100*2/(2+2*9999) - 20/10000 = 0.008
EV = 0.0009 + 0.0008*0.9 + Sum[(9/10)^n((10*2/(2+9999+9999n)) - 2/10000),{n, 2, Infinity}] ~= 0.00222

three toss
toss 1 profit: 100*1/(1+9999) - 10/10000 = 0.009
toss 2 profit: 100*2/(2+2*9999) - 20/10000 = 0.008
toss 3 profit: 100*3/(3+3*9999) - 30/10000 = 0.007
EV = 0.0009 + 0.0008*0.9 + 0.0007*0.9*0.9 + Sum[(9/10)^n((10*3/(3+9999+9999n)) - 3/10000),{n, 3, Infinity}] ~= 0.00252

four toss
toss 1 profit: 100*1/(1+9999) - 10/10000 = 0.009
toss 2 profit: 100*2/(2+2*9999) - 20/10000 = 0.008
toss 3 profit: 100*3/(3+3*9999) - 30/10000 = 0.007
toss 4 profit: 100*4/(4+4*9999) - 40/10000 = 0.006
EV = 0.0009 + 0.0008*0.9 + 0.0007*0.9*0.9 + 0.0006*0.9*0.9*0.9 + Sum[(9/10)^n((10*4/(4+9999+9999n)) - 4/10000),{n, 4, Infinity}] ~=0.00262

five toss
toss 1 profit: 100*1/(1+9999) - 10/10000 = 0.009
toss 2 profit: 100*2/(2+2*9999) - 20/10000 = 0.008
toss 3 profit: 100*3/(3+3*9999) - 30/10000 = 0.007
toss 4 profit: 100*4/(4+4*9999) - 40/10000 = 0.006
toss 5 profit: 100*5/(5+5*9999) - 50/10000 = 0.005
EV = 0.0009 + 0.0008*0.9 + 0.0007*0.9*0.9 + 0.0006*0.9*0.9*0.9 + 0.0005*0.9*0.9*0.9*0.9 + Sum[(9/10)^n((10*5/(5+9999+9999n)) - 5/10000),{n, 5, Infinity}] ~= 0.00262

first throw is 156% efficiency, second throw is 166% efficiency, third throw is 130% efficiency, fourth throw is 110% efficiency, the fifth throw being a wash
we're really reaching the limits of Wolfram Alpha here, though, the result it gave me is that fifth throw is slightly higher EV in the next few digits, but I can't be sure if that's right or not since it's not giving the exact formula, but only an estimation due to the huge amount of computation we're doing

I mean, I don't get how we got the second throw as more efficient than the first, it could be all calculation errors
I'll try with a thousand players later

that's not true, I've shown that the EV for each throw depends on the number of players in the game due to the fact that more players participating doesn't increase the chance of a payout, but generates shares

so the monetary value is inherently linked to the amount of players participating in each throw
it gets especially cheap to participate in a throw when a lot of players participate

example:
when a lot of players participate in throw 5 because it's a lucky number or whatever, it can be profitable to participate in it yourself, since the amount of money you pay to participate is now less due to the money splitting thing, but you still get a full share despite paying less dollars

I certainly appreciate your tenacity!

But try finding the expected value of a throw. Go to HTH7 (http://hoppersden.info/entries/24-How-to-hop-7-Expected-share-values) and look at how I derive the expected value for a share, not for the hopper.

Not quite - you showed that the EV for a particular player's throw depends on the number of players, not the expected value of the actual throw.

thousand players scenario
one toss strategy:

toss 1 profit: 100*1/(1+999) - 10/1000 = 0.09
toss i(=n+1) profit: 100*1(1+999i) - 1/100= 100*1(1+999+999n) - 1/100
EV = 0.009 + Sum[(9/10)^n((10*1/(1+999+999n)) - 1/1000),{n, 1, Infinity}] ~= 0.0156

two toss:
toss 1 profit: 100*1/(1+999) - 10/1000 = 0.09
toss 2 profit: 100*2/(2+2*999) - 20/1000 = 0.08
EV = 0.009 + 0.008*0.9 + Sum[(9/10)^n((10*2/(2+999+999n)) - 2/1000),{n, 2, Infinity}] ~= 0.0222

hundred players scenario
toss 1 profit: 100*1/(1+99) - 10/100 = 0.9
toss i(=n+1) profit: 100*1(1+99i) - 1/100= 100*1(1+99+99n) - 1/100
EV = 0.09 + Sum[(9/10)^n((10*1/(1+99+99n)) - 1/100),{n, 1, Infinity}] ~= 0.157

toss 1 profit: 100*1/(1+99) - 10/100 = 0.9
toss 2 profit: 100*2/(2+2*99) - 20/100 = 0.8
EV = 0.09 + 0.08*0.9 + Sum[(9/10)^n((10*2/(2+99+99n)) - 2/100),{n, 2, Infinity}] ~= 0.223

ten players scenario
toss 1 profit: 100*1/(1+9) - 10/10 = 9
toss i(=n+1) profit: 100*1(1+9i) - 1/10= 100*1(1+9+9n) - 1/10
EV = 0.9 + Sum[(9/10)^n((10*1/(1+9+9n)) - 1/10),{n, 1, Infinity}] ~= 1.68

toss 1 profit: 100*1/(1+9) - 10/10 = 9
toss 2 profit: 100*2/(2+2*9) - 20/10 = 8
EV = 0.9 + 0.8*0.9 + Sum[(9/10)^n((10*2/(2+9+9n)) - 2/10),{n, 2, Infinity}] ~= 2.36

I can see that a share is worth different amounts even when scaled to what it costs
the ratios for each number of players is not the same

in fact, the solution for larger number of players is five tosses and for a lower number of players is four tosses
for five thousand players:

four toss
0.0018 + 0.0016*0.9 + 0.0014*0.9*0.9 + 0.0012*0.9*0.9*0.9 + Sum[(9/10)^n((10*4/(4+4999+4999n)) - 4/5000),{n, 4, Infinity}] = 0.00524994
five toss
0.0018 + 0.0016*0.9 + 0.0014*0.9*0.9 + 0.0012*0.9*0.9*0.9 + 0.0010*0.9*0.9*0.9*0.9 + Sum[(9/10)^n((10*5/(5+4999+4999n)) - 5/5000),{n, 5, Infinity}] = 0.00525006

so for a sufficiently large number of players you need to toss 5 times

teukon, I'm not clear on what you're saying here. In the real world, the chances you mention can be calculated. See if the following makes sense to you, or show me where I'm wrong.

To find out if on average you will profit or not, for this type of payout system you have to find how many 'snake-eyes' are expected in the next 10 throws. If there is 0, your throw is worth nothing. If there are 1, your throw is worth $10, 2 snake eyes you get $20 up to $100 if there are 10 snake eyes in the next 10 throws.

We can assess this more generally. The frequency of snake-eyes occurring is a Poisson process, so the number snake-eyes occurring before before a number of throws follows the Poisson distribution. Define p = probability of success, B = the reward, N= the number of throws rewarded and L = number of snake-eyes expected after N throws, and we know there is no fee at this casino.

To get the expected value of an event, we need to calculate the probability of the event and the reward for that event. In this case, if a throw is rewarded once, it will always be the same: the reward/number of throws rewarded:
To find out how probable multiple rewards are we need to determine L. Since L follows the Poisson distribution, its mean is the expected number of snake-eyes during N throws:
The expected value of the throw:

So the expected value of a throw is invariant: there is no strategy which will gain you more since B and p never change.

In the posted game's case, the expected value of any throw is $100* 1/100 = $1.

Please note that this is not anything original. I've adapted chapter 3.3 of Analysis of Bitcoin pooled mining reward systems (https://bitcoil.co.il/pool_analysis.pdf) to the dice game. If I've made a mistake in my analysis of the game or its reward system it is mine, not Meni's.

teukon, I just thought of an even simpler example: If the payout was paid only to the person who threw the snake eyes  - is there a winning strategy?

This is the same as the case of paying the last ten throws, with N=1 instead of 10. Only the variance changes.

iopq (and any other interested contestants): You are still calculating the reward for a player since the beginning of the game. The problem with that is although it provides information about how much a player can be expected to earn, it doesn't provide you with enough information to pinpoint a strategy. All you can do is calculate and observe trends. If you calculate the expected value of a throw, then whenever it is above 1.0 you should throw, and whenever it is below, you should not.

Calculating the expected profit as you have done will always result in a profit greater than the cost even by a tiny margin since it can only equal the cost if there are an infinite number of throws so that the reward for the game minus the cost of the game equals zero.

What I think you mean your calculations to tell us is that earlier throws are rewarded more than later throws. But you don't show us when a particular throw is worth less than the mean value of a throw, which (since you define profit as winnings minus cost) would be less than zero. This is what you need in order to determine the best strategy.

Early on, when I couldn't figure out how to simulate expected values of shares (which ended up being quite easy, simulating winnings since the start of a round was harder) I generated similar data, showing expected profit per round and then comparing that to a different expected profit per round (see HTH1 (http://hoppersden.info/entries/15-How-to-hop-part-1-Slush-s-pool.)). Have a look at how hard it is to figur out a strategy that way, and then look at HTH2 (http://hoppersden.info/entries/17-How-to-hop-part-2-More-on-score.) where there are graphs of expected values of a particular share, and it's much easier to see what the correct strategy for that 'game' is.

Hint 4: HTH7 has full instructions on how to do this.

I think you missed my point.

Firstly, I don't question your logic on the use of the Binomial distribution.  I omitted talking about it because it is not needed to reason out the expected value of a throw (I'm trying to keep things simple).  I will now expand on my thoughts and use standard mathematical notation but I still prefer my original form.

Suppose a player takes a turn and throws the dice.  Suppose also that there have been at least 9 past and at least 9 future throws.  We want to calculate the expected amount that the player will receive.

Let X_i be the expected amount the player receives from the i-th throw (where i=0 is the player's throw and i=1..9 are the 9 future throws).

We want to calculate E(X_0 + X_1 + ... + X_9).  (Where E is the expectation operator).

The X_i's are independent identically distributed Bernoulli random variables with parameter p = 1/100 (probability of success).

There are two main ways to calculate this expected value.  The first is to consider X = X_0 + ... X_9 as a random variable in it's own right.  This will be a binomial random variable (just as you describe) and you can use the known formula for the expected value of such a random variable (number of trials * probability of success; n*p).

The other way is to note that the expectation operator is linear so
E(X_0 + ... + X_9) = E(X_0) + E(X_1) + ... + E(X_9) = n*E(X_0) = n*p
Indeed, this is the main way in which the formula for the expected value of a binomial distribution is derived.  The beauty of taking the second method here is that it the expected value of a Bernoulli random variable is intuitive so formulae can be largely avoided.  I find it difficulty to express myself properly on a forum but I feel this is the elegant way to reason about this game.

The majority of my post was discussing the assumptions needed to make the mathematics rigorous.  If you make an assumption that this game extends infinitely in both directions then everything is fine but most people will assume that the game starts at some point and ends at some point.

What happens, for example, if we actually start playing this game and I get snake eyes on my first throw?  Would I recieve $100 or would I recieve only $10 (the other $90 theoretically given out to the previous 9 players).  In the latter case there is no problem but in the former case the first 10 throws give the player a positive expected profit.  Instead of being 10 * 1/10 * $1 the expected value would be (1 + 1/2 + 1/3 + ... + 1/9 + 1/10) * $1.

What happens when a game ends?  If I make the last throw of the game then surely $1 is too much to pay for only a 1/100 shot at receiving $10.

A real PPLNS pool has to start at some point and must end at some point too.  A naive PPLNS pool will screw up here, giving out high value to the initial miners and constantly borrowing from the future until, when the pool closes, the people holding the last N shares lose out.  This is a trapezoid scheme.  A carefully implemented PPLNS pool would try to avoid this, probably by creating a pool kitty which is funded by the initial miners and pays out to the final miners.  A PPLNS pool has other factors to worry about, such as changing N and changing difficulty.  Just as with starting and ending a pool, these changes need to be handled gracefully to make sure that the expected value of each share is correct.

I think it's unfair to expect more than this when the question was


It seems that people have found a winning strategy and provided sufficient justification to show that it is winning.  They may not have found the best winning strategy or justified that their strategy is the best but this is not what is asked for.  You do say the winning strategy but only at one point and you never ask for the best strategy.  I would say the 1 BTC has been earnt.

The 4 BTC on the other hand would certainly require some elegant mathematical reasoning.

It's only unfair to expect it if I'm making the reward contingent on his response. I'm not. The offer holds, and any other entries are still welcome.

All I'm doing is promoting discussion. I'm not requiring a response or a change in the entry. I apologise if I gave that impression.
Well, I'm glad you followed iopq's work too! There's a lot of interesting points there. And from your post I guess his proof is satisfactory for you? Fair enough! But I'm still not making any decisions about the competition until the deadline, midnight 19-10-2011 UTC.

Throws in any previous game are rewarded if the current game is short, ie less than 10 throws. The game ends when the dice come up snake eyes, as per my understanding of iopq's post on his game (is that correct iopq?)

So if you threw snake eyes on the first throw of a game, you'd get $10, and the last nine throwers of the previous game get $10 each. Then a new game starts. In the real world, with 24 hour casinos and no end of gamblers, I think we can assume that starting a series of games and ending a series of games would be a rare occurrence.

I hope that clears it up!

Just a bit more about your post, since you put a lot of thought into it:


I actually didn't use the binomial distribution in the post - I only mentioned that the number of snake eyes found in N throws follows a Poisson distribution.



So I calculate the expected value as p*B not n*p as you have. So either we have different meaning of expected value or one of us is wrong there! I'm ok with being wrong if you can show me why.


It's unnecessary to sum the series since the expected value for a throw in the game, p*B, consists of unchanging constants.

It's late for me here so I might not have followed you properly, so I'm looking forward to your reply.

Ok.  Most of my original post was about what happens at the beginning and end of a "series of games".  The confusion has come from my saying "game" for your "series of games" and "round" for your "game".  Certainly there is no funny business going on shortly before or after snake-eyes.


Good point, I have not been reading these posts in full detail but just trying to get a feeling for the mathematical approach taken.  Your approach really is fine if you are talking about the binomial distribution but calling this a Poisson process is technically an error.  This is a discrete process, not a continuous one.  My apologies for not reading your post thoroughly.


Ah, we're just talking about different random variables.  The expected total payout for a throw is certainly p*B.  You're right, I made an error here.

Of course, E(X_0) is 1/n*(p*B) and hence

When focusing on how the binomial distribution is a sum of Bernoulli ones it's very easy to write "E(X_i) = p" without thinking. ;)


The sum is, in my opinion, an important part of this problem.  Without it my solution would read:

Assuming there have been at least 9 previous throws and will be at least 9 future throws, the expected value of a throw is
Because it costs $1 to play the expected profit from any turn is exactly $0 and hence there is no winning strategy (possibly unless we allow ourselves throws close to the beginning or end of a series of games).

The interesting bit is in seeing why the expected value of a throw is $1.  If someone cannot see that it really is $1 then I doubt using words like "binomial" and "distribution" won't help.  Instead, I think the simplest reasoning is to consider how much you expect to get from each of the next 10 throws (including your own).  In each case you would be one of 10 people sharing an expected 1/100 * $100 = $1 reward so your expected income from the throw is $0.10.  Summing the expected incomes of all 10 of these throws yields the expected return of $1.

So reading your posts in with that in mind, I found your analysis of the game start and finish boundary problems interesting. I still have more thinking to do though. It takes a while. Mills grinding slowly but exceedingly fine etc. Well, fine-ish, anyway.


Point taken. The 'time' between snake eyes being rolled is the number of throws, not the time taken for the throws, and the number of throws to end a game is a series of Bernoulli trials. Pooled bitcoin mining would approximate a Poisson process better. But the number of snake eyes in N throws still follows a Poisson distribution. The number of throws to result in one snake eye follows a binomial distribution. I understand you realise that but I wanted to spell it out for other readers.

Yes, from what I understand atm, you couldn't show the start/finish boundary problem without summing that way. I was assuming, as you say, as many games in the past and the future as necessary to make the start and finish of a series of games irrelevant and tbh hadn't I considered the problem at all.

Well, no, but the conversation might interest people enough to do their own reading. I find that unless very well crafted, intuitive explanations can lead readers astray since the writer has to assume *some* level of knowledge on the part of the reader. If you assume to too little knowledge the reader gets bored and assume too much knowledge and the reader makes incorrect intuitive leaps. I can't find that happy medium so I try to make the math as simple as possible to follow.

Well, that was great! Thanks for persevering teukon. I'm sure I wasn't the only one to find that interesting.

Comp ends in only 3 days. Any other entrants?

I'm confused here.  I think the number of snake eyes in N throws follows a binomial distribution and the number of throws to result in one snake eye follows a geometric distribution.  Both of these distributions are built on the underlying base of independent identically distributed Bernoulli trials.  The Poisson distribution provides an approximation for the binomial distribution when n is large and p is small (and hence is an excellent choice in practice for handling bitcoin mining).


Ok.  I only brought it up because the assumption of many games in the past and future was not made in the question and did affect the answer.


I think you are wiser than I.


You're welcome.  I was briefly interested in spending some time (a full day) looking at all the reward systems mathematically, perhaps inventing one or two of my own in the process.  I discovered however that a decent body of work on this subject already exists.

Good luck with your competition!

Expected values for dicecoin - competitions answers

Question 1: is there a winning strategy for this gambling game? What is it?

Both competition entrants iopq and 3phase put a lot more work into this than I expected anyone to make! Good job both of you and I'll make some comments about your results after I give the answer.

I was actually assuming that entrants would simply try the game and see what happens, as I mentioned in one of the hints. If you had tried that you would have obtained something like the following 100 games, which took quite a while using the online dice generator I linked to:


If you weren't going to use probability theory to solve this, the first intuitive leap you had to make was that assessing one throw per game before the costs and prizes were distributed amongst the players seems much easier to assess than trying to work out a per player result (which would depend on how many players were present). If you accept this for now, I'll derive the result mathematically later.

To work out the value of the first throw, we have to find all of the games which contain one or more throws - i.e. all of them. The profit for the first throw of a game before costs and winnings are split amongst players is:
Winnings for the throw minus cost of the throw = $100/(number of throws in the game)-$10


So our average profit (when we define profit as winnings minus cost) for playing only the first throw in a game for this series of games is $15.24


To estimate the value of the second throw, we have to find all of the games which contain two or more throws -

Calculating the average profit as above results in $9.62 per game for the second throw of each game.

Keep in mind that for a constant player, the expected profit is $0 per game.

If we continue calculating the expected profits for a throw as above, we can generate the following results:

https://i.imgur.com/X1YWg.png (http://imgur.com/X1YWg)

When the expected or average value of the throw is below $0, the throw is more likely to reduce your overall winnings than increase them. So for this dataset the strategy would be to stay on for the first 5 throws. I would have accepted this as an answer. It turns out (interestingly) that when the expected values are more accurately calculated the strategy would still be a winner if the 4th throw or the 5th throw is used as the final throw.

Both iopq and 3phase came up with similar results. Although 3phase was first with he later added that any consecutive 5 throws would be a winning strategy (although I can't find that quote in the post anymore, only in the discussion between iopq & 3phase - can you confirm that for me 3phase?)

So, contingent on 3phase confirming his "any consecutive 5 throws" statement, I'm awarding iopq the huge 1btc prize! Congratulations iopq, and well done to both iopq and 3phase.

So I think that's enough for the moment. A little later I'll post a proof for the above, then a discussion of both sets of results from iopq and 3phase, and finally I explain how to calculate the expected profit from the game if you use this strategy.

iopq, please PM me with a bitcoin address to send your prize to.

I admitted I was wrong in making that statement, and edited my initial post (post #9) just after iopq's comments. See "EDIT" notes in post #13.

So I missed the prize for trying to play clever  :-[.

Anyway, I did enjoy thinking about it and reading the posts here. Thanks, organofcorti !!!

You're welcome - glad you enjoyed it. And I don't think you were trying to be clever - you were just interpreting what you that the results told you. A good attempt anyway.

Expected values for dicecoin: Answers part 2

So here I'll derive the strategy mathematically. I name all variables except number of players and cost as per Analysis of Bitcoin pooled mining reward systems (https://bitcoil.co.il/pool_analysis.pdf) to make the derivation easier to follow. A read of How to hop 7: Expected values (http://hoppersden.info/entries/24-How-to-hop-7-Expected-share-values) will also be helpful.


D = 10, the 'difficulty' of throwing a ten on a ten sided die.
probability of a winning throw, p = 1/D
probability of a losing throw, (1-p) = 1-1/D
I = throw previous to the one being assessed
Y = number of players
N = number of throws
B = total reward per game = 100
C = cost per throw = 10
winnings = 100/(N*Y)
costs = 10/Y per round

Expected profit of the first throw = probability * value

Probabilities:


if last throw = I
probability Nth after Ith throw wins
1/D*(1-1/D)^(N-I-1)

Values:

So winning value Nth throw = B/(N*(Y+1))

Costs:


So the cost value Nth throw = C/(Y+1)

Profit $ value per throw (winnings minus cost)

B/(N*(Y+1)) - C/(Y+1)
= 1/(Y+1)*(B/N-C)


Profit can also be expressed as total income/total outgoings,
eg if it costs $9 to earn $10, the percentage profit is 10/9 = 111.11%, or an 11.11% increase. Expressed as a fraction instead, 10/9 = 1.1111


This allows us to make the number of players irrelevant when determining expected fractional profit of a throw.

Expected fractional profit first throw:

1/D*(1-1/D)^(1-1)*B/C/1 + 1/D*(1-1/D)^(2-1)*B/C/2 + …..

Expected fractional profit second throw:

= 1/D*(1-1/D)^(1-1)*B/C/2 + 1/D*(1-1/D)^(2-1)*B/C/3 + …..

Expected fractional profit Nth throw:



Renaming I (the previous throw) to J for clarity and using wolfram alpha to calculate the first 5 throws:

2.55843 (http://www.wolframalpha.com/input/?i=Sum+from+J%2B1+to+infinity+%281%2FD*%281-1%2FD%29^%28N-J-1%29%2F%28N%29%29*B%2FC+where+J%3D0+and+D%3D10+and+B%3D100+and+C%3D10), 1.73159 (http://www.wolframalpha.com/input/?i=Sum+from+J%2B1+to+infinity+%281%2FD*%281-1%2FD%29^%28N-J-1%29%2F%28N%29%29*B%2FC+where+J%3D1+and+D%3D10+and+B%3D100+and+C%3D10), 1.36843 (http://www.wolframalpha.com/input/?i=Sum+from+J%2B1+to+infinity+%281%2FD*%281-1%2FD%29^%28N-J-1%29%2F%28N%29%29*B%2FC+where+J%3D2+and+D%3D10+and+B%3D100+and+C%3D10), 1.15011 (http://www.wolframalpha.com/input/?i=Sum+from+J%2B1+to+infinity+%281%2FD*%281-1%2FD%29^%28N-J-1%29%2F%28N%29%29*B%2FC+where+J%3D3+and+D%3D10+and+B%3D100+and+C%3D10), 1.00012 (http://www.wolframalpha.com/input/?i=Sum+from+J%2B1+to+infinity+%281%2FD*%281-1%2FD%29^%28N-J-1%29%2F%28N%29%29*B%2FC+where+J%3D4+and+D%3D10+and+B%3D100+and+C%3D10)

The first twenty throws in terms of fractional profit:

https://i.imgur.com/TADGR.png (http://imgur.com/TADGR)


Since the fifth throw is approximately 1.000, a strategy of leaving the game at 4 or 5 throws is equally effective. If you got free drinks per throw, then you'd be better off staying for 5 throws. If instead of drinks there were lots of other tables playing the same game, then you'd be better off leaving at 4 throws - or earlier if another game starts sooner.


I'll post an answer about the expected profits of the game later on, unless someone beats me to it or points out a mistake in my reasoning :)

the expected fractional profit does not actually tell you the correct strategy for the game with a lower number of players
this is because the fifth throw has a positive expected fractional profit, but it's a lesser EV than not throwing for the player who is playing strategically

the expected fractional profit ONLY shows the correct strategy as the number of players approaches infinity because of the effect of players gaining shares in later rounds that devaluate your winnings

Can you show me what the mistake in the derivation is?

Also, the expected fractional profit for the 5th throw is 1.0, or winnings=costs. Any value above 1.000 is profit, any below 1.000 is a loss. At 1.000 you have neither. The expected fractional profit for throw 5 is 1.00012, so it won't have a likelyhood of producing a profit unless you play thousands of games.

your non-participation changes the number of players in the game in later rounds

this affects the game differently based on how many players there are to begin with, since your shares vs. their shares scale differently

if there's two other players:

you throw first 5, they throw 10 in that time
then they throw for 5 more and get 10 shares in that time
we all have 25 shares

your share is 5/25 = 1/5 of the total prize pool for $20
you paid 1/3 of $10 five times, so $50/3 = $16.(6)

your profit is $3.33, so 1/5 on top of your original investment

if there's three other players:

you throw the first 5, they throw 15 in that time
they throw 5 more and get 15 more in that time
so total shares is 35, you get 1/7 of the prize pool or almost $14.3

you paid 1/4 of $10 five times, or $12.5
so you made about 14.3% profit or 1/7 on top of our original investment

how do you reconcile these differences under your fractional profit model? When there's a different amount of players, even when the game goes the same way, the profits are DISTRIBUTED differently
this is because the more other players there are, the more each player cuts into the strategic player's shares

so the strategic player could be compensated less than 1.0 even when the fractional is above 1.0
and in smaller games I've found this to be the case, tossing 4 is better than 5 because your fifth share is worth less than the cost

and this is for the player himself, the fractional for all players is still above 1.0, but the EV for one player != fractional for all players

thought experiment:

the game is getting really stupid now, 9 strategic players play it around the clock professionally
one player plays it fairly

he has to pay $1 on the first toss and $10 on the 6th+ toss
but he only takes ONE share per toss away from the strategic players
and they all pay $1 per round as well until they all stop tossing at 5 tosses because they read the organofcorti guide

it's super cheap for them and super expensive for the poor fair player
in fact, he ends up paying nearly half of the cost but gets only twice as many shares each strategic player, getting about ~20% of the reward

my point is:
strategic players and "it's due for a 10" players change the distribution of the payouts BETWEEN the players, so by playing the game you're changing the distribution of the payout between the players since you're a strategic player

so that's why my comment was your post outlines "the correct strategy as the number of players approaches infinity" at which point your strategic play doesn't disturb the payouts since you're an infinitesimal part of the field

this was already pointed out earlier in 3phase's post where he wrote:
"The number of players participating in the game is relatively stable and big enough so that your participation or your non participation does not make a significant difference (say number of players N=100,000)"

I did not make this assumption and wrote the EXACT EV for the strategic player assuming he was the only strategic player in the game

because a strategic player actually messes with the distribution of the payouts by his own presense, he can get away with "paying less, and receiving more"

he does this by participating in cheap rounds (rounds with many players in them) and not participating in expensive rounds (rounds with few players in them)

who cares about the EV for all players when some players pay less to receive more?

Understood - multiple players affect expected winnings. But does it change the fractional profit per strategic player, ie winnings/cost? You might make less per round, but I think the fractional profit will remain the same.

Let me think a bit more on it, I'll do a post on expected profit and see if I can get similar results to you.

the strategic player himself increases his own profits by being in the game
this effect is eliminated at high enough number of players and at sufficiently large number of players the results would be close to the fractional for all players even for the strategic player himself

New 'How to hop' post  on a simple method to calculate 'c' for a 'Slush scored' pool (http://hoppersden.info/entries/26-How-to-hop-8-Determining-Slush-and-BTCMine-s-c).

lambert_w

How is that implemented in R?

I didn't realise it when I posted How to hop 8 (http://hoppersden.info/entries/26-How-to-hop-8-Determining-Slush-and-BTCMine-s-c), but the Lambert W function in R is actually from the GNU scientific library. Anything in GNU-sl can be used on any platform that can use C and C++ since the source is available.

A good simple reference is here (http://www.gnu.org/s/gsl/manual/html_node/Lambert-W-Functions.html).

I think long time blog readers will get a kick out of this:


....which I explained way back in How to hop 4 (http://hoppersden.info/entries/19-How-to-hop-4):


Have to love it when the real world agrees with the math.

Word on the street is "c value for Coinatron is 6."  However, I expect the c value to be higher and have had good luck mining with a c value of 3000.  Have you determined a c value for Coinatron yet?  Keep up the great work!

Coinotron's score system is different from Slush's, and mine_c on bitHopper is not appropriate. I would use role:mine instead. I'll explain why at some point, but in the meantime please enjoy following chart porn, just for you:

https://i.imgur.com/Z1r2W.png (http://imgur.com/Z1r2W)

When I first published the Slush hop function in How to hop 4 (http://hoppersden.info/entries/19-How-to-hop-4) I made a mistake in not bothering to take difficulty into account, since D seemed pretty stable at the time. c00w even asked about how Slush hopping would be affected by difficulty and I lazily replied something like 'not a problem'. I wasn't expecting D to drop by a third!

So I rejigged the hop function to take current difficulty into account. I'll publish the derivation on hoppersden.info when I have time. The new function makes a significant difference (try it against the old one and see) so please pass the word.

Anyway here it is, ready to go:


'c' can be calculated (see 'How to hop 8') (http://hoppersden.info/entries/26-How-to-hop-8-Determining-Slush-and-BTCMine-s-c) if you get some score, share and time values from the pool website, 'hashrate' is the average hashrate of the pool  since start of roundin Ghps, and D is current difficulty. Finding an accurate solution that was still fairly simple took a while, so sorry for the delay.

Edit: fixed formula - brackets in wrong place. Thanks for the heads up, eveofwar

I'm giving "mine" w/penalty a try, have a suggestion on the optimal penalty?  Also, thanks for the cp...had my way with it! Ohh!

I'm afraid I've not had time to read everything you said carefully (I have to dash) but the assumption you gave here could be the cause.  I hope I've not missed the point.

The probability of any one hash (share if you like) generating a Bitcoin block is essentially fixed.  (It is changed once every 2016 blocks - approximately 2 weeks).  If you select a 10 day period shortly after a difficulty change then the various hopping strategies outlined here apply.  If you are careful you can probably profit even more when difficulty changes (and yes, some of the strategies given here may have to be tweaked to accomodate a change).  I haven't been keeping up with this thread so it's possible there are some posts on what to do at difficulty changes.

Hey Marty,

The hop point for coinotron is about 0.73*D, but you don't know if they're using c=6 or not and if you stayed until 0.73*D you'd lose efficiency. The other downside is that until around 0.38*D you wouldn't want to be there if you had a prop pool. Until hopper software can incorporate hopping efficiency function (discussed in How to hop 4 (http://hoppersden.info/entries/19-How-to-hop-4), I'd just treat it like a proportional pool if you really want to hop it.

Your best bet though is to compare your shares submitted per round to your reward. You can work backward to find out if your reward is consistent with a normal proportional pool or not. If they aren't using C=6, then there's nothing to worry about at all. If they are, you can use a penalty of 0.6.

Good luck!

Thanks for your interest, catfish. I am absolutely certain that pool hopping works. I was even before I understood the probability behind it, by using mining simulations. How to hop 5 (http://hoppersden.info/entries/20-How-to-hop-5-Back-to-basics) gives some examples of this sort, and How to hop 6 (http://hoppersden.info/entries/25-How-to-hop-6-Basic-probability-for-bitcoin-miners) derives the expected value for a share. Having studied probability yourself I encourage you to read through these posts which I hope will help explain why the expected value of a share varies.

When I discuss pools in this reply I am only referring to pools with a standard proportional payout although some information is standard for all pools.

But bitcoin mining *is* like coin tossing, even in one pool. You make the statement that bitcoin mining probabilities do not follow a geometric distribution but I'd like to know why you think that. Maybe you're confusing shares with hashes? Each share  is a hash of difficulty 1, and so has a probability of 1/D of solving a block. A series of events each which have the same probability of ending a trial is a standard bernoulli trial.
A pool with a hashrate of ten times another pool will solve blocks ten times more quickly, on average, because it is accumulating shares ten times more quickly. The variance you mention is related to the time taken to solve a block, not to the number of shares taken to solve it. Over a large enough series of rounds, the share variance at a small pool is the same as at a large pool, only  it takes more time for the mean and variance to settle.
Why is frequent hopping helpful? No, just the time based variance[/quote], which is also affected by pool-hoppers moving, then simplified models become less accurate.

I've seen far too much of this in quantitative finance - a model that works very well with the nice little line 'assume that P (or whatever) is invariant' fails big-style when P turns out *not* to be invariant, but volatile as hell. Isn't that JUST as relevant here?

It seems to me that the entire pool-hopping 'strategy' relies on exploiting variance in small-to-medium sized pools. The largest pools must be getting towards the law of large numbers by now, surely?[/quote] To quote Starlightbreaker - "hop all the pools!". In fact because the time based variance of small pools is so large, they are not preferable. The larger the pool, the more constant the hopping profit. Even if this sort of variance was useful to a pool hopper, one round's variance is not reliant on previous rounds so that a maximum in average variance doesn't predict variance in the next round
Great questions, catfish! It took me a lot of reading to get up to speed. The best place to start is Analysis of bitcoin pooled mining reward systems (https://bitcoil.co.il/pool_analysis.pdf). Another thing you could do is collect a hundred or so block lengths (deepbit publishes theirs) and do some calculations for yourself. At the minimum you could generate a histogram to show you that the block lengths are distributed according to a geometric probability distribution. If you can prove that to yourself, everything else should follow.

The dependence on other pools is done only via difficulty retargeting, which happens once every two weeks. In between difficulty adjustments, each pool really is its own completely independent Poisson process.

Pool-hopping works by maximizing your gain for every share. Your gain per share in a proportional pool depends only on the eventual number of shares in the round, which is completely independent of any temporal considerations (such as the pool's hashrate) - only on the fixed probability of every share to be a valid block and end the round. The less shares in a round, the more you gain per share, so you want to submit to pools with the least shares in the current round.

You mean it doesn't now? How... uninspired.

One way to test if a list of empirical values were generated from a specific distribution is by comparing moments (http://en.wikipedia.org/wiki/Moment_%28mathematics%29). If you take each round length and divide it by the difficulty at the time, you'll get values supposed to be distributed exponentially (http://en.wikipedia.org/wiki/Exponential_distribution) with mean 1. So the average nth power of the values should be n!. But you need quite a lot of observations to be accurate, more so for the higher moments - with 100 samples, even the second moment will be a bit off.

Here's a little something to help you commemorate/celebrate the approaching end of the proportional payout system while I find time to finish my next blog post.

In first two charts you'll find everything you need to figure out how much you gained/lost while you hopped/mined. The second two are an illustration of PPLNS payout systems, the first with N=1 and the second with N=3.

https://i.imgur.com/NOcyi.png (http://imgur.com/NOcyi)

https://i.imgur.com/FWLTL.png (http://imgur.com/FWLTL)

https://i.imgur.com/6p9SJ.png (http://imgur.com/6p9SJ)

https://i.imgur.com/OzBXK.png (http://imgur.com/OzBXK)

lol organofcorti, pretty explanatory yeah, nice graphs man

Care to make a graph which compares standard prop with score type payouts and simulates intermittent disconnects from the pool ?

Can't seem to find a worthwhile explanation or graph around interwebs. If you have the ability so simulate score payouts over a 200 or more, rounds, normal and intermittent connection, to make a good average would be great.

Yes, I didn't think simulate out potential losses if a hopping efficiency function isn't used, and hopperware creators and maintainers are only going to introduce significant changes if there's a good enough reason or enough people ask for them.

I think I'll have to write and run a simulation now that there are fewer proportional pools and the chance of hopping to a hoppable scored with a lower expected share value (and therefore reduced efficiency) is greater.

BTW, thanks for your help on hopper v fulltimer potential earnings question. I think the charts turned out ok.

Hey paraipan,

You handle's getting shorter, I see. I guess it must be more efficient that way?  ;D No? Not even a chuckle? Sigh.

Anyway your proposal sounds like a good project. I'll need to know a bit more:

• Which type of score payout? I'm assuming Slush's?
• How much does the intermittent connection affect share submission? How long would there be no share submission as a proportion of round length, and what would the reduction in average hashrate be?

To be honest I don't understand what the first two charts are saying.

yeah it's true bout my nick haha, thanks for considering my proposal organof
adding missing data:

- slush score would be a good example and easy for all to understand, yes
- the problems will cut share submission and work requests completely.

The graph should contain reference score just like you simulated before and it's equivalent containing real world parameter, miner pool connection, that adds to pool variance as a whole. You take the reference point, can be 1-5 minutes every hour, 1 hour every day or 1 day every month, because it depends on the time frame you choose to sample.

Thanks again for providing this kind of resources to the community, i'm sure some donations will come your way soon and be able to do even more stuff.

Maybe not so ok, then  :-\

The first chart shows how the round payout for the hoppers as a group and the fulltime miners as a group changes before and after the hoopers leave, as a function of the hashrate increase due to hoppers adding hashrate to a pool. So it shows the portion of the round reward that leaves the pool with the pool hoppers (over and above what they would have been paid with a fair payout system), on average.

The second chart shows the (expected pool hopper payout)/(fair payout) compared with (expected fulltime miner payout)/(fair payout), again as a  function of the hashrate increase due to hoppers.
 

Ok, I get it now.

I've completed the simulation, and it works well until I try to compare Slush to proportional - for some reason Slush comes out ahead in payouts by 0.7% consistently. Once I either find the source of the error or find out why it's not an error I'll post the results.

I wouldn't be surprised if it's a real result caused by self-hashrate-hopping. As you recall, in temporal pools it is an advantage to mine when the hashrate is higher. When you disconnect from the pool its hashrate is reduced, so conversely, you mine when the hashrate is higher.

I haven't quantified this effect, and AFAIK it could just as easily have the opposite effect by expediting decay of share submitted before disconnecting. I'll try to look into it.

nice to hear that, take your time though

@Meni Rosenfeld, awesome, some interesting results should come i'm sure

Ok, I've got some results, though I haven't spent enough time on this to be sure they're correct. Doing this for slush's method is complicated, so I've done this for PPLNM (the temporal version of PPLNS). Wlog assume that the window is 1 time unit. We have a miner with hashrate H2 mining intermittently for a pool which, besides him, has a constant hashrate H1. Once in a while he starts mining for some time and then disconnects. We will denote H = H2/H1. His efficiency in the first time unit he joins is
 (H (2 + 3 H) - 2 (1 + H) Log[1 + H])/(2 H^2)
And his efficiency in the last time unit before he disconnects is
 1/2 + 1/H + Log[1/(1 + H)]/H^2
So his average efficiency in these two time units is
 (Log[1/(1 + H)] + (1 + H) (2 H - Log[1 + H]))/(2 H^2)
This is always less than 1 so he earns less than normal. It achieves a minimum of 94.8064% at H=3.47669. As H->Infinity the efficiency approaches 1. For H~0 the efficiency is (1-H/12). This is only for the 2 time units spent in the beginning and end of each connected session; the rest of the time the efficiency is 1.

slush's method is a little different but I'm no longer confident it could create a positive effect.

I'd like to remind everyone that this happens only in temporal pools. Hopping-proof methods like unit-PPLNS and DGM are immune to the effect. slush's method is temporal which is one of its two problems, but since it's so big you likely won't see the effect - if you're mining at 1GH/s you'll only have 0.008% (1 part in 12000) reduction in the worst case (with the reasonable assumption that the numbers for slush and PPLNM are similar).

Edit: Fixed a critical error.

Thank you kindly for that, Meni - very quick. I hope that the analysis makes it into AoBpmrs (https://bitcoil.co.il/pool_analysis.pdf), although I can't see it becoming a problem unless someone develops that exahash farm  ;D Or hopping tiny PPLNS-H pool comes into vogue. So there's one answer for you, paraipan!

If my following excuses about the errors I had in my last simulator attempt are not interesting for you, please go to the Results so far: paragraph.

So I had some errors in my last attempt at a simulation (which showed that 0.7% increase in efficiency for non-intermittent fulltime miners). For the intermittent miner, that increase was more like 1%. I think I've fixed these particular errors:

1. I was trying to make the simulator as efficient as possible and I was using some old techniques to do this. One of them was to assume all miners submitted shares evenly each time period (say every second). I changed this to a different and much less efficient method using Poisson random variables to determine when and how many of each share would be received by the pool and the error disappeared. I really don't know why.

2. Because of the original naive method of simulating Slush's pool I used a simple method of creating 'random' periods of downtime which happened to slightly favour the latter parts of a round. This made the miner a hopper, and made the increase in efficiency about 1%, which is clearly wrong. In my new method I treat the rounds as a very long string of share submissions and overlay random periods of downtime for the fulltime miner under investigation.

Variables: For the non-intermittent fulltime miner I've used 1Ghps hash generation rate with a 1000Ghps pool, making a hashrate ratio of 0.001. For the intermittent miner downtime is 0.05% with a string of as many downtimes as there are rounds. The downtimes also appear at times based on a uniform random variable because I simply don't have enough information to decide on a different probability distribution. The downtimes are exactly D*0.05 long, giving an efective hashrate of 0.95Ghps for the intermittent miner when averaged over many rounds - but this can vary significantly by round, especially on shorter rounds - no downtime on some short rounds and completely preventing submission during other short rounds. Longer rounds are affected by this variability less.

Results so far: I'm finding that for an intermittent miner the Slush scored payouts are an average of about 99.9% of the proportional pool payout, although I have a thousand or so rounds to run in total with only 400 completed so that figure may change. It is significantly worse than Meni's estimate for an intermittent miner in a PPLNS-H pool. I don't know if this reflects irl results, but it isn't a large enough difference to make a significant difference to the charts.

Possible modifications: I still have a few tricks up my sleeve if necessary - I'd like to model the downtime onsets as a Poisson random variable with an estimated arrival time of once per round (I could be quite wrong with this oversimplification, but ignoring external factors I guess that the probability of downtime per unit time is constant - very wrong if external factors like brownouts due to excessive power usage at certain times of day are to blame for the downtimes). Unfortunately generating and managing long strings of numbers slows things down significantly so I wont be doing this unless I have to. I could also model the length of downtimes as a uniform random variable which creates downtimes of 0 - 10%, but again I don't know whether this models the irl downtimes.

I'll post the charts when I have the thousand rounds worth of data completed and the charts prettified.

Requests Anyone want to see something specific from the data? Make your requests in a form I can generate charts from, eg 'Comparison of payout for Slush intermittent miner compared to prop pool intermittent miner as a function of round length' or 'contour plot of intermittent payout/proportional payout as a function of change in miner hashrate  and round length'. etc. If like the latter example your request requires new data, be patient - this is a slow beast.

Thanks again Meni for your rapid analysis of the intermittent miner on a PPLNS-H pool - interesting as always, plus having someone else's (trusted) results makes working out if and where there might be errors in a simulation much easier.

Edit: I just realised that the variance over as few as a thousand rounds would probably mask the tiny reductions in payout as described by Meni.

Well, seeing as my results before the edit were completely nonsensical, maybe they shouldn't be trusted too much :). In my defense I did disclaim I hadn't taken the time to verify this properly.

Yeah, I doubt you'll be able to simulate properly such small differences. Also maybe there's a difference between slush and PPLNM, and maybe there are additional discrepancies in the scenarios we've looked at.

thank you both for working on this, @meni hope you appreciate the small donation a sent you for your time, in Europe that buys you a latte ;). I hope in the future you will try figuring out more things related to score type of payouts under real world production environments.

@organof, until now this seems to be an interesting project to graph and thanks again for starting the "ball rolling".
We only had theoretical figures on every payout system, so this small experiment should make us an idea on the subject and free us from the burden of testing it in a real mining rig for the time being.
I know that miners have to take into account 3 main parameters when choosing their mining profile: self mining efficiency (under miner control), Internet and power connectivity (not always under control), pool variance (pool speed and popularity are two factors that go hand in hand to affect it). Those would be the main variables that depend on lots of sub-parameters on their own. I supposed that any change in one of the three affects payouts some way and preliminary results you and meni posted seem to go that direction too.
Hope you show us some nice comparing graphs soon and help us get more educated in the process  :D

Thanks, much appreciated!

My curse is that I know what's important and what's not. What we've done here is a nice exercise but it's not important, because A) the effect is tiny and B) This only happens in temporal methods like slush's pool. I don't like it when slush's pool is subject to false criticism but I never recommended using his method, it has several problems and it's known that this is one of them. This simply cannot happen in hopping-proof methods where the average reward really is equal to the total worth of work submitted regardless of pattern. (Though I'm not talking about things like stale shares, invalid blocks, pool downtime etc. which have nothing to do with the reward system.) The geometric method is what slush's method would have looked like if it was done properly.

So, here are the first few results. Look first, description after.

https://i.imgur.com/IIKVW.png (http://imgur.com/IIKVW)

https://i.imgur.com/EAE8Y.png (http://imgur.com/EAE8Y)

https://i.imgur.com/RcVtv.png (http://imgur.com/RcVtv)

https://i.imgur.com/XnsK1.png (http://imgur.com/XnsK1)

https://i.imgur.com/76sUY.png (http://imgur.com/76sUY)


Before I start, the mean payout for the intermittent  Slush miner was 0.0074% more than for the intermittent prop pool miner, and the mean payout for the non-intermittent Slush miner was actually 0.01164% less than for the non-intermittent prop miner. I think we can ignore these values given the variance involved.

The first two charts show the amount earned by an intermittent miner at a proportional pool (green) and the exact same share submissions at a Slush scored pool. The first chart shows results for one hundred rounds, the second chart are results for twelve hundred rounds. You can see clearly that the results in both cases are centred near the expected 0.0475 btc. However the scored payout shows a lot more variance.

The third chart shows the proportional payout minus the Slush payout for non intermittent miners. It has a fair amount of variance but doesn't seem skewed to either above or below expected, meaning that median and mean are similar, and we don't have a large amount of small increases one way and a few very large ones the other way to 'balance' it.

The fourth chart shows the proportional payout minus the Slush payout for non intermittent miners. There is skew in the data, with lots of small negative differences (where the Slush scored pool pays better than proportional) and a few very large positive differences (where the slush scored pool pays significantly worse). I think the density plot below that illustrates this point well.

Statistics:

Non-intermittent, Prop payout per round minus Slush payout per round
median: -0.0000470
mean:    0.0000058
sd:         0.0036246

Intermittent, Prop payout per round minus Slush payout per round
median: -0.0006029
mean:    -0.0000035
sd:         0.0061706

Summary:

In the long run and with the parameters previously mentioned, being an intermittent miner on a Slush scored pool is not significantly different from being an intermittent miner on a proportional pool. In the short term, a comparison between the non-intermittent and intermittent groups shows significantly increased variance for the prop minus Slush intermittent group as compared to the non-intermittent group, with some slight skew - which may not be significant given the variance in the data.

Edit: Fixed an error in mean intermittent prop minus Slush payout. Value should be -0.0000035 not 0.0000035.

awesome work organof, just managed to pull a few great conclusions based on your data, hope others will too. I'm pretty sure i will be making better mining decisions from now on.
Sent you a tip, not much but expect more in the future because i will be closely watching your work.

Well, thanks for that, paraipan! Your donation is much appreciated.

What I got from the simulation was (if you're a fulltime 1Ghps miner with 5% downtime) not to allow a few worse payouts than expected change your mind about mining at Slush's pool since this is offset by more regular and less noticeable better than proportional payments. The hoppable score system is something that should make you change your mind though.

Since you were kind enough to donate I rewrote the the simulation to allow for a changing hashrate and changing downtimes. I'll post a contour plot and a 3D perspective graph of the results when it's done. It will take a few days, I expect.

While I'm working on this simulator, any other requests? Keep in mind this simulator only includes variables which are important for the payout system. It doesn't include frequency of getwork requests, mining software variables, etc - just frequency of share submission, frequency of downtime, and the payout.

PPLNS systems, as long as they cross rounds (which all do, there is no concept of pool rounds when distributing payments) are all fair payout methods that do not positively or negatively affect the part-time miner. Since the work you submit now determines your percentage of reward on future blocks until the work expires, you don't know when blocks will be found, and past block finding doesn't affect future payments, all contributed shares have equal expected value.

I think it may be possible to game 'decaying' value pools or get a different average reward than you deserve when part-time mining, which is non-ideal. Lets say you have three different accounts on one pool, and switch between accounts every hour. It would seem that under an exponentially decaying reward or other custom poorly-informed formula (don't know if any pools do this) your expected reward may be different than constantly mining one account. Just thinking that 'pulsing' your hashrate (intermittent mining), may get you more or less expected reward than constant mining, depending on the decay rate, when we want every submitted share to have the same expected return.

Upon reflection, it seems like the second paragraph's concern is also unfounded. As long as each share's value is independently evaluated, it shouldn't make a difference. If a pool has some other policy, like "if you leave for three hours your reward is cut in half", this would "connect" the value of shares you submit now to future shares you submit.

PPLNS isn't the only hopping-proof method. As you can see in section "general unit-based framework" of AoBpmrs (https://bitcoil.co.il/pool_analysis.pdf), a hopping-proof method can either cross rounds, include a variable fee, or both, and have either exponential, step, or any other decay. Exponential decay is far from poorly-informed - it is the only decay that allows encoding the score with a single value.

The problems with slush's method aren't that it's exponential - it's that it's temporal, and that it has neither round crossing nor variable fee.

Yes.  The goal of many of the reward systems is to ensure that each submitted share has the same expected value.  PPLNS does this (unless carelessly implemented), PPS does this (this too can be implemented in a way that is technically hoppable thanks to the transaction fee reward), and Geom does this.  As far as I understand it, DGM simply interpolates between PPLNS and Geom is a spectrum of different non-hoppable reward systems ranging from PPLNS to Geom and, consequently, takes an additional parameter.  If a reward system has this property and pays all rewards out in a timely manner then it simply cannot be hopped (for the time issue, compare DGM to SMPPS).

The interesting aspect is that, for a fixed difficulty and hashrate, the number of blocks generated in a certain period is very well modelled by the Poisson distribution (equivalently, the time until the next block is found is very well modelled by the exponential distribution).  Consequently there is a natural "decay", not built into Bitcoin by design, but simply a mathematical phenomenon.  If you just design a reward system with shares decaying in value at some random rate you prescribe then most likely the pool will be hoppable.  The decay must exactly match that required by the mathematics.  This is why the proportional reward system is hoppable; the decay is not the same as that required by the mathematics.  Nonsense

That's not what it does. It's on a spectrum that has exponential-PPLNS on one end and Geom on the other, but it doesn't just pay out a convex combination of the respective rewards.

That's not really it. You can use any decay function (and linear decay gives the best variance/maturity tradeoff). But you must maintain a steady state with some combination of round crossing and correctly tuned variable fee. Suppose you take the geometric method, in which the operator's score is specified as 1/(r-1). If you choose to make the score any less, you incentivize mining in young rounds; if you make it any higher, you incentivize mining in old rounds; only with this exact score the profitability is always the same.

There's nothing wrong with the decay in proportional. It's equivalent to exponential decay with r=1. If you do this with infinite score fee and correspondingly infinite negative fixed fee, you get PPS which is hopping-proof. The problem is that people try to use it with 0 score fee.

My apologies, I had to dash while I was composing this post and didn't have time to read it.  By "interpolate" I didn't mean to suggest any particular mathematical way of calculating payouts but rather just meant to suggest that by varying one of the parameters you would obtain a continuum of reward systems from PPLNS to Geom.  I admit this was a poor choice of word but couldn't think of anything better at the time.  Spectrum is a good word for this.

As for the "decay" part I was being particularly dense when I wrote this and I'm sorry for any confusion caused (I'll edit my earlier post if I can).  I somehow managed to get the idea in my head that it would be possible to have a non-hoppable reward system where for each block the full reward is paid out according to the shares submitted in that round.  I was talking about the "decay" in value such a share submitted to such a pool must experience before the end of the round (and thought it would exist and be some kind of exponential decay).  Of course, the only reward system that satisfies these two properties is PPLNS with N=1.  I was flatly wrong, "That's not really it" was just kindness ;).

After a quick read of your initial post about the Geometric method I see what you are saying about Prop and PPS.

May I ask what you do for a living Meni?

Yeah, that's what I call "the hopping immunity theorem". I'll add a proof in AoBpmrs as soon as I determine the most general conditions under which I am able to prove it.

A bit off-topic isn't it? ;)

I used to be an algorithm researcher in a small internet startup. I recently moved to a 20%-time position there so I can focus on Bitcoil (https://bitcoil.co.il).


This, by the way, is my 1000th post.

Good.  The simple form of the theorem that is suggested by the two conditions I gave is easy to prove but it would be nice to say something more along the lines of "If X is a hop-proof pool then there must exist a function f and ...".  This shouldn't be tough (kind of fun really) but as I said a while back I've not done any of the maths for pooled mining and instead am enjoying just going with rough intuition (which frequently leads to my making false assertions but that's fine).  Good luck with this, not that you'll need it.


If you've been following my posts you'll know I'm a fan of "off-topic".


Congrats!  It's a shame you don't get higher status than "Hero Member".

Want to try your hand at simulating pooled bitcoin mining? How to hop 9: Simulating miner earnings (http://hoppersden.info/entries/27-How-to-hop-9-Simulating-miner-earnings)

I explain how to generate random variables and provide a step by step example of what to do with them. Feel free to ask any questions you might have.

Round length follows a geometric distribution starting at 1. So to generate a sample accurately, you should use 1+round(ln(U)/(ln(1-1/D))) (assuming "round" rounds down). For an approximation that works well for large D you can simply use round(-D*ln(U)).

Thanks Meni - I'd forgotten to include the '1+' so you just saved blog readers who might want to simulate very large numbers of rounds from NAN-ville  ;)

Also, the simplified version was great. I know I've seen that approximation somewhere, but how do you derive the I should probably know this!

I just realised that hardly any of the blog readers so far have accessed the extra charts for the post or the scripts I linked to, so I encourage everyone who might want to try their hand at simulating pooled mining earning to check them out:

'How to hop 9' album on imgur.com (http://imgur.com/a/UKMfB)
Poisson random number generator (http://pastebin.com/9TX4mKDJ)
Mining simulator pseudo-code (http://pastebin.com/eJKjVtLj)
Mining simulator (http://pastebin.com/JvMBPrXu)

Also, if you want to generate geomterically distributed random numbers you approximate it (and compound the inaccuracies, but oh well) back-asswards using a Poisson distributed RNG:


This is inaccurate (since the number generated ending the round could be > 1, and any inaccuracies in the Poisson RNG will be compounded), very inefficient and I guess not very interesting. But it is how I generated geometrically distributed random numbers for my first simulator and before I knew better! I'd better thank Meni for that, too.

From the Taylor series (http://en.wikipedia.org/wiki/Taylor_series) of ln(1+x) You know that for x~0 you have ln(1+x)=x+O(x^2). So for large D you have 1/D ~ 0 and so ln(1-1/D) ~ -1/D and ln(U)/ln(1-1/D) ~ ln(U)/(-1/D) = -D*ln(U).

If you don't know the Taylor series of ln you can simply use the fact that the derivative of ln at 1 is 1. Or you could use exp(x) ~ 1+x and take logs of both sides.

That's it - tickles a vague memory from somewhere. Cheers for that.

Some hopper news: looks like I predicted the end of proportional pools too soon:

https://bitcointalk.org/index.php?topic=52403.msg625380#msg625380

Are PPLNS pools hoppable by selecting the backup pool with the highest pool share count?

No. The distribution of round length is memoryless, so having a high share count does not make it any more likely that a block will be found. The result is that a properly implemented PPLNS pool is hopping-proof - the expected payout per share is always the same no matter when it is submitted.

Come check out http://www.tntmining.com, we are a 0% proportional pool which means we are pool hop friendly. 

well, not so fast...he switched to PPLNS...

This is just inane. First he spams his pool everywhere saying he deliberately wants to be hopped. Then he switches to PPLNS?

I was contributing 20% of their overall hash rate and it happened...  It was, in fact, very lame.

Bait and switch, mid round. Can't think of any other way to interpret it.

Has BTCmine or Slush changed their scoring?  Results have been down lately on BTCmine, or is it just me? ;)

If they have, I'm not aware of it. Keep in mind though, if they haven't changed their 'c' value, at low hashrates your payouts will vary significantly, apart from the usual pool based variance.

Im a bit late to the party but I just picked up on this thread and figured to respond.

This "suppose calculation" makes absolutely no sense. This assumes there is 1mh non-hopper for every 1mh hopper which is absurd to think that its so linear and even if there were 1 to 1 correlation and you expect hoppers to average out at 175% efficiency and non-hoppers to drop down to 75%, please tell me how you figured in your maths where the other magical 50% gain of the hopper would come from ?

Simply put, the gains expressed here does not add up and in the real hopping world does not at all materialise.

Raolo paper: http://bitcoin.atspace.com/poolcheating.pdf

The pool hopper, by simply hopping one pool (hopping off to PPS mining after 43% of difficulty shares) will earn 28% more. Note that this means the hopper spends more of his time PPS mining than mining on the proportional pool - the pool hopper earns his expected reward while backup mining, but earns significantly more than +28% per share while exploiting the pool, for a total earnings 28% higher. Leaving the pool even earlier (if you have many pools to hop) means the per-share reward of the miner in the exploited pool is even higher.

As a proof-of-concept, I submitted just a few shares to a pool at the very start of each round, quitting after 5% of difficulty. My shares on average were worth 4x more than expected.

The more hoppers there are, the less full-time miners will be able to submit shares into the profitable early window where a lucky block might be found. Enough hoppers on the pool, and full-time mining approaches the opposite of pool hopping, hardly submitting any shares before 43%, only able to submit after 43% of difficulty until the round ends.

If you need anecdotal evidence of full-time miner losses at a 2 hoppers per 1 fulltime miner proportional pool: https://bitcointalk.org/index.php?topic=10121.msg656033#msg656033 - and that is even with a minor anti-hop measure, delayed stats.

Hi Clipse, glad to have your input.
There is no 'suppose' at all - just a simple simulation repeated many times resulting in expected (or average) earnings. Actually, I did use a few supposes: 'suppose there's no lag', 'suppose your hopperware gets you there at the very start of a round, not after the round start has been announced', 'suppose you don't get stales', suppose your internet doesn't ever go down' etc. I left these out of the simulation on purpose.


No, it doesn't. If you look at the x axis, you'll see clearly labelled "1x  2x  3x' etc. This is the total pool hashrate increase due to pool hoppers. So the x axis starts at 'no hopper increase' and goes up from there. I've seen pools go from 50Ghps to 250Ghps and back due to pool hoppers, so '5x' is not unreasonable. I included '20x' to show what would happen to a 10Ghps pool that was hopped by the same amount since I was asked that very question.


What magical gain? Using 'bitHopper' I have had efficiencies of 150 to 250% per pool per round, averaging to around 160% long term for most pools (except deepbit which averaged to about 140%). I haven't hopped for a while but I can't see why it would be lower now.



I'm not following. My own experiences show an average efficiency per pool per round approaching what's shown in the graph. What magical 50% are you talking about? Poolhoppers will *always* approach ~175% or thereabouts in terms of efficiency: (what they earned per prop pool per round) /(what no fee PPS would earn them per round). What full time miners will earn depends on how many hoppers there are.

The graph above the one you quote give results in terms of BTC:

Now if I haven't convinced you and you can read R code, I'll post the simulation - I'd be happy for you to do some code error checking.

And good to cross swords with you once more, deepceleron!


Meni Rosenfeld's "Analysis of Bitcoin Pooled Mining Reward Systems" (https://bitcoil.co.il/pool_analysis.pdf) is more general has more detail and information. It should be considered a starting point when considering any payment system.
In the charts I'm only considering results per prop pool per round and not including PPS fallback.
Nicely said.

The following is a response to simc, a full time miner at slush's pool:

https://bitcointalk.org/index.php?topic=1976.msg728345#msg728345

It started to get long (especially with chartage) so I decided to put it here instead. Look a few posts up from the one I linked to if you want context.

Thank you for the data, simc. As for the number of shares from the score, integrate the score formula and make shares the subject. Wolframalpha can help if you're not sure how to.

The first chart shows a clear peak in pool hashrate for rounds about 274000 shares total, after which there is a gradual decline in average hashrate. The trend is fairly clear even with this very limited dataset. This is interesting since that's about the current hop point, which can be calculated as follows:


and making D=1300000, hashrate=1600 and c=300, we get an estimated hop point of 0.16*D which rises to 0.18*D at 1900Ghps. This is close to the 0.21*D that 274000 represents, so this gradual increase is probably due to hoppers - many will miss the start, and other proportional pools may be available instead, but the decline afterward and the ramp before are, to me at least, very likely accurate or at least close. The ramp and decline are also gradual because we are dealing with the average hashrate for the round, not the hashrate at the time.

The other two graphs show your earnings per round against pool hashrate and total round shares. There do seem to be some trends there, however.

https://i.imgur.com/i2H1X.png (http://imgur.com/i2H1X)

ANOVA of the linear model:
with coefficients:
gives p<0.0001, so it seems possible that (for your data set) the your reward will increase with increasing round length:

Similar analysis of
and
resulted in p>0.05 so with this limited dataset I'm not willing to accept either of these relationships as probable.

In summary, simc's data shows:
1. A probable hopper effect of about 36% increase in round average hashrate by about 0.21*D
2. A probable positive relationship between reward and round length, meaning that for the rounds under 3 600 000 shares on this particular day, total shorter rounds tend to reward less.
3. No relationship of significance between simc's reward and total pool hashrate. This is a bit odd since an increase in pool hashrate implies shorter rounds and less reward per round. Since slush uses a score method for payment and it's late here, I'm not going to work out the p value for that relationship with this data.

Keep in mind all this is based on minimal data, and I estimate I'd need a few weeks worth of a single miners data to have results worth making decisions on.

Nice stuff. I like the quality of these posts a lot.

This peak makes no sense. Either hoppers are behaving in a very weird way, or the apparent climb to ~270000 shares is the result of sampling error.

There's going to be some lag for hoppers to join due to the nature of the hopper software but (going from distant memory) it usually wasn't more than about 5000 shares missed at a similar pool hashrate.

But I agree, the peak is probably an effect of having a tiny sample from a pool that has a score system that increases variance. As well, if hoppers miss the start of a few short rounds (because a prop pool has a more rewarding total round shares) in this dataset, then you'd see this sort of peak. I would think with a bit more data the hashrate would be less a peak and more a plateau.

What was interesting to me though was that the pool hashrate started to drop at the total round shares you would expected it to if the increase was due to hoppers.

So Goat finally confessed to running a pool hopping pool (https://bitcointalk.org/index.php?topic=63192.msg739103#msg739103), like the "multipool" of old, or the bitHopper proxy. I'm interested to see the lack of blowback from prop pool miners

This sort of pool might explain explain the recent increase in pool hopping. For example look at the hashrate and worker spikes in the weekly hashrate of this popular proportional pool:

https://i.imgur.com/8emzA.png (http://imgur.com/8emzA)
https://i.imgur.com/3RLJA.png (http://imgur.com/3RLJA)

The first thing to note is that I'm assuming the hop increase coincides with the start of a round. The round starts reported by the pool look to be about when the spikes are on the graph, but I can't be sure they tally exactly. The have in the past, so I'm assuming the hashrate spikes are at the start of a round.

Next, notice that total pool hashrate increases by 2x to 7x (the greater increase yesterday). Use these (https://bitcointalk.org/index.php?topic=47411.msg614637#msg614637) charts to work out how much the full time miners are losing from this pool alone.

It's a bit disconcerting to realise that even big pools can be affected in this way. In the heyday of individual pool hopping, the expected hop boost was in the order of 200-300Ghps. From the (very small) dataset this pool provides it's around 500Ghps, and earlier today hit 1500Ghps. The 500 Ghps tallies well with slush's data (provided by simc).

This hashrate graph from July 2011 shows about 150Ghps hopper hashrate increase:

http://img19.imageshack.us/img19/8510/breyvzd2lp0day.png

Finally, these sort of charts used to show a large increase in workers with the hashrate increase. Now, you'll notice a minimal worker increase. That means that either all hoppers have a much higher hashrate than full timeminers, or a number of pools are using pool hopping to augment their mining.

Take away message: being on a mid size proportional pool is not even semi-protection against poolhopping - not when hoppers are submitting a Thps or so. With's Goat's expose I expect more hopping pools to be created. It's really time to leave prop pools now.

Bitclockers.com are faking round lengths, and many miners - those who stay for only the early part of a round, for example - are being underpaid. Check out more detail  here (http://hoppersden.info/entries/28-How-to-hop-10-Bitclockers.com-amp-spurious-round-lengths-part-1). More details about how and why they're faking their round length data in upcoming posts.

              https://i.imgur.com/qFDF2l.png (http://imgur.com/qFDF2)

I expect a shitfight over this so comments are welcome, especially from backburn.

Yes, I thought you might find it useful.

In other words, they have a reward system which is some sort of interpolation between proportional and PPS (perhaps with weighting affected by their estimate of hopping level in each round), but instead of being open about it, they fake stats.

I find it troubling that such egregious falsification has gone unnoticed for so long. If they had added 2% fake shares to every round to collect a hidden fee, would it be spotted quickly? Perhaps the "stats hunters" pay more attention to the distribution's expectation than its variance?

And finally, WHY? Their system either greatly increases their own risk, or required some nontrivial control mechanism. Why can't they use a hopping-proof method that just works, probably has similar long-term characteristics, and allows them to be honest about what they are doing? Were they bitten by a hopping-proof method as a child?

It's a geometric to loglogistic transform:
round length -> geometric cdf -> loglogistic quantile function -> loglogistic 'round length'
More details will be posted on hoppersden as I finish the charts.

Their system is like a score system, but on the round length itself. It would be quite clever, except they didn't tell anyone, and there have been far better options for months - There were far better options at the time.
It took a while for me to figure out what was going on, and I knew there was a problem as early as September or October last year. I was waiting for more round to increase the data set and then got side  tracked.


Because (assuming they have no ethical qualms about doing it) they get the best of both worlds - on one hand hoppers get lower profits, fulltime miners lose less to hoppers, and on the other people who 'love proportional pools' can mine there thinking they're getting the full proportional experience, and the hopper boost stays to help finish rounds.

Bitclockers.com are:
a) faking round lengths
b) faking round starts and not owning up to blocks

Which leads me to think they must be happy there are no bitcoin police or there would be a lot of angry miners they'd have to pay extra to.

Quite possibly a rabid one.

c) underclocking hoppers and miners' earnings from time to time

I think a) covers that. I'm pretty sure that's all of the payout weirdness with them, unless you know of something else?

How to hop 11 (http://hoppersden.info/entries/29-How-to-hop-11-Bitclockers.com-amp-spurious-round-lengths-part-2) with more on how Bitclockers.com have been paying some miners more at the expense of others.

https://i.imgur.com/NLYVK.png (http://imgur.com/NLYVK)

How do you know this? That the reported lengths follows a log-logistic distribution doesn't mean they're just doing a simple transformation.

But if it is indeed a simple transformation on the round length, this means they are greatly increasing their own risk. (And it only has limited anti-hopping effectiveness.)

If they did a transformation based on a singleton target distribution, it would be PPS. What they are doing is something in between.

Yes, paying a 12*D round out as a 3*D round seems risky to me too. And yet with all the other options which can reduce risk for them and reduce variance for their miners, they decided to fake their most important stats for what seem to me to be venal reasons. I could (maybe) understand it if they did it for a couple of weeks during a change over to hopper proof method, but still going now?

I meant to add that they're also doing something funky with their block announcements - so I don't know if they are reporting their true hashrate but not their blocks, or if they are fudging the hashrate and keeping 'block timing' boundaries.

If you aren't going to respect block boundaries, why not DGM? Or PPLNS if you're old school and don't like flexibility?

Well investigated organ.  This isn't going to go down well I expect!

EDIT: The following may not be true because I didn't include in this analysis the fact they're messing with the round boundaries. If the modified round lengths are caused strictly by moving the boundaries, it's possible they don't have a hidden fee.

The situation may be much worse than we (I?) thought.

The average of their reported round lengths seems close enough to D. But this doesn't mean they pay fairly on average, since their payout per round is inversely, rather than directly, proportional to the reported round length.

So if f is their transformation function, the average total they pay per round is

$int_0^{\infty}\frac{e^{-x}x}{f(x)}\ dx$

I fitted a loglogistic distribution with alpha = 0.953236, beta = 4.55639 (I'm lazy, a better fit is possible), and the result turned out as 78%. That's right, they're paying 78% of the rewards, keeping 22% fee to themselves.

So I'd say their transformation has nothing to do with combating hopping, and everything to do with being thieves. I guess they thought they could get away with it by keeping round length average similar to the expected one. Seeing how long this went on, I guess they were right.

My calculations were kind of hasty and I'm not that much interested in these politics, so I'll let organ volunteer to make the "BITCLOCKERS ARE STEALING 20% OF MINERS' REWARDS" public announcement once he confirms this with his data.

How to hop 12 (http://hoppersden.info/entries/30-How-to-hop-12-Bitclockers.com-amp-spurious-round-lengths-part-3) is finally done. I thought I had only one more post to go but after reading some of these posts, I doubt there'll be only one more. I think all pools need a thorough going over.


Can you expand on this a little?

What? You come into my house on the day my daughter is to be married and ...oh wait.

Pool hopping proportional pools is simple. It's when there are known or unknown anti-hopping protections that you'll earned less than the expected value of a share.

Even then, at least with all of the hop resistant rather than hop proof scoring systems, as long as you're there at the start you'll earn more than PPS payout. I haven't come across a proportional modification that prevented that entirely.

The difficulty in pool hopping is optimising. This means finding the correct %D to leave the pool for a particular payout method, making sure your software doesn't cause too many stales or miss round starts, having a system that allows the software to compare the expected value of a share at a particular pool at a particular %D, and probably lots more.

As far as manipulating hoppers to increase hashrate, I'd guess that is why they've used their score method the way they have - without actually owning up. That way they keep their hopper boost but lose less coinage from fulltime miners to the pool hoppers.

Really, it's quite a nice idea - a score system that doesn't need to keep track of anything other than users shares. But Slush's score system still does better because the expected value of a share at the end of a long round is still near 1.0. whereas at Bitclockers.com the expected value of a share drops more rapidly even than a proportional pool. And of course, any of the DGM solutions (I include PPLNS in that) beats the Bitclockers.com system hands down since they're not only provably hopper proof, they're can also be modified - to reduce miners variance for example. And you don't have to lie about your stats.

I made a very conservative estimate of how much they've underpaid pool hoppers over the last 200 rounds, and that's about 2000btc.

We don't know for sure that they're ignoring round boundaries because they don't own up to any block - so this is well worth my time looking into and an interesting idea. I hadn't thought to look for really nefarious activity.

Edit:What method did you use to calculate Beta? I ended up going with a brute force algorithm which was quick to write but not to run. Is there a better way - some regression technique maybe?

Politics or consumer advocacy? I haven't mined since October so I don't have a vested interest anymore. But dishonesty is bad for bitcoin - even if it was originally done with good intentions.

And about honesty - I wonder if even the Bitclockers.com pool ops realise that because they claim to have a proportional payment system: but actually don't, by their own definition they're underpaying miners if rounds are short.

So you think they are reporting the correct block finder but not when the block is found? More evidence of block boundary tampering then. I'm sure someone who has more skills with blockchains.info than i do could track every bitclockers block down, backtrack and estimate how many shares were in each block.

I really am surprised no one has made these sorts of accusations against them before.

I'm assuming their methodology is as follows (and the fact they misreport block finding times suggests this may not be their methodology):
1. When a block is found, determine X, the number of shares since the last block (in multiples of the difficulty).
2. Report there were f(X)*D shares in the last round, and pay (50 BTC / (D*f(X))) per each share since the last block, for a total of (50BTC * X / (D*f(X))).
3. f is chosen so that f(X) will follow a specific distribution with CDF F2(X).

X follows the exponential distribution so the real CDF is F1(X) = 1 - exp(-X). To have a CDF F2 for the reported lengths, the transformation they need is f(X) = F2^{-1}(F1(X)).

If they take F2(X)=F1(X), then f(X) = X and they are not doing any transformation. This results in normal proportional payments.

If they make it so f(X) is always 1 (corresponding to number of shares per round precisely equal to the difficulty) - that is, the target distribution has no variance, it's a "random" variable that always takes the same value - they will always pay (50 BTC / D) per share, that is, they are handing out PPS payments which has high variance for them, and no variance for miners.

If they make the target distribution something in between, with variance less than exponential but more than a singleton, they will have some variance, but less than PPS (and for miners, less than exponential). But this is moot unless they choose the distribution so that E[X/f(X)] = 1 (the expectation is over the real exponential distribution of X) so that they pay 50 BTC per block on average.

There are several ways to go about it but they all require a good numerical root-finding/optimization function (which should take less than 10 iterations to converge). I copped out by simply fitting your reported mean and variance exactly. Expressing alpha in terms of beta is easy from one equation, and then you solve the second equation numerically for beta. A more accurate result can be obtained by taking some statistics (such as moments or quantiles) and building a loss function for any given alpha/beta combination based on their difference from the real values of the distribution, with a weight that depends on each statistic's estimate variance. Then it's just a matter of numerically minimizing the loss function over alpha and beta.

The best method would be Bayesian inference, but if we don't want to commit to any particular prior, the Maximum Likelihood Estimator is the next best thing. For any given alpha and beta, calculate the logarithm of the pdf at each datapoint, and add. Maximize this function with respect to alpha and beta, again with whatever numerical optimization function you have available.

PS if you can give me the complete list of values of round length divided by difficulty, I can try to run an MLE.

If it involves pointing fingers, it's politics in the wide sense of the word, it being a noble pursuit notwithstanding.

All of the miners have been underpaid for short rounds. I'm not sure if fulltime miners have come out ahead or behind because what stats are available are either obfuscated or simply made up.

no.

huh, it really reminds me why my overall full day mining without hopping always comes short when compared to bclc. Checked my stats when my hopper machine was offline, they're normally off by .2 - .7 btc per day. some of it probably variance...but .7 btc?

This is a really important point that I didn't follow until you mentioned that E[X/f(X)] = 1 for a system like this to pay the same as the original. All the time I worked on this I assumed:
1. The number of shares submitted to Bitclockers would be respected.
2. The block boundaries did not have to be respected.

But  as you point out, just having a loglogistic distribution of round lengths doesn't guarantee that there has been a mapping block boundaries onto loglogistic round lengths. So I've listed the implementations below.

1. Block boundaries respected: each share X is mapped to f(X), which can be a number larger or smaller than X.  I also measured the expectation E[X/f(X)] using mean(X/qllogis(X,4,scale=0.95))= 0.7606445, so I'm getting a similar result to you: 24% of the expected share value is unavailable using the transform.

Advantages: pool pays out only part of bitcoin reward. May be hopping resistant.
Disadvantages: May be noticeable since changing the number of shares retrospectively means altering all pool stats, which might be noticeable.

2. Block boundaries ignored: each share maintains 1:1 value (what I'd assumed was happening)
Type i: The number of shares in a the transformed round is generated using the number of shares in the original round. In this case payouts are equivalent to a process that generated blocks from submitted shares in a loglogistic distribution. Expected share value = 1.
Type ii: The number of shares in a round is generated entirely randomly in a loglogistic distribution. I like this option best. It takes less calculation, and if you're going to ignore block boundaries, then you can make up any kind of payout system you want without using any of the information from the original rounds.

Advantages: Don't have to worry about changing pool stats except for the round length. Definitely hopping resistant.
Disadvantages: Have to obfuscate block solve times which means not claiming any blocks at all.

Which gives me a great idea for a pool - a randomly generated payout method each round. You only get told which at the end of the round! :tongueincheek:

So were there other ways you thought a loglogistic distribution could be obtained that I should include in the list?

Yes, that blocks were a complete fabrication from a random number generator, and they were proxying and hopping with miner's hashes. Note that there are no real Bitcoin blocks linked or mentioned on their stats (http://bitclockers.com/statistics/blockhistory) page. Making their fake blocks unprofitable to hop would be first priority in such a scheme, hence why the minimum solve time is >1/2 difficulty. Plus they can fake "unlucky" which they couldn't do if they were PPS.

The pool better publish their entire list of found Bitcoin block numbers and real finding times and submitted shares...or get tarred and feathered.

The graph shows three distinct stages, blocks <100 are more spread out, with just the expected short rounds missing (stolen?). Then after that, nothing that looks like pool rounds.

That would be 2 type ii, totally ignoring reality and making up your own game.


You think so, wouldn't you? So far I see a distinct lack of care. I wonder if some less scrupulous pools may head down that path since it's easy?

Aha.

Ways To Present Information:

• Nested Lists
  • Organized
  • Easy To Read
• Unformatted
  • Complete Jumble
  • Information Unparsable

goodideaillhavetopaymoreattentiontoformattingorreaderswillfindittoohardtofollow .

Since hoppersden.info is closing :verysadface:  I've moved 'How to hop' to:

http://howtohop.blogspot.com.au/2012/03/introduction.html

I wish 'myself' the best of luck in his future endeavours.

Good luck,

where do I post edits?   :)

If you see anything wrong in any of the reposts, you can leave a comment by clicking on the little speech bubble at the bottom of the page. Or you can message me here.