DiceVsDice.com BTC Gambling Site • #1 Player Vs Player BTC • Provably Fair

[game-protect]

How much is your house edge?

[1714770351]

1714770351

[1714770351]

1714770351

[1714770351]

1714770351

[1714770351]

1714770351

[DiceVSDice.com]

Hey, There is NO house edge. You playing vs Real Player, Its means you have 50% chance to win (As him).
However, There is 2% Tax on every game.

[BTCevo]

Hey, There is NO house edge. You playing vs Real Player, Its means you have 50% chance to win (As him).
However, There is 2% Tax on every game.

2% fee is like house edge as I know because on the dice site with house edge we can choose 50% chance to win too but it lowered our payout so I think it will be just the same if you said there is no house edge but put higher fee on this tax on every games too. This is just matter of how we look into this game

[NLNico]

Without depositing or playing, it says:

"Your next roll hash: 1eeaac1b05a5.."

Can you tell me how that is possible? If it is player vs player, I would imagine the other player would also see some kind of roll hash.. but I guess a different one? (since I didn't even select any amount.) Basically I am looking for information about your provably fair implementation.

Normally P2P provably fair would work with hashed client seeds, where both first send their hashed client seeds and bets, then the unhashed client seeds to calculate the winner. AFAIK no serverseed is needed (nor possible with P2P.)

Hey,
Your next roll, no matter the lobby is predetermined and hashed.
You are shown the hashed version of your next roll.
Each time you play, a new roll and therefore its hash will be generated.
Each player will have a unique hash every game as the roll data is hashed with a salt.
After a game is complete, both players decoded hash is shown to both players to prove that it is fair.

So the 2 players that play against each other have a different roll? How is the roll calculated? Do you have a provably fair info page so it's easy to figure this out?

Either way I am sure it's not actually provably fair, but I first want to understand how you guys calculate the result

[Caladonian]

Without depositing or playing, it says:

"Your next roll hash: 1eeaac1b05a5.."

Can you tell me how that is possible? If it is player vs player, I would imagine the other player would also see some kind of roll hash.. but I guess a different one? (since I didn't even select any amount.) Basically I am looking for information about your provably fair implementation.

Normally P2P provably fair would work with hashed client seeds, where both first send their hashed client seeds and bets, then the unhashed client seeds to calculate the winner. AFAIK no serverseed is needed (nor possible with P2P.)

Hey,
Your next roll, no matter the lobby is predetermined and hashed.
You are shown the hashed version of your next roll.
Each time you play, a new roll and therefore its hash will be generated.
Each player will have a unique hash every game as the roll data is hashed with a salt.
After a game is complete, both players decoded hash is shown to both players to prove that it is fair.

So the 2 players that play against each other have a different roll? How is the roll calculated? Do you have a provably fair info page so it's easy to figure this out?

Either way I am sure it's not actually provably fair, but I first want to understand how you guys calculate the result

Yeah thats also what i seen from the system how we can be assured whether the same time the two players roll the dice seems its really needed to be explain well with the players that wanted to try your service, ill be going to watch how players will give feedbacks with this unique dice site.

[DiceVSDice.com]

Without depositing or playing, it says:

"Your next roll hash: 1eeaac1b05a5.."

Can you tell me how that is possible? If it is player vs player, I would imagine the other player would also see some kind of roll hash.. but I guess a different one? (since I didn't even select any amount.) Basically I am looking for information about your provably fair implementation.

Normally P2P provably fair would work with hashed client seeds, where both first send their hashed client seeds and bets, then the unhashed client seeds to calculate the winner. AFAIK no serverseed is needed (nor possible with P2P.)

Hey,
Your next roll, no matter the lobby is predetermined and hashed.
You are shown the hashed version of your next roll.
Each time you play, a new roll and therefore its hash will be generated.
Each player will have a unique hash every game as the roll data is hashed with a salt.
After a game is complete, both players decoded hash is shown to both players to prove that it is fair.

So the 2 players that play against each other have a different roll? How is the roll calculated? Do you have a provably fair info page so it's easy to figure this out?

Either way I am sure it's not actually provably fair, but I first want to understand how you guys calculate the result

This game uses “roll hashes” to prove itself.

Roll hashes are how DiceVsDice proves that each player's roll is chosen before the game is played and are not tampered with. Hashes thus prove to the player that the game is fair.

When a new round is started, each players will play their next roll which has been predetermined and encoded. The decoded hash consists of the 2 dice rolls coupled with a random string generated by the server - this hash is encoded with SHA256. The result of the hash function is shown to you before you play a game.

Validating the fairness

After a game has been completed, the "dice1-dice2+random string" secret will be revealed. It is at this point you may validate that the SHA256 hash of the secret matches the hash that has been shown since the beginning of the round.
http://www.xorbin.com/tools/sha256-hash-calculato

[NLNico]

What is "dice1" and "dice2"? I assume your and your opponent's result, right? So:

1) How is it possible that you show the hash already before I join a game? My opponent's result cannot be known yet?
2) How is it possible that: "Each player will have a unique hash" if it's player vs player where both players would have the same result/rolls?




Besides this, it's still not provably fair.. it's very easy for you to just generate hashes that ensure that the opponent (which could be a "site-player") has a higher roll result. Just because you "hash" things, doesn't make it provably fair.

A proper P2P provably fair implementation should work like this:
1) Both players join a game (player 1 is who started game, player 2 who accepted game).
2) Both players send a hashed version of their clientseed that was generated randomly in their browser with a cryptographically secure RNG.
3) After receiving the opponent's hashed clientseed (and showing it to the player - ideally with some seconds to copy it), they send their clientseed but now unhashed.
4) Site can already calculate result based on that.. for example use some HMAC function to generate a hash based on both clientseeds (player 1 is key, player 2 is message) and loop 2 dice results out of that (first roll is player 1, second is player 2.) A bit like regular dice games.
5) Send result + unhashed clientseeds to both players. They now know the result and can calculate the results themselves (and should be done automatically in browser too.)

This way, you - as site owner - cannot "pretend" to be a player and cheat. Therefor it is actually provably fair.




PS, I absolutely do not accuse you of cheating.. just to be clear But if you have a provably fair implementation, it should be really provably fair. GL.

[DiceVSDice.com]

Hey,
dice 1 and dice 2 are your 2 rolls. you do not know what your opponents results are until after the game.

[NLNico]

Ah okay, tbh, doesn't really matter.

In the end provably fair is about ensuring that the player can verify that he has not been cheated. In your implementation you could pretend to be the opponent and you could simply generate a higher result for yourself. There is no way for the player to verify this and therefor it is not provably fair.

I am not accusing you of this, but like I said, it simply is not provably fair right now. Therefor I recommend you use the implementation as I suggested in my previous post.