Dice64 - Off Blockchain. Provably fair. Instantly verifiable. 0.9% Edge

[dice64]

The service does not publish your return or deposit addresses, to protect your identity.

what kind of identity are you trying to protect not publishing it?

Peoples unspent tx outputs, which may link to their real name and identity and the coins could certainly be traced further, showing many transactions they have made with other people.

[1715276329]

1715276329

[1715276329]

1715276329

[1715276329]

1715276329

[1715276329]

1715276329

[Zaih]

Hey, I've noticed you assign the server seed (Well, hash), and you only let the user choose a nonce.

The nonce can only be number 1 - 99999, what's stopping you assigning server seeds which when applied to a nonce, have a lot higher average roll. You can quickly test all 99,999 instantly, and then only assign ones which have an average roll of lets say 36? That's definitely possible.

To fix this, you should allow the user to choose whether they want to roll high or low.

Just my 2 cents

[Insanity]

I think you forgot to mention that insanity dice is the only other provably fair option.  We use camtasia to record all bets to make sure none are rigged.

[vlees]

I think you forgot to mention that insanity dice is the only other provably fair option.  We use camtasia to record all bets to make sure none are rigged.

Wow, good thinking! I totally forgot that videos can't be edited. Will play at Insanity Dice Extreme soon.

[dice64]

Hey, I've noticed you assign the server seed (Well, hash), and you only let the user choose a nonce.

The nonce can only be number 1 - 99999, what's stopping you assigning server seeds which when applied to a nonce, have a lot higher average roll. You can quickly test all 99,999 instantly, and then only assign ones which have an average roll of lets say 36? That's definitely possible.

To fix this, you should allow the user to choose whether they want to roll high or low.

Just my 2 cents

The output is calculated as follows, the nonce is a 16-bit integer 1-65536 and is generated in Javascript in the browser, the user can also set the nonce themselves, rolling high or low wouldn't make any difference to how fair it is. We can't assign secrets which have an average result, as any input is nonced by the user. The server seed can also be refreshed to a 256 bit number generated from random. Even if we did generate fixed secrets, the user would always nonce it in a way which completely changed the result through using dsha256(secret + nonce).

Here is a json list of the result frequency. bet_frequency_post_nonce is the actual results calculated with the nonce added. bet_frequency_pre_nonce is what the result would have been if the user was allowed to place a bet with a nonce of 0, this is the same as performing mod 64 on the secret_hash.

https://dice64.com/api/bets?pretty

Code:

secret = random integer 0 - 2256
secret_hash = dsha256(secret)

combined_number = secret + nonce
combined_hash = dsha256(combined_number)
result = combined_hash mod 64

[Zaih]

Hey, I've noticed you assign the server seed (Well, hash), and you only let the user choose a nonce.

The nonce can only be number 1 - 99999, what's stopping you assigning server seeds which when applied to a nonce, have a lot higher average roll. You can quickly test all 99,999 instantly, and then only assign ones which have an average roll of lets say 36? That's definitely possible.

To fix this, you should allow the user to choose whether they want to roll high or low.

Just my 2 cents

The output is calculated as follows, the nonce is a 16-bit integer 1-65536 and is generated in Javascript in the browser, the user can also set the nonce themselves, rolling high or low wouldn't make any difference to how fair it is. We can't assign secrets which have an average result, as any input is nonced by the user. The server seed can also be refreshed to a 256 bit number generated from random. Even if we did generate fixed secrets, the user would always nonce it in a way which completely changed the result through using dsha256(secret + nonce).

Here is a json list of the result frequency. bet_frequency_post_nonce is the actual results calculated with the nonce added. bet_frequency_pre_nonce is what the result would have been if the user was allowed to place a bet with a nonce of 0, this is the same as performing mod 64 on the secret_hash.

https://dice64.com/api/bets?pretty

Code:

secret = random integer 0 - 2256
secret_hash = dsha256(secret)

combined_number = secret + nonce
combined_hash = dsha256(combined_number)
result = combined_hash mod 64

There's only 65536 different nonces a user can apply. You give the users secrets which when all those different nonces are applied, has a higher average, or more losses depending on the game they're playing. This will inherently change the odds advertised.

[dice64]

There's only 65536 different nonces a user can apply. You give the users secrets which when all those different nonces are applied, has a higher average, or more losses depending on the game they're playing. This will inherently change the odds advertised.

The secret is given out before the player chooses a number to play on, so is your concern that we could only chose secrets which were more likely end up with a high number when being nonced with every number in the range 1-65536? This is certainly possible, but computationally impractical.

In our tests performing dsha256(secret + nonce), where nonce is in the range 1-65536 gave quite an evenly random distribution. If necessary we can increase the size of the nonce field, maybe 32-bits would provide a more even distribution.

Edit: Valid point. I'll increase the size of the nonce.
Edit again: Nonce fields are now 32 bits, this is working in the api, but the html and javascript are cached and will clear in the browser after an hour.

[vlees]

Edit again: Nonce fields are now 32 bits, this is working in the api, but the html and javascript are cached and will clear in the browser after an hour.

A shift+F5 fixed it for me.

[Zaih]

There's only 65536 different nonces a user can apply. You give the users secrets which when all those different nonces are applied, has a higher average, or more losses depending on the game they're playing. This will inherently change the odds advertised.

The secret is given out before the player chooses a number to play on, so is your concern that we could only chose secrets which were more likely end up with a high number when being nonced with every number in the range 1-65536? This is certainly possible, but computationally impractical.

