Bitcoin Dice Site Called Just-Dice.com Rigged or Not?
01-23-2014
, 08:23 PM
This is a site that allows players to bet on a dice game at a provably fair disadvantage of -1 percent. The amount on the left of the picture is the amount of bitcoins that is backing the bankroll for the site. The "maximum win" number is the most money someone can bet/win in a single roll. That number is set at 1/2 of 1 percent of the total bankroll.
In order to allow for people to make big bets the site allows people to invest in the bankroll of the site. What seems sort of suspicious is that even though the investors in the site should win at a 1 percent rate over time they have only won at under .25 percent over the amount of bets it lists. The average bet size on the site is .01 of a bitcoin approx and 500 million bets have been placed.
Based on those numbers is it possible to prove that investors on the site are intentionally being cheated? What is tending to happen is that the profit will drift up for long periods of time and then a "big bettor" will come in and win a huge chunk of money. The amounts these big bettors are betting are usually unrealistic. Sometimes as much as 500 thousand dollars worth of bitcoins in a single roll.
https://just-dice.com/#a1
Last edited by northeastbeast; 01-23-2014 at 08:35 PM.
01-23-2014
, 10:36 PM
01-24-2014
, 02:42 AM
The owner of the site says he's going to come in and post a bunch of data on the betting so that it can be analyzed. It's a lot of information so it's taking some time.
01-24-2014
, 08:20 AM
01-24-2014
, 09:18 AM
You should be able to do something like this:
1. Uncompress and convert the grouped data into a list of {BetSize,Probability} pairs (500M pairs using a 4-byte float for each = ~4GB RAM needed).
2. Then run:
The fraction NumRunAsBadOrWorse/NumSimulations should give an idea of how likely/unlikely the real just-dice.com run is.
I've used this same idea to work with outcomes from SNG all-ins and it worked quite well for that, but because this is such a huge amount of values I'm not sure if you'll be able to get in enough iterations in a sensible amount of time...
I think I can see a better algorithm that deals with the grouped data (ie: create a Binomial distribution for each line of grouped data and then pick bins proportionally using this O(1) algorithm), but it may well turn out somebody on this forum knows a better way to do this without the need for simulation at all, so I'll leave it a while to see first.
Juk
EDIT: Have I got the "(0.99*((1/Probability_I)-1)*BetSize_I)" bit right for the way the game actually works?
1. Uncompress and convert the grouped data into a list of {BetSize,Probability} pairs (500M pairs using a 4-byte float for each = ~4GB RAM needed).
2. Then run:
Code:
NumSimulations = 0
NumRunAsBadOrWorse = 0
for many iterations:
Sum=0
for all bets in the list, I:
if (UniformRandom01() >= Probability_I)
Sum = Sum + BetSize
else
Sum = Sum - (0.99*((1/Probability_I)-1)*BetSize_I)
if (Sum <= 11717BTC)
NumRunAsBadOrWorse = NumRunAsBadOrWorse + 1
NumSimulations = NumSimulations + 1
I've used this same idea to work with outcomes from SNG all-ins and it worked quite well for that, but because this is such a huge amount of values I'm not sure if you'll be able to get in enough iterations in a sensible amount of time...
I think I can see a better algorithm that deals with the grouped data (ie: create a Binomial distribution for each line of grouped data and then pick bins proportionally using this O(1) algorithm), but it may well turn out somebody on this forum knows a better way to do this without the need for simulation at all, so I'll leave it a while to see first.
Juk
EDIT: Have I got the "(0.99*((1/Probability_I)-1)*BetSize_I)" bit right for the way the game actually works?
Last edited by jukofyork; 01-24-2014 at 09:34 AM.
Reason: Corrected for the house edge.
01-24-2014
, 09:54 AM
My edit time has run out on the post above, but I think I've got it now: the probabilities in the file already have the 1% house edge in them, so we should be using:
Which looks like it works out as the game on the site, eg:
((1/((1/0.99)*0.495))-1) = 1 unit of profit to player
((1/((1/0.99)*0.2475))-1) = 3 unit of profit to player
((1/((1/0.99)*0.66))-1) = 0.5 unit of profit to player
and so on...
Juk
Code:
Sum = Sum - (((1/((1/0.99)*Probability_I))-1)*BetSize_I)
((1/((1/0.99)*0.495))-1) = 1 unit of profit to player
((1/((1/0.99)*0.2475))-1) = 3 unit of profit to player
((1/((1/0.99)*0.66))-1) = 0.5 unit of profit to player
and so on...
Juk
01-24-2014
, 12:18 PM
Thought about this some more and here are a couple of ideas:
Instead of using a massive 500M element list (although this may still be useful for the next method - see below), just keep the grouped data and use:
You can speed this up massively by:
A) Converting all of the probabilities to 32 or 64 bit fixed point integers.
B) Pre-calculating the change in Sum for each of the two outcomes.
C) Using the 32/64 bit "quick and dirty" RNG (from Numerical Recipes book).
D) It's "embarrassingly parallel" so can use threads or parallel_for() with only a tiny change to the summation needed.
E) If the group sizes are large enough, possibly saving the Binomial distribution for each group and selecting from it using the O(1) algorithm (although not sure if all the extra work for this is worth it...).
If this is still too much to get a decent number of iterations, then perhaps you could use boot-strapping like so:
1. Stick all of the data in a massive 500M element vector (or keep grouped and use the O(1) discrete distribution selection algorithm I linked above).
2. Take lots of boot-strap samples of size N = 1000, 10000, 1M (or whatever seems to work given the massive differences in the bet-sizes we have here) by indexing into the vector above (or proportionally selecting a bin using the O(1) algorithm) and using the same idea as the other algorithm, eg:
3. Calculate the mean and SD of the above boot-strap samples.
4. Multiply the mean by 500,000,000/N and divide the SD by sqrt(500,000,000/N) and then calculate P(X <= 11717BTC) ~ Gaussian(mean,SD).
Not sure if this is 100% correct though (people in this forum will hopefully be able to correct me if it isn't), but something like this should work I think.
Juk
EDIT: Not sure the "divide SD by sqrt(500,000,000/N)" is correct...
Instead of using a massive 500M element list (although this may still be useful for the next method - see below), just keep the grouped data and use:
Code:
NumSimulations = 0
NumRunAsBadOrWorse = 0
for many iterations:
Sum=0
for all groups in the list, I:
for all elements in the group, J:
if (UniformRandom01() >= Probability_IJ)
Sum = Sum + BetSize
else
Sum = Sum - (((1/((1/0.99)*Probability_IJ))-1)*BetSize_I)
endfor
endfor
if (Sum <= 11717BTC)
NumRunAsBadOrWorse = NumRunAsBadOrWorse + 1
NumSimulations = NumSimulations + 1
endfor
A) Converting all of the probabilities to 32 or 64 bit fixed point integers.
B) Pre-calculating the change in Sum for each of the two outcomes.
C) Using the 32/64 bit "quick and dirty" RNG (from Numerical Recipes book).
D) It's "embarrassingly parallel" so can use threads or parallel_for() with only a tiny change to the summation needed.
E) If the group sizes are large enough, possibly saving the Binomial distribution for each group and selecting from it using the O(1) algorithm (although not sure if all the extra work for this is worth it...).
If this is still too much to get a decent number of iterations, then perhaps you could use boot-strapping like so:
1. Stick all of the data in a massive 500M element vector (or keep grouped and use the O(1) discrete distribution selection algorithm I linked above).
2. Take lots of boot-strap samples of size N = 1000, 10000, 1M (or whatever seems to work given the massive differences in the bet-sizes we have here) by indexing into the vector above (or proportionally selecting a bin using the O(1) algorithm) and using the same idea as the other algorithm, eg:
Code:
if (UniformRandom01() >= Probability_I) Sum = Sum + BetSize else Sum = Sum - (((1/((1/0.99)*Probability_I))-1)*BetSize_I)
4. Multiply the mean by 500,000,000/N and divide the SD by sqrt(500,000,000/N) and then calculate P(X <= 11717BTC) ~ Gaussian(mean,SD).
Not sure if this is 100% correct though (people in this forum will hopefully be able to correct me if it isn't), but something like this should work I think.
Juk
EDIT: Not sure the "divide SD by sqrt(500,000,000/N)" is correct...
Last edited by jukofyork; 01-24-2014 at 12:47 PM.
01-25-2014
, 12:46 AM
Got it working now and it looks like the std dev is about 21k BTC, and: P(X <= 11717) ~ N(48800,21000^2) = ~0.04
or in other words: about a 1 in 25 event.
I've left it running overnight and should have the results of 4 runs of 10k simulations by tomorrow, but I don't think it'll change all that much (perhaps 21k +/- 500 BTC or so).
I'll post the results and code I used tomorrow.
Juk
or in other words: about a 1 in 25 event.
I've left it running overnight and should have the results of 4 runs of 10k simulations by tomorrow, but I don't think it'll change all that much (perhaps 21k +/- 500 BTC or so).
I'll post the results and code I used tomorrow.
Juk
01-25-2014
, 02:55 AM
Quote:
Got it working now and it looks like the std dev is about 21k BTC, and: P(X <= 11717) ~ N(48800,21000^2) = ~0.04
or in other words: about a 1 in 25 event.
I've left it running overnight and should have the results of 4 runs of 10k simulations by tomorrow, but I don't think it'll change all that much (perhaps 21k +/- 500 BTC or so).
I'll post the results and code I used tomorrow.
Juk
or in other words: about a 1 in 25 event.
I've left it running overnight and should have the results of 4 runs of 10k simulations by tomorrow, but I don't think it'll change all that much (perhaps 21k +/- 500 BTC or so).
I'll post the results and code I used tomorrow.
Juk
The data I posted doesn't show it, but over 1 million BTC of the < 5 million wagered in total was wagered by one guy in one 24 hour period at the end of September. He didn't *have* a million BTC to wager, and could only bet that much because he kept winning, betting the same coins over and over.
It seems to me like that somehow skews things. If he hadn't won, he wouldn't have bet so much. ie. running the bets I've provided and seeing how often the results come out as bad as or worse than they did kind of assumes that those bets were always going to be made - but all those huge bets that day couldn't have been made if lots of them didn't win.
Does that make any sense? I can't tell if I'm desperately trying to justify the result or if this effect is real.
I made this chart a day or two before dumping the data I provided yesterday. It shows the actual site profit and the expected (1% of wagered) profit. The two grey areas are when our famous whale was playing. You can see the expected profit line goes vertical at the end of September, on his million BTC day, and other than those two grey areas the two curves run roughly parallel, as expected.
01-25-2014
, 08:55 AM
Here are the results of the 4 x 10k runs:
Mean = (48651.9+49036.9+48904.8+48437.2)/4 = ~48758
SD = ((21209.2+21391.3+21356.2+21530.4)/4 = ~21372
P(X <= 11717) ~ N(48758,21372^2) = ~0.0415 (which agree's with "Expected run-bad" = (3.86+4.17+3.99+4.31)/4 = ~4.1%)
So again, this appears to be only about a 1 in 25 event.
As for the reason, then I think you have it spot on: you ran bad during those massive bets and sadly these are weighted much more heavily in terms of variance.
Here is the code I used:
If you want to be more rigorous, then you might want to re-write this to use floating point arithmetic and a better random number generator (like the Mersenne twister). As it is, there is some chance (but unlikely) that the cycle length of the "quick and dirty" RNG has meshed with the sample size, but if this is the case then it's likely you'd see an increase in the standard deviation using a better RNG (ie: the event would be even less rare!). I think it'll prolly run about 10-20x slower if you do this, so you'll need a few more days CPU time than I gave it for the same number of simulations...
Also, if you clean the code up a bit then you should also be able to work out how things could have been different if you were to exclude the bigger bet sizes, etc.
Juk
Code:
NUM_SIMULATIONS : 10000 Run as bad or worse : 3.86% Mean (in BTC) : 48651.9 Std dev (in BTC) : 21209.2 NUM_SIMULATIONS : 10000 Run as bad or worse : 4.17% Mean (in BTC) : 49036.9 Std dev (in BTC) : 21391.3 NUM_SIMULATIONS : 10000 Run as bad or worse : 3.99% Mean (in BTC) : 48904.8 Std dev (in BTC) : 21356.2 NUM_SIMULATIONS : 10000 Run as bad or worse : 4.31% Mean (in BTC) : 48437.2 Std dev (in BTC) : 21530.4
SD = ((21209.2+21391.3+21356.2+21530.4)/4 = ~21372
P(X <= 11717) ~ N(48758,21372^2) = ~0.0415 (which agree's with "Expected run-bad" = (3.86+4.17+3.99+4.31)/4 = ~4.1%)
So again, this appears to be only about a 1 in 25 event.
As for the reason, then I think you have it spot on: you ran bad during those massive bets and sadly these are weighted much more heavily in terms of variance.
Here is the code I used:
Code:
#include "stdafx.h"
#include <iostream>
#include <fstream>
#include <time.h>
using namespace std;
// -----------------------------------------------------------------------------------------
// The number of simulations we want to run.
#define NUM_SIMULATIONS 10000 // Currently running at ~ 1 sim per 2s.
// This is the value we want to test against for bad luck.
#define TEST_BTC 11717 // 11717 BTC is what is says in the image.
// -----------------------------------------------------------------------------------------
// The number of bets groups stored in the file.
#define NUM_BET_GROUPS 2979615 // Each bet made up of 3 numbers on a single line.
// The maximum fixed point (high-order) number a probability can be (ie: when = 1.0).
#define MAX_FP_PROB 4096000000U // = 1000000*2^12 or 1000000<<12.
// -----------------------------------------------------------------------------------------
// This is used to store the data.
struct GroupElement {
int Num; // The number of bets in this group.
unsigned int Prob; // The fixed point probability of win, scaled so 1.0=MAX_PROB.
long long EV_Lose; // The (+ve) EV, in satoshis, for just-dice.com when player loses.
long long EV_Win; // The (-ve) EV, in satoshis, for just-dice.com when player wins.
};
// -----------------------------------------------------------------------------------------
// The vector of grouped values, stored as global to keep on heap.
GroupElement G[NUM_BET_GROUPS];
// -----------------------------------------------------------------------------------------
void main(int argc,char** argv)
{
// Read from the file and convert.
// NOTE: I pre-converted the file to be space separated!
cout << "Loading file... "; cout.flush();
ifstream InFile("bets.txt");
for (int I=0;I<NUM_BET_GROUPS;I++) {
InFile >> G[I].Num;
InFile >> G[I].EV_Lose;
InFile >> G[I].Prob;
G[I].EV_Win=(long long)(-(((0.99/((double)G[I].Prob/1000000.0))-1.0)*(double)G[I].EV_Lose));
G[I].Prob=(G[I].Prob<<12); // Convert 10,000ths of a % to our fixed point system.
}
InFile.close();
cout << "Done." << endl << endl;
// These are used to get the mean and std dev.
double SumAllEVInBTC=0.0;
double SquareSumAllEVInBTC=0.0;
// This holds the number of times the sim ran worse than 11717BTC.
int NumRunAsBadOrWorse=0;
// This holds the current 32bit "quick and dirty" random number.
unsigned int N=time(0); // Seed with the time.
// For many simulations.
cout << "Running simulations: "; cout.flush();
for (int I=0;I<NUM_SIMULATIONS;I++) {
// This holds the sum of EV, in "satoshis", from just-dice.com's perspective.
long long SumEV=0LL;
// For each group.
for (int J=0;J<NUM_BET_GROUPS;J++) {
// For each in group.
for (int K=0;K<G[J].Num;K++) {
// Lets get the next random number.
N=((N*1664525U)+1013904223U);
// Test the random number against our probability.
// NOTE: If above 4096000000, we need to discard and re-generate the number...
if (N<=G[J].Prob)
SumEV+=G[J].EV_Win; // Player wins (= just-dice.com pays out).
else if (N<=MAX_FP_PROB)
SumEV+=G[J].EV_Lose; // Player loses (= just-dice.com profits).
else
K--; // Need to generate another number (~5% of time).
} // End for each in group.
} // End for each group.
// Add to sum and square sum (in BTC).
SumAllEVInBTC+=(double)SumEV/100000000.0;
SquareSumAllEVInBTC+=((double)SumEV/100000000.0)*((double)SumEV/100000000.0);
// If worse than test threshold, add to the count.
if ((SumEV/100000000LL)<=(long long)TEST_BTC)
NumRunAsBadOrWorse++;
// Print the iter over.
cout << (I+1) << ' '; cout.flush();
} // End for each iter.
cout << "Done." << endl << endl;
// Print the results.
// Use: http://www.wolframalpha.com/input/?i=P%28X+%3C%3D+11717%29+~+N%2848800%2C21000%5E2%29
cout << "NUM_SIMULATIONS : " << NUM_SIMULATIONS << endl;
cout << "Run as bad or worse : " << 100.0*((double)NumRunAsBadOrWorse/(double)NUM_SIMULATIONS) << '%' << endl;
cout << "Mean (in BTC) : " << SumAllEVInBTC/(double)NUM_SIMULATIONS << endl;
cout << "Std dev (in BTC) : " << sqrt((SquareSumAllEVInBTC-((SumAllEVInBTC*SumAllEVInBTC)/(double)NUM_SIMULATIONS))/(double)(NUM_SIMULATIONS-1)) << endl;
}
Also, if you clean the code up a bit then you should also be able to work out how things could have been different if you were to exclude the bigger bet sizes, etc.
Juk
01-25-2014
, 09:10 AM
Quote:
Incidentally, would it be useful to have any more data? I think OP is just trolling here but he says that the data I provided was "essentially useless".
As for me being in with you somehow, then if people check they can see that I was the first person to write code to work out luck-adjustment for SNGs (ie: to create graphs like you have of your expected winnings vs actual) and also have no time at all for people who claim online poker is rigged without providing some proof.
I do tend to rush things too though, so it may be a good idea to double check my code to be sure there is not a bug lurking there somewhere giving erroneous results...
I should say finally that the value of 4% wasn't that far off what I had expected though: when this thread was first made I plugged some values into a binomial calculator which I thought represented the number and size of your biggest bets and as a result guessed it would be somewhere around 5%.
Juk
01-25-2014
, 11:29 AM
Quote:
It seems to me like that somehow skews things. If he hadn't won, he wouldn't have bet so much. ie. running the bets I've provided and seeing how often the results come out as bad as or worse than they did kind of assumes that those bets were always going to be made - but all those huge bets that day couldn't have been made if lots of them didn't win.
Does that make any sense? I can't tell if I'm desperately trying to justify the result or if this effect is real.
Does that make any sense? I can't tell if I'm desperately trying to justify the result or if this effect is real.
Players tend to move up in stakes when their bankroll increases and then back down if they lose (ie: move up when "running hot" and back down when "running bad"). There is also a cap on how far up in stakes the players can go (ie: nothing above the "nosebleed" stakes).
So in terms of $s, if you were to take the luck adjusted winnings of the whole population of poker players, it's quite likely that they would appear as a whole to be running under expectation!
But, if you were to do the same in terms of units (ie: "big blinds", "SNG/MTT buy-ins", etc) then they should as a whole be running approximately as expected.
Juk
01-25-2014
, 12:17 PM
My edit time has run out again, but my post above didn't make much sense: I should have said "take the luck adjusted winnings of the whole population of poker players, excluding the top winners/most lucky". Here's a couple of examples of what I mean to make it clearer:
* A SNG player does quite well at one level and then tries to move up in stakes, but gets killed due to variance alone. He then moves back down and doesn't try going back up again because he believes he was out-played at the level above.
* A high stakes cash game player tries to move up to the nosebleeds and the same happens to him, meaning he moves back down forever and/or completely busts his bankroll and leaves poker.
The players that this has happened to are going to appear to be running under EV as a whole in terms of $s, but not in terms of units.
If you add this to the phenomenon whereby players on huge heaters at the top stakes won't accept it (they're poker gods right?
) nor care about luck-adjusted values saying they are running above expectation, it's quite likely that you can (correctly) get the feeling that as a whole, poker players are running under EV and/or the luck-adjustment calculation (incorrectly) appears somewhat biased! There's a massive thread in the SNG forum here where this phenomenon is clear to see, and if you look around the 2+2 forums, it's likely that the same is true for other game types too.
As for what your site has experienced, it's kind of the opposite effect whereby the variance of your game goes up massively when one of these "whales" gets lucky and re-invests his winnings, so in a "multiverse" of just-dice.com sites I think you're going to find a disproportionate number of slightly under-EV sites (with higher variance) and a few bigger over-EV sites (with lower variance), but the "average site" should be running as expected. I'm not sure how you can model this though as what I did just assumes that all the sites in the "multiverse" have an identical distribution of bets made...
As for the trolls, then think of it this way: had the initial bet(s) of these players been lost and the EV of your site significantly over 1%, then it's likely you'd still have just as many "rigtards" being vocal as to how "the site was rigged against the players" and so on - you can't win
Juk
* A SNG player does quite well at one level and then tries to move up in stakes, but gets killed due to variance alone. He then moves back down and doesn't try going back up again because he believes he was out-played at the level above.
* A high stakes cash game player tries to move up to the nosebleeds and the same happens to him, meaning he moves back down forever and/or completely busts his bankroll and leaves poker.
The players that this has happened to are going to appear to be running under EV as a whole in terms of $s, but not in terms of units.
If you add this to the phenomenon whereby players on huge heaters at the top stakes won't accept it (they're poker gods right?
) nor care about luck-adjusted values saying they are running above expectation, it's quite likely that you can (correctly) get the feeling that as a whole, poker players are running under EV and/or the luck-adjustment calculation (incorrectly) appears somewhat biased! There's a massive thread in the SNG forum here where this phenomenon is clear to see, and if you look around the 2+2 forums, it's likely that the same is true for other game types too.As for what your site has experienced, it's kind of the opposite effect whereby the variance of your game goes up massively when one of these "whales" gets lucky and re-invests his winnings, so in a "multiverse" of just-dice.com sites I think you're going to find a disproportionate number of slightly under-EV sites (with higher variance) and a few bigger over-EV sites (with lower variance), but the "average site" should be running as expected. I'm not sure how you can model this though as what I did just assumes that all the sites in the "multiverse" have an identical distribution of bets made...
As for the trolls, then think of it this way: had the initial bet(s) of these players been lost and the EV of your site significantly over 1%, then it's likely you'd still have just as many "rigtards" being vocal as to how "the site was rigged against the players" and so on - you can't win
Juk
Last edited by jukofyork; 01-25-2014 at 12:47 PM.
01-25-2014
, 01:43 PM
Thanks for your detailed replies.
I still struggle with the effect I was describing, of lucky players betting more and skewing the results that way. It somehow feels wrong.
It reminds me of an argument I often see: "the site is bound to do better than expectation because almost everyone plays until they bust. You can't "borrow" to go anywhere from bust. All these people going bust cause the site to run better than expected".
To counter that, every bet has a 1% house edge built in. The site doesn't care where one player's bet stream ends (due to going bust, say) and the next player's begins. It's just a stream of bets, each with an expection of +1% for the site, so the sum of those bets also has a +1% percent expectation.
But I guess the difference is in the way we're simulating things. The big bets wouldn't have happened unless the big play got lucky, because he couldn't have afforded to lose the >1M BTC he bet (on account of not owning that much).
To make a very simple stupid example: suppose there's only one gambler on the site, and he only has 1 BTC. He's going to bet that 1 BTC aiming to double it twice, then quit.
a) 50.5% of the time he loses his first bet, and ends up 1 unit down.
b) 24.9975% of the time he wins his first bet, loses his 2nd, and ends up 1 unit down.
c) 24.5025% of the time he wins both bets and ends up 3 units up.
We see scenario c happen, with two bets (sizes 1 and 2) and wonder "is the site rigged?"
We run your simulation, and see that the 4 possible outcomes were -3, -1, +1, +3.
We know that -3 is impossible. There is only 1 unit in the hands of the gambler, so that's the most he can lose.
Um... it turns out my simple example clearly demonstrates how confused I am... Is it of any other use?
Well we get that too of course. Even though the site has been doing badly overall, some players obviously have horrible luck. With 500 million bets to look through you're able to find instances of all kinds of lucky and unlucky streaks. But the ones the unlucky streaks happen to often call foul. So you're right - we can't win. At least with the unlucky players we can point to the provable fairness of the site. Not that it helps once a losing player has made up his mind that he was cheated of course. They tend not to want to listen to reason, especially if it proves beyond doubt that they're wrong.
I still struggle with the effect I was describing, of lucky players betting more and skewing the results that way. It somehow feels wrong.
It reminds me of an argument I often see: "the site is bound to do better than expectation because almost everyone plays until they bust. You can't "borrow" to go anywhere from bust. All these people going bust cause the site to run better than expected".
To counter that, every bet has a 1% house edge built in. The site doesn't care where one player's bet stream ends (due to going bust, say) and the next player's begins. It's just a stream of bets, each with an expection of +1% for the site, so the sum of those bets also has a +1% percent expectation.
But I guess the difference is in the way we're simulating things. The big bets wouldn't have happened unless the big play got lucky, because he couldn't have afforded to lose the >1M BTC he bet (on account of not owning that much).
To make a very simple stupid example: suppose there's only one gambler on the site, and he only has 1 BTC. He's going to bet that 1 BTC aiming to double it twice, then quit.
a) 50.5% of the time he loses his first bet, and ends up 1 unit down.
b) 24.9975% of the time he wins his first bet, loses his 2nd, and ends up 1 unit down.
c) 24.5025% of the time he wins both bets and ends up 3 units up.
We see scenario c happen, with two bets (sizes 1 and 2) and wonder "is the site rigged?"
We run your simulation, and see that the 4 possible outcomes were -3, -1, +1, +3.
We know that -3 is impossible. There is only 1 unit in the hands of the gambler, so that's the most he can lose.
Um... it turns out my simple example clearly demonstrates how confused I am... Is it of any other use?
Quote:
As for the trolls, then think of it this way: had the initial bet(s) of these players been lost and the EV of your site significantly over 1%, then it's likely you'd still have just as many "rigtards" being vocal as to how "the site was rigged against the players" and so on - you can't win
01-25-2014
, 07:59 PM