TossBits.com - toss a coin like game with variable payout. Provably fair

[xyu]

clickable: TossBits.com
testnet for those who want to try it safely: http://testnet.tossbits.com/

Hi guys, I've been working on a new gambling site, it is like a coin toss game, where your chances are 50%. But unlike other sites, I've made payout variable, basically, when you lose, your wager goes to the bank, and when you win you get 50% of the bank.

Some other features:

• Low house edge: 1%
• Provably fair
• Off the chain transactions
• Realtime
• Chat

Gameplay:
We have fixed size bets: from 0.0005 to 1 BTC, that's because we have a bank for each bet type. As I've mentioned payouts are not fixed and depend on the result of the previous bets, if you lose, or other players lose, their wager goes to the bank, rising the available payout. If someone wins they get 50% of the current bank, so in theory it is unlikely that bank can be emptied. What that means for you as a player? You can choose your own strategy, for instance you can watch bets in realtime and play only when the payout is significant enough for you, or you if you have enough coins in you balance you can play agains the bank - because all coins you lose go to the bank a series of wins can recover all loses, so you playing until you leave the bank with less coins than were there when you started

Provability:
All results are provably fair. We use random client and server seeds to generate a hash that is used to determine luck, server side seeds grouped into batches by 1024, and we calculate a hash for a batch, therefore guaranteeing that we cannot alter the server seed without altering entire batch. Client side seeds generated after each bet - it is all embedded right into html and is not minified, so you can inspect the code.
Here also the python script that can check results:

Code:

# -*- coding: utf-8 -*-
from __future__ import print_function

import requests
import sys

from hashlib import sha256

URL = 'http://tossbits.com/api'

bet_id = sys.argv[1]
bet = requests.get(URL + '/bet/' + bet_id).json()
rand_hash = sha256(bet['server_seed']+bet['client_seed']).hexdigest()
luck = bool(int(bin(int(rand_hash, 16))[-1]))

print('Luck: ', luck)

batch = requests.get(URL + '/batch/'+bet['batch']).json()
if batch.get('error'):
    print("couldn't verify batch, because it is not exhausted yet")
    exit(1)

acc = ''
for hash in batch['hashes']:
    acc += hash

batch_hash = sha256(acc).hexdigest()
assert batch_hash == bet['batch']

You need to install `requests` library first. To run: `python verifybet.py <bet-id>`, for example python verifybet.py 34


I would like if you guys give it a try
Any feedback?

Thanks!

[1715163571]

1715163571

[digit]

Looks interesting,  I'll give it a try

[digit]

do i have to make an account to use the test site?

[xyu]

do i have to make an account to use the test site?

Yep, but it doesn't check emails, so, you can use whatever email you want =)
You can also use testnet faucet to get the coins - http://testnet.mojocoin.com/

[vlees]

I first read it incorrectly and assumed the batch hash was the hash of the next server seed, which is not the case.

Why did you take this approach instead of just publishing the hash of the next seed?

[xyu]

I first read it incorrectly and assumed the batch hash was the hash of the next server seed, which is not the case.

Why did you take this approach instead of just publishing the hash of the next seed?

Do you mean kind of the server seed that changes, say, once a day and its hash published somewhere on the site?
Well, with this I should also make sure that you cannot use client seed twice, since it will be obviously exploitable, so I just thought making unique random seed for each bet would be more secure, the problem was that publishing hash of this seed wouldn't make much sense because it would always change with each bet, so I decided to combine them in batches and publish the hash of the batch.

[vlees]

Why wouldn't it make sense to create a different server seed beforehand for each game and after it is used, immediately publish it?

[xyu]

Why wouldn't it make sense to create a different server seed beforehand for each game and after it is used, immediately publish it?

Just wonder how will you check it? You decide to check our honesty - you check the client seed, remember it, you make a bet - and check what was the server seed - seems ok? But it isn't in this scenario we could just easily fool you by using any seed that will make any outcome we want - just enumerate few random seeds that would give us desired outcome. Even if we would somehow publish a hash of this seed - you cannot be sure that hash you see is for the seed that you will get when you bet, since any other player might use this seed before you.

[vlees]

Why wouldn't it make sense to create a different server seed beforehand for each game and after it is used, immediately publish it?

Just wonder how will you check it? You decide to check our honesty - you check the client seed, remember it, you make a bet - and check what was the server seed - seems ok? But it isn't in this scenario we could just easily fool you by using any seed that will make any outcome we want - just enumerate few random seeds that would give us desired outcome. Even if we would somehow publish a hash of this seed - you cannot be sure that hash you see is for the seed that you will get when you bet, since any other player might use this seed before you.

But if a player uses that hash just before me, I could easily confirm this on the right side. Now you can say: doesn't prove anything since we could already do this.

