Topic: Provably Fair isn't fair for Investors [System Idea] Server seed+Concealed Info (Read 711 times)

So:

1. Round has server seed, players get hash of it.
2. Players select blocks and only send hash to server. Got x seconds to do this.
3. After that site broadcasts all hashes of players, so player/investor can copy-paste this. For let's say 5 seconds. Players/site owner cannot change the bets because others have hash of it.
4. Then players send their actual blocks/bet.
5. With this the result is calculated (server seed hashed x times based on combined number of blocks - obviously hashed in different method then first hash :> )
6. With all the information you can verify if: server seed was really used, players didn't change their blocks and bet results of players.

In theory I like it.

Few problems:

- Most people like fast bets (dice sites) and this will be just too slow for them.
- It would only work for the most popular gambling sites. Because new sites will have only 1 player at the time frequently and if that player is the site owner he can still know the results in advance.
- Investors gotta be online 24/7 to really verify all rounds themselves, but in theory if multiple investors do it randomly sometimes, it's better than nothing.
- What will happen if player is disconnected in the time between sending hash and actual bets If their bets get cancelled, site owner can pretend to be disconnected player and cancel his bet if it was a loss. If it's default loss or some delay, players will complain.

But I always like new theories so nice idea overall.

We are talking about PC doing maths (scripts), not humans =p
everything is about miliseconds.

When a gamble website change the your prob rate to smooth steal clients, Do you think the "owner, (the people)" do it? no... it's a simple script on server, if user profit more than 200% do something.

Hey, hmm i think your idea has some fail points...

Because if the "Hash" giving is changing, it's easier to server manipulate it..., this things about changing the hash everytime someone make a new bet... for a PC, it takes less then 1milisecond to calculate. If you the Server Host you can always calculate where you need to "Fake bet" to get the most profit for yourself.

For exemple, 30 seconds like you said... when times goes to 29.99s, server try some bets using script and check what's the profit for each possibilities, because you already have all past bets hash compilation. And in the last instant you bet on where you want to generate the profit. or you can let the 30seconds run, but ONLY on the server you can bet at 31s (acting as a normal user) (if you need more time to calculate using script), website show 30s, but on really no one know how the server will run internal.

I am talking from the host perception not the player perception.

As the host of the gambling site you know the results. However you can't cheat on a non investor gambling site without invalidating hashes, and giving it away.
And thus making it known to the community your site as a cheater.

The key point here is there are gambling sites that have an investor feature. Where people invest as a bank roll, and players play against the bank roll.
The host can sign up as a player on the site. And knowing the server seed + client seed + player seed can cheat as the player, stealing funds from the investor
roll. Without the investors ever knowing what happened.

On a normal gambling site, you don't have investors, your just the host, and players playing against the house. This is layed out differently. And works fine.

I am adding a uncertainty feature to the server seed, by mixing the amount of actions the user did on the round. To prevent the server from knowing the player actions, and thus giving you the result already as the host for cheating, you hash the player actions, and give the server the hash of the player actions. When the round ends, you reveal to the server the amount of actions you did and verify this up against the hash that was submitted, if it verifies, you mix this with the other players
and the server seed generating a brand new server seed, and from there you get the round results.

This is my idea.

But that is not how provably fair games work right? Ive researched a bit and   

''The server seed is unknown, but the hash is revealed. The client seed is something you set, after the server seed has already been generated.
''

As you know, you are in control of your server seed. If you are the host of a provably fair investor site, you
can know the results, and play as a player and steal from the investors.

However I thought of an idea, and I like to hear some opinions on whether this works or not.
Lets imagine a site with 50 squares, a player can play on any of the squares. Draw out
patterns, and bet in what ever form he wishes.

Lets make the round 30 seconds long. The player makes a selection on squares of 1,5,7,12,16
for total of 5 squares out of 50. And places a bet of .01 BTC on each.

My scheme involves adding an uncertainty to the server seed as a component with locking bets.
How it works.

Player makes selection 1,5,7,12,16.
We hash his bets, and submit that hash to the server to be used later.
When the round ends, the player submits which bets lead up to that hash as a verification.

Lets say there are 3 players.

Player one makes 1,5,7,12,16 (5)
Player two makes 2,5,3 (3)
Player there makes 5,8,16 (3)

We take each bet they done as a independent action and rehash the server seed that many following times, after their bets have been locked.
Adding the above you get 11 actions in total.

Original: 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08
Sha(Original) = 7b3d979ca8330a94fa7e9e1b466d8b99e0bcdea1ec90596c0dcc8d7ef6b4300c (step 1)

You do this 11 times, and using this seed you determine the results for the round.
They key point here is as host you will not know how many actions there will be in a given round.
And thus won't know what the final result will be.

If you create an account, and try to cheat the system, you first have to lock in your bet, then round ends.
Then the server seed is rehashed X times depending on actions, then after that is the determined results for the round.

Or perhaps an even better method is after the players submitted their hash of their bets. When the round ends, the player reveals what lead to that hash,
the server verifies if this = The hash they submitted of their bets during the round. Then If it verifies, then take the betting data from all the players
of (server seed) + Bet 1,5,7,12,16 + Bet 2,5,3, etc. Then mix this into a new sever seed. And thus the results.

Initially the server only receives the hash, and is concealed of the players bet. The results being revealed to the server after the round ends, and mixing this
for the draw happening later on. Determines the outcome of the draw, and thus the results.