This article assumes some basic knowledge of EOS and EOSBet Casino. If you have no idea what those are then why are you here?
Backstory to why I did the analysis
Like many of you, I’ve been enjoying EOSBet Casino’s dApp by playing the dice betting game. The game allows a user with EOS tokens (I play through my EOS Lynx wallet on my iPhone) to wager tokens by rolling a simulated dice. The player has the option to pick a number 2 through 96 by interacting with a slider. To win the bet the player has to roll a number less than the number chosen on the slider. For example, if the player chose 50 on the slider, then the dice must land on a number lower than 50, giving the player a 49% chance of winning (since only rolling a number 1–49 results in a win). The payout is based on the degree of risk you place on the wager. If you have the slider on the highest option, 96, then you have a 95% chance of winning and the payout is only 1.03x, meaning that, if you only bet one EOS token then you receive 0.0315 EOS for winning. On the other hand, if you have the slider on the lowest option, 2, then you have a 1% chance of winning and the payout is 98.00x and if you only bet one EOS then you’d receive 98 EOS tokens.
In all honesty, though, I’ve been a complete pussy with this game. With limited EOS to gamble in the first place, I’ve only bet with the slider all the way up to 96 and only one EOS at a time (I know, bitch move). That only means a payout per bet of 0.0315 (like I said earlier) but, I have won 100% so any extra EOS is good, I guess.
Recently, in the EOSBet Casino Telegram group someone posted a link to some software they designed that automated the betting process. Full disclosure, I didn’t look at the software (sorry person that worked hard and had the courage to put themselves and their work out there), but it got my weird little nerdy brain going.
If I could automate the process of betting a single EOS on the highest slider option (96) then I could passively collect hundreds or thousands of tiny wins of 0.0315 EOS a day. By just bullshitting the idea and coming up with some basic figures: 60 seconds in a minute, 60 minutes in an hour, 24 hours a day. That comes out to 86,400 seconds in a day. If the software could place a bet every second (100% possible with the EOS network) then every little micro-win will start to add up. But, just as fast as my mind starter turning, it hit me. With a 95% probability of winning, you’d lose 5% of the time. If 95% of the bets are wins (paying out 0.0315 EOS) then you’d win 2,585.52 EOS, but if 5% of the bets are losses (which if you bet one EOS and lose, you lost that whole EOS) then you’d lose 4,320 EOS. Immediately, my dreams of creating “easy money” were crushed.
Of course, many of you are already thinking ahead and have realized what I eventually realized as well about how my back-of-the-napkin calculations were completely wrong. Comparing it to the coin flip probability problem — if you flip a coin three times and they all land on heads, what is the probability of the next flip being heads? Still 50/50. Same with the EOSBet dice game. There’s no guarantee of winning 95 games out of every 100 if the slider is on 96 giving you a 95% probability of winning. Every single bet resets the probability and each individual roll still gives you a 95% chance of winning. So, you could win 95 games out of 100 or you could win all 100. There’s no way to determine a set number of wins.
This started me down the rabbit hole. The following is what happens when I have too much time on my hands.
I decided to work out some basic models using a Jupyter Notebook to see what kind of results the strategy might yield if you completely randomized each individual roll. I used python to program the tests because python is the best and I’m a very lazy — and terrible — coder (fuck you compiler over interpreter nerds, we get it, C++ is faster, but I’ve touched a boob).
Before we start: definitions and up-front stuff
Real quick before I walk through the analysis:
Micro-betting is the term I made up to call the strategy of automatically placing small bets of just one EOS thousands of times a day.
The analysis assumes a working software that allows the user to determine a slider option, press a button, and the program will run itself to bet every second (86,400 bets per day).
The analysis
To make my life easier (and make the analysis runtimes a lot quicker) I broke the bets into 100 bet intervals, meaning 864 100-bet intervals in a day. This way it will be easier for us to read the output and quickly see the win percentage of each interval.
I also used an interactive slider widget to represent the slider option in the dApp. The bet is determined by the slider placement.
By using a random number generator, I created a function that randomly generated 100 dice rolls. The function would then count how many rolls in the 100-roll interval resulted in a number greater than the bet (chosen by the user through the interactive slider). Then, that was repeated 864 times to represent the 864 100-bet intervals in a day (one bet per second).
To make money, the user would have to win more games per 100-bet interval than whatever was choose for the slider option. For example, to win money if the slider option chosen was 90, the user would have to win 91 out of 100 rolls to see a net gain.
The first interactive slider widget showed how many wins per each 100-bet interval the user won and whether or not the interval was a net-gain for the user.
It’s hard to interpret any real and meaningful results from this interactive widget, but it’s just fun to mess around with.
For the next part of the analysis, I wanted to see the percentage of net-gain intervals to net-loss intervals. To do this I pretty much just counted all of the “Net-Gain” and “Net-Losses” from the second graph and calculated the percentage of each by dividing the total of either net-gain intervals or net-loss intervals to the number of intervals in total (864).
The interesting take away from this part of the analysis was that even though having the slider option at 96 (giving the user a 95% chance of winning a roll) actually had less net-gain 100-roll intervals than when the user had the slider option at 2 (giving the user only a 1% chance of winning a roll). This is counterintuitive at first but after thinking about it I can somewhat see the reasoning behind that. To have a net-gain 100-roll interval with the slider on 96, the user would have to win 97 rolls, whereas if the user had the slider on 2 they would only have to win 3 rolls per 100-rolls.
The other critical take away is that none of the slider options provided above a 50% chance of the 100-roll intervals resulting in net-gains. That means that, at least according to the analysis, there’s absolutely no chance of an automated software betting one EOS every second resulting in a total net-gain for the user, no matter what the slider option was put to.
This sadly put the final nail in the coffin of my automated micro-betting idea. Still, the show must go on, and even if none of the slider options could result in a net gain I wanted to see which slider option at least resulted in the best net-gain probability.
For this part of the analysis, I collected the net-gain probability for each slider option from the above interactive slider and plotted them to see which one provided the highest probability. Long story short, there wasn’t a clear winner here since every time I ran the test, the numbers would be completely different since they are randomly generated. The only thing I could gather for (almost) certain from this analysis was that the slider option that provided the maximum net-gain probability was almost always in the range from 10 to 60. This isn’t that groundbreaking since that still leaves the user with over half of the options to choose from. Also, at least twice in the many runs of the analysis I did, the maximum actually ended up within the range of 60 and 90, again, showing no clear signs of a winner, or at the very least, some consistency. The only concrete takeaway is that the user has a better probability of net-gains by choosing a slider option 2 to 10 than they would choosing a slider option 90–96, and to get the best probability all you can really do is throw a dart at a board with numbers 10 through 60 on it and use whatever you hit as your choice.
To round out the analysis I tried one more time to see if there was any true winner in slider option choices to choose if you felt lucky and still wanted to risk doing automated micro-betting. To do the last part I pretty much just ran a bunch of the previous tests and kept track of which slider option provided the maximum probability from each individual test. The idea was that, maybe, one would show up more than the others. Again, sadly, there wasn’t much to take away from this. The results were different every single time without any clear winner.
To be transparent though I could only run limited numbers of tests since I was just running the analysis on a laptop and I could only run a certain number of the tests without having to wait forever for my computer to chug out the answers (I can hear all the compiler losers chuckling under their breaths).
Pretty much, the only thing that came out of this part of the analysis was that it reassured the 10–60 max probability range and that the majority of results actually showed up in the 40–50 range. That seems promising on the face, but with the limited number of tests done and the wide variations in results you have to take that with a grain of salt. Below is one of the outcomes that actually had a clear winner.
The takeaway
So, what should we take away from the interpretations of the analysis? Basically, automated micro-betting almost certainly won’t work, regardless of which slider option you choose. But, here’s my real advice: PLEASE STILL TRY.
Why, if it doesn’t work would I still recommend you try it? Well, as a holder of BET tokens I will eventually receive a percentage of all the pooled lost bets, making your loss my gain. So, go on out there and please try to beat the odds 🖕.
Links and other stuff
To see the full walkthrough of the analysis you can visit my Github to view the Jupyter Notebook and the code I wrote to perform the analysis. That way you can shit all over my feelings and tell me if I did the analysis wrong or how bad I suck at coding. The files should be amateur-ly documented, so it shouldn’t be that hard to stumble around and critique.
Follow me on Twitter or connect with me on LinkedIn if you want to reach out and critique my analysis/code or to just talk about EOS.
Thanks for reading.