Well with your current implementation you could also skip hashes from the batch and add fake bets to the right to compensate.

[xyu]

Why wouldn't it make sense to create a different server seed beforehand for each game and after it is used, immediately publish it?

Just wonder how will you check it? You decide to check our honesty - you check the client seed, remember it, you make a bet - and check what was the server seed - seems ok? But it isn't in this scenario we could just easily fool you by using any seed that will make any outcome we want - just enumerate few random seeds that would give us desired outcome. Even if we would somehow publish a hash of this seed - you cannot be sure that hash you see is for the seed that you will get when you bet, since any other player might use this seed before you.

But if a player uses that hash just before me, I could easily confirm this on the right side. Now you can say: doesn't prove anything since we could already do this.

Well with your current implementation you could also skip hashes from the batch and add fake bets to the right to compensate.

Sorry, but I don't follow what you trying to say - have you found any significant flaw in this scheme compared to to others or you suggesting an better solution? We can't skip hashes from the batch, because they are taken sequentially

[BRules]

Sorry, but I don't follow what you trying to say - have you found any significant flaw in this scheme compared to to others or you suggesting an better solution? We can't skip hashes from the batch, because they are taken sequentially

you can skip it by simulating a play before mine for example.

it is all embedded right into html and is not minified, so you can inspect the code.

The problem with this aproach, is that everytime I access your site I will have to check the code to see if you didn't change it. Will be way better if you implement a way for us to change it.

But it isn't in this scenario we could just easily fool you by using any seed that will make any outcome we want - just enumerate few random seeds that would give us desired outcome. Even if we would somehow publish a hash of this seed - you cannot be sure that hash you see is for the seed that you will get when you bet, since any other player might use this seed before you.

The seed can't be global, but attached to the session. IMO, the best way to do it is to generate a seed to our session, show it to the user just before any bet, provide a way so we can set our client seed and after the bet generate another server seed to the next bet.

[Mooshire]

What happens if the bank gets so small that people don't want to bet anymore?

[vlees]

I agree with everything BRules said.

Nice concept of the site though!

[001sonkit]

Now wait for a genius to play the EV up

[xyu]

The problem with this aproach, is that everytime I access your site I will have to check the code to see if you didn't change it. Will be way better if you implement a way for us to change it.

Yep. added to the todo.

The seed can't be global, but attached to the session. IMO, the best way to do it is to generate a seed to our session, show it to the user just before any bet, provide a way so we can set our client seed and after the bet generate another server seed to the next bet.

Okay, I'm gonna think on it.

[BRules]

another problem I see is that if a payout % is lower than 99% , why would I play at your site instead of just-dice for example that will always give me 99% return if I win?

[vlees]

Now wait for a genius to play the EV up

Oh, had nothing to do at work today so I played the 0.003 up to 225% and someone quickly took it

[xyu]

another problem I see is that if a payout % is lower than 99% , why would I play at your site instead of just-dice for example that will always give me 99% return if I win?

Because it doesn't work like a dice game - that's the whole point, lets consider the following example:
We have a 1BTC bet, with the payout 50%, you may think that this is not a nice situation to get in the game, but actually you could have the following strategy
1. Ensure you have enough balance to make something like 5-6 bets (i.e. 5-6 BTC), lets say we have 5 btc
2. Start betting, if you have lost, bank will have 2 btc and payout will be 100% and you have 4 btc in balance
3. You can continue to bet, if you lost again you will have 3 btc in balance and bank will be 3btc and payout is 150%
4. As you can see bank and payout are heavily depend on the current streak if it is all loses - it will quickly grow, but if it all wins you can quickly recover all loses, and the more you lose the higher probability to win. Also bank grows in arithmetic progression and decreases in geometric.
5. Lets say you bet again and you win, you won 1.5 btc, your balance now is 4.5 btc and bank is 1.5 btc
6. You bet again and you won 0.75 btc and you balance will be 5.25 BTC - it is already higher than you had when you started!



So to sum up: in dice games it all about luck, here you can have some strategy, but because this is gambling no one guaranteeing that there is a strategy that will always make you money, for instance some dude could watch the site while you making these bets and he could just make a bet in between your bets and win.

And if this thing will take of, be sure it wouldn't be people who play it but bots. Lol, I was even thinking that I should take some time and release a bot at the same time with the game so that people will be equal in their chances But I already had a deadline for this thing a week ago, so I just had released it without any fancy bots

[vlees]

the more you lose the higher probability to win

Sounds like gambler's fallacy to me.

[xyu]

the more you lose the higher probability to win

Sounds like gambler's fallacy to me.

Maybe I wasn't clear enough: it is not the probability of winning is higher - it is always 50% it is the chances to win you money back because you decrease the bank in geometric progression.