In our tests performing dsha256(secret + nonce), where nonce is in the range 1-65536 gave quite an evenly random distribution. If necessary we can increase the size of the nonce field, maybe 32-bits would provide a more even distribution.

Edit: Valid point. I'll increase the size of the nonce.
Edit again: Nonce fields are now 32 bits, this is working in the api, but the html and javascript are cached and will clear in the browser after an hour.

Still not amazingly solid (Like you claim in your OP), just means you might have to go through 10,000 server seeds opposed to 100 to find one with a high level of inconsistency.

Just do what JD does.

[vlees]

There's only 65536 different nonces a user can apply. You give the users secrets which when all those different nonces are applied, has a higher average, or more losses depending on the game they're playing. This will inherently change the odds advertised.

The secret is given out before the player chooses a number to play on, so is your concern that we could only chose secrets which were more likely end up with a high number when being nonced with every number in the range 1-65536? This is certainly possible, but computationally impractical.

In our tests performing dsha256(secret + nonce), where nonce is in the range 1-65536 gave quite an evenly random distribution. If necessary we can increase the size of the nonce field, maybe 32-bits would provide a more even distribution.

Edit: Valid point. I'll increase the size of the nonce.
Edit again: Nonce fields are now 32 bits, this is working in the api, but the html and javascript are cached and will clear in the browser after an hour.

Still not amazingly solid (Like you claim in your OP), just means you might have to go through 10,000 server seeds opposed to 100 to find one with a high level of inconsistency.

Just do what JD does.

But instead of having to hash 0xffff strings to find out which one has a high chance of winning for the house he would have to do 0xffffffff now. Which is practically impossible to do at this speed.

[dice64]

Still not amazingly solid (Like you claim in your OP), just means you might have to go through 10,000 server seeds opposed to 100 to find one with a high level of inconsistency.

Just do what JD does.

I've upped it to 32 bits, 4294967296 possibilities for the nonce, which should be enough for now. I'm not sure how well javascript would handle anything larger than 32-bit integers, so I'll have to test and see about increasing it.

I don't want to change to a high/low method as that would mean an API structure change. Besides JD could just as easily notice that you bet low most of the time and create a secret which is more likely to give high outputs, or that you bet high so they could make a low secret.

Secrets are chosen at random by the server, because they're computationally easier to generate that way than to pick a number, see if what sort of result it provides against a 16 or 32 bit nonce and then publish. Any method of pre-generating secrets is now computationally impractical, without using an ASIC for it. Even then, on a 5GHash machine, we'd only be able to generate 1 full secret profile after it has been nonced per second.

[vlees]

Still not amazingly solid (Like you claim in your OP), just means you might have to go through 10,000 server seeds opposed to 100 to find one with a high level of inconsistency.

Just do what JD does.

I've upped it to 32 bits, 4294967296 possibilities for the nonce, which should be enough for now. I'm not sure how well javascript would handle anything larger than 32-bit integers, so I'll have to test and see about increasing it.

I don't want to change to a high/low method as that would mean an API structure change. Besides JD could just as easily notice that you bet low most of the time and create a secret which is more likely to give high outputs, or that you bet high so they could make a low secret.

Secrets are chosen at random by the server, because they're computationally easier to generate that way than to pick a number, see if what sort of result it provides against a 16 or 32 bit nonce and then publish. Any method of pre-generating secrets is now computationally impractical, without using an ASIC for it. Even then, on a 5GHash machine, we'd only be able to generate 1 full secret profile after it has been nonced per second.

Or you allow people to allow ANY string at all, then take the hash of your secret concatenated with whatever the user typed in. Then the user can type in his nice 100 character unicode string which you cannot possibly predict and everyone is happy.

[dice64]

Or you allow people to allow ANY string at all, then take the hash of your secret concatenated with whatever the user typed in. Then the user can type in his nice 100 character unicode string which you cannot possibly predict and everyone is happy.

We could do this, but a limit has to placed somewhere, what happens when someone wants to nonce it with a 100MB string, the service would have to parse and store it for an amount of time, while consuming precious resources. 32 bits offers 4.29 billion possibilities. Which should be enough for now. 

Also we don't currently do string concatenation for calculating the results, everything is done in raw byte format. I've seen many services that use the + operator on strings to concatenate, where a nonce should actually increment the data, not be appended to it.

[vlees]

where a nonce should actually increment the data, not be appended to it.

Tell the Bitcoin developers about that. They just append the nonce in the header.

[Boelens]

Just made a deposit, I can't gamble though. First it said something about the seed, now I get an error saying : Secret hash does not match the value on the server
EDIT: Works now after refreshing! I accidentally did a bet of 1.18 mBTC on <10, and it <10. Sorry, I'm hurting your bankroll :S I hope the max bet gets increased in the future.

[vlees]

and also then limit it to 32*8 bit for the user to enter (instead of unlimited). So the user can enter ANYTHING and is not limited by the site operator.

[Boelens]

I can't bet anymore, I keep getting internal server errors.

[vlees]

I can't bet anymore, I keep getting internal server errors.

The only time I had that was when I forgot to enter a client seed/nonce.

[dice64]

I can't bet anymore, I keep getting internal server errors.

I've taken it offline while I update the database. I'll automatically release your current balance back to your return address in a few minutes.

[Boelens]

I can't bet anymore, I keep getting internal server errors.

I've taken it offline while I update the database. I'll automatically release your current balance back to your return address in a few minutes.

that's strange, it's been more then a few minutes and it's not back yet.
EDIT: It's back.