GigaDice.com | 1% House-Edge | FREE BTC | PayPal, Bitcoin, PerfectMoney Cashouts

[irequirefilth]

already signed up

username:burzki

thanks in advance

[wayneyoyo]

signup , username : wayne
thanks

[pie3636]

Username : Anfasa
Thanks!

[GigaDice]

I have accredited every account I missed, hope you guys enjoy the site.

[ASICSRUS]

BANNED in the U.S. bummer! 

[eMoxes]

you missed me , emox

[GigaDice]

you missed me , emox

I have not, please check your balance here

[GigaDice]

Thought I'd add a few more pictures of Gigadice 2.0 as I've gotten a few PM's regarding it.

[Mooshire]

Thought I'd add a few more pictures of Gigadice 2.0 as I've gotten a few PM's regarding it.

Are you going to consider adding inputs.io?

[saif313]

Thought I'd add a few more pictures of Gigadice 2.0 as I've gotten a few PM's regarding it.

Are you going to consider adding inputs.io?

but inputs.io have many troubles around there most of time

[Mooshire]

Thought I'd add a few more pictures of Gigadice 2.0 as I've gotten a few PM's regarding it.

Are you going to consider adding inputs.io?

but inputs.io have many troubles around there most of time

It's only having trouble right now, normally it works great.

[knowitnothing]

For what's worth, so far you have entirely sidestepped the discussion regarding the provably fair method used at gigadice. Can't you clearly explain it ?

Anyway, here is how I understood the process. For this example I took the bets 1 and 8 at http://gigadice.com/verification.php?betid=1 and http://gigadice.com/verification.php?betid=8. Bet 1 rolled 18.71 with user seed 208606, Bet 8 rolled 56.03 with user seed 597414. To check the outcome is the expected one, concatenate the rolled number, the user seed, and the daily secret of 61f476d793488e3d47fd348011c203084c60be24 for these rolls. Apply SHA 512 on the concatenated message and take the hex digest, if they match the one published at "Server Seed (Hash) for that Roll" for that bet, then the result is the expected one. For these rolls, the hashes match -- EXCEPT it is missing the most important step: WHAT did it do to roll 18.71 and 56.03 there ?

There are yet two other issues about how you're handling this (beyond not properly answering it earlier). First issue: the hash of the daily secret 61f476d793488e3d47fd348011c203084c60be24 is not shown anywhere, if it is I can't find it. Second issue regards the way you describe your method, if it is done exactly as specified there, then it is not provably fair again.

Here is the part that is wrong in every instance: """Prior to betting, you receive a "Server Seed" and a "Client Seed." The Server Seed is a combination of your roll, your client seed, and our secret - hashed""". This is telling me I get a user seed before the bet is placed, it doesn't clearly say that the player sends its own seed. /If/ it is not the player who specifies his seed, then it is not provably fair and it should be obvious why that is the case. The description regarding "Server seed" is also confusing, but I mentioned this in an earlier post.

Since this is relatively long, let me resume: 1) you are not describing how the rolled number is picked; 2) the way you describe "user seed" makes it not provably fair; 3) "server seed" is confusing as it is not a seed of anything.

[GigaDice]

For what's worth, so far you have entirely sidestepped the discussion regarding the provably fair method used at gigadice. Can't you clearly explain it ?

Anyway, here is how I understood the process. For this example I took the bets 1 and 8 at http://gigadice.com/verification.php?betid=1 and http://gigadice.com/verification.php?betid=8. Bet 1 rolled 18.71 with user seed 208606, Bet 8 rolled 56.03 with user seed 597414. To check the outcome is the expected one, concatenate the rolled number, the user seed, and the daily secret of 61f476d793488e3d47fd348011c203084c60be24 for these rolls. Apply SHA 512 on the concatenated message and take the hex digest, if they match the one published at "Server Seed (Hash) for that Roll" for that bet, then the result is the expected one. For these rolls, the hashes match -- EXCEPT it is missing the most important step: WHAT did it do to roll 18.71 and 56.03 there ?

There are yet two other issues about how you're handling this (beyond not properly answering it earlier). First issue: the hash of the daily secret 61f476d793488e3d47fd348011c203084c60be24 is not shown anywhere, if it is I can't find it. Second issue regards the way you describe your method, if it is done exactly as specified there, then it is not provably fair again.

Here is the part that is wrong in every instance: """Prior to betting, you receive a "Server Seed" and a "Client Seed." The Server Seed is a combination of your roll, your client seed, and our secret - hashed""". This is telling me I get a user seed before the bet is placed, it doesn't clearly say that the player sends its own seed. /If/ it is not the player who specifies his seed, then it is not provably fair and it should be obvious why that is the case. The description regarding "Server seed" is also confusing, but I mentioned this in an earlier post.

Since this is relatively long, let me resume: 1) you are not describing how the rolled number is picked; 2) the way you describe "user seed" makes it not provably fair; 3) "server seed" is confusing as it is not a seed of anything.

What you're suggesting is implementing a system where the site would be not only be provably fair but have provable results as the user seed would directly influence the outcome of the roll. I see you have managed to test our current system and have done so correctly. In regards to your question about the "client seed" and not having it directly influence the roll it is not necessary to be labled provably fair albeit it would improve our transparency. Which is why we have already discussed implementation of the aforementioned provably fair system. The daily secrets can be found here. It would be impossible or very illogical to force the user into submitting a client seed every bet, we do however allow users if they feel the need to change it if they feel the need to. If you're wondering how the rolls are determined it is through a simple php rand function.

[knowitnothing]

For what's worth, so far you have entirely sidestepped the discussion regarding the provably fair method used at gigadice. Can't you clearly explain it ?

Anyway, here is how I understood the process. For this example I took the bets 1 and 8 at http://gigadice.com/verification.php?betid=1 and http://gigadice.com/verification.php?betid=8. Bet 1 rolled 18.71 with user seed 208606, Bet 8 rolled 56.03 with user seed 597414. To check the outcome is the expected one, concatenate the rolled number, the user seed, and the daily secret of 61f476d793488e3d47fd348011c203084c60be24 for these rolls. Apply SHA 512 on the concatenated message and take the hex digest, if they match the one published at "Server Seed (Hash) for that Roll" for that bet, then the result is the expected one. For these rolls, the hashes match -- EXCEPT it is missing the most important step: WHAT did it do to roll 18.71 and 56.03 there ?

There are yet two other issues about how you're handling this (beyond not properly answering it earlier). First issue: the hash of the daily secret 61f476d793488e3d47fd348011c203084c60be24 is not shown anywhere, if it is I can't find it. Second issue regards the way you describe your method, if it is done exactly as specified there, then it is not provably fair again.

Here is the part that is wrong in every instance: """Prior to betting, you receive a "Server Seed" and a "Client Seed." The Server Seed is a combination of your roll, your client seed, and our secret - hashed""". This is telling me I get a user seed before the bet is placed, it doesn't clearly say that the player sends its own seed. /If/ it is not the player who specifies his seed, then it is not provably fair and it should be obvious why that is the case. The description regarding "Server seed" is also confusing, but I mentioned this in an earlier post.

Since this is relatively long, let me resume: 1) you are not describing how the rolled number is picked; 2) the way you describe "user seed" makes it not provably fair; 3) "server seed" is confusing as it is not a seed of anything.

...
It would be impossible or very illogical to force the user into submitting a client seed every bet, we do however allow users if they feel the need to change it if they feel the need to. If you're wondering how the rolls are determined it is through a simple php rand function.

Wow, take some time and think about what you just wrote there. How can the user possibly know that the roll was done in a provably fair manner considering what you just wrote ? Here is the result of "a simple php rand function": 32, who can you know I did it in a fair manner ? You (the player actually) have no way to check that with this current method.

Pay attention to this: neither the user seed nor the daily secret have any effect in the rolled number. If you know of any site that do this, you picked the wrong example to follow.

[monbux]

I can't log in to my account anymore, is it because all accoutns were deleted?

[GigaDice]

For what's worth, so far you have entirely sidestepped the discussion regarding the provably fair method used at gigadice. Can't you clearly explain it ?

Anyway, here is how I understood the process. For this example I took the bets 1 and 8 at http://gigadice.com/verification.php?betid=1 and http://gigadice.com/verification.php?betid=8. Bet 1 rolled 18.71 with user seed 208606, Bet 8 rolled 56.03 with user seed 597414. To check the outcome is the expected one, concatenate the rolled number, the user seed, and the daily secret of 61f476d793488e3d47fd348011c203084c60be24 for these rolls. Apply SHA 512 on the concatenated message and take the hex digest, if they match the one published at "Server Seed (Hash) for that Roll" for that bet, then the result is the expected one. For these rolls, the hashes match -- EXCEPT it is missing the most important step: WHAT did it do to roll 18.71 and 56.03 there ?

There are yet two other issues about how you're handling this (beyond not properly answering it earlier). First issue: the hash of the daily secret 61f476d793488e3d47fd348011c203084c60be24 is not shown anywhere, if it is I can't find it. Second issue regards the way you describe your method, if it is done exactly as specified there, then it is not provably fair again.

Here is the part that is wrong in every instance: """Prior to betting, you receive a "Server Seed" and a "Client Seed." The Server Seed is a combination of your roll, your client seed, and our secret - hashed""". This is telling me I get a user seed before the bet is placed, it doesn't clearly say that the player sends its own seed. /If/ it is not the player who specifies his seed, then it is not provably fair and it should be obvious why that is the case. The description regarding "Server seed" is also confusing, but I mentioned this in an earlier post.

Since this is relatively long, let me resume: 1) you are not describing how the rolled number is picked; 2) the way you describe "user seed" makes it not provably fair; 3) "server seed" is confusing as it is not a seed of anything.

...
It would be impossible or very illogical to force the user into submitting a client seed every bet, we do however allow users if they feel the need to change it if they feel the need to. If you're wondering how the rolls are determined it is through a simple php rand function.

Wow, take some time and think about what you just wrote there. How can the user possibly know that the roll was done in a provably fair manner considering what you just wrote ? Here is the result of "a simple php rand function": 32, who can I know I did it in a fair manner ? You (the player actually) have no way to check that with this current method.

Pay attention to this: neither the user seed nor the daily secret have any effect in the rolled number. If you know of any site that do this, you picked the wrong example to follow.

I have answered this multiple time at the moment the client seed doesn't affect affect the roll but we're looking to implement it in the future. I'm looking to ways to increase our provability and transparency and very much appreciate your feedback.


@Monbux, we wiped the database when we launched officially meaning all accounts in the BETA were deleted. Please re register and I will accredit you with some balance for participating in our BETA.

[knowitnothing]

For what's worth, so far you have entirely sidestepped the discussion regarding the provably fair method used at gigadice. Can't you clearly explain it ?

Anyway, here is how I understood the process. For this example I took the bets 1 and 8 at http://gigadice.com/verification.php?betid=1 and http://gigadice.com/verification.php?betid=8. Bet 1 rolled 18.71 with user seed 208606, Bet 8 rolled 56.03 with user seed 597414. To check the outcome is the expected one, concatenate the rolled number, the user seed, and the daily secret of 61f476d793488e3d47fd348011c203084c60be24 for these rolls. Apply SHA 512 on the concatenated message and take the hex digest, if they match the one published at "Server Seed (Hash) for that Roll" for that bet, then the result is the expected one. For these rolls, the hashes match -- EXCEPT it is missing the most important step: WHAT did it do to roll 18.71 and 56.03 there ?

There are yet two other issues about how you're handling this (beyond not properly answering it earlier). First issue: the hash of the daily secret 61f476d793488e3d47fd348011c203084c60be24 is not shown anywhere, if it is I can't find it. Second issue regards the way you describe your method, if it is done exactly as specified there, then it is not provably fair again.

Here is the part that is wrong in every instance: """Prior to betting, you receive a "Server Seed" and a "Client Seed." The Server Seed is a combination of your roll, your client seed, and our secret - hashed""". This is telling me I get a user seed before the bet is placed, it doesn't clearly say that the player sends its own seed. /If/ it is not the player who specifies his seed, then it is not provably fair and it should be obvious why that is the case. The description regarding "Server seed" is also confusing, but I mentioned this in an earlier post.

Since this is relatively long, let me resume: 1) you are not describing how the rolled number is picked; 2) the way you describe "user seed" makes it not provably fair; 3) "server seed" is confusing as it is not a seed of anything.

...
It would be impossible or very illogical to force the user into submitting a client seed every bet, we do however allow users if they feel the need to change it if they feel the need to. If you're wondering how the rolls are determined it is through a simple php rand function.

Wow, take some time and think about what you just wrote there. How can the user possibly know that the roll was done in a provably fair manner considering what you just wrote ? Here is the result of "a simple php rand function": 32, who can I know I did it in a fair manner ? You (the player actually) have no way to check that with this current method.

Pay attention to this: neither the user seed nor the daily secret have any effect in the rolled number. If you know of any site that do this, you picked the wrong example to follow.

I have answered this multiple time at the moment the client seed doesn't affect affect the roll but we're looking to implement it in the future. I'm looking to ways to increase our provability and transparency and very much appreciate your feedback.

Do you understand that gigadice is not provably fair ?

[GigaDice]

For what's worth, so far you have entirely sidestepped the discussion regarding the provably fair method used at gigadice. Can't you clearly explain it ?

Anyway, here is how I understood the process. For this example I took the bets 1 and 8 at http://gigadice.com/verification.php?betid=1 and http://gigadice.com/verification.php?betid=8. Bet 1 rolled 18.71 with user seed 208606, Bet 8 rolled 56.03 with user seed 597414. To check the outcome is the expected one, concatenate the rolled number, the user seed, and the daily secret of 61f476d793488e3d47fd348011c203084c60be24 for these rolls. Apply SHA 512 on the concatenated message and take the hex digest, if they match the one published at "Server Seed (Hash) for that Roll" for that bet, then the result is the expected one. For these rolls, the hashes match -- EXCEPT it is missing the most important step: WHAT did it do to roll 18.71 and 56.03 there ?

There are yet two other issues about how you're handling this (beyond not properly answering it earlier). First issue: the hash of the daily secret 61f476d793488e3d47fd348011c203084c60be24 is not shown anywhere, if it is I can't find it. Second issue regards the way you describe your method, if it is done exactly as specified there, then it is not provably fair again.

Here is the part that is wrong in every instance: """Prior to betting, you receive a "Server Seed" and a "Client Seed." The Server Seed is a combination of your roll, your client seed, and our secret - hashed""". This is telling me I get a user seed before the bet is placed, it doesn't clearly say that the player sends its own seed. /If/ it is not the player who specifies his seed, then it is not provably fair and it should be obvious why that is the case. The description regarding "Server seed" is also confusing, but I mentioned this in an earlier post.

Since this is relatively long, let me resume: 1) you are not describing how the rolled number is picked; 2) the way you describe "user seed" makes it not provably fair; 3) "server seed" is confusing as it is not a seed of anything.

...
It would be impossible or very illogical to force the user into submitting a client seed every bet, we do however allow users if they feel the need to change it if they feel the need to. If you're wondering how the rolls are determined it is through a simple php rand function.

Wow, take some time and think about what you just wrote there. How can the user possibly know that the roll was done in a provably fair manner considering what you just wrote ? Here is the result of "a simple php rand function": 32, who can I know I did it in a fair manner ? You (the player actually) have no way to check that with this current method.

Pay attention to this: neither the user seed nor the daily secret have any effect in the rolled number. If you know of any site that do this, you picked the wrong example to follow.

I have answered this multiple time at the moment the client seed doesn't affect affect the roll but we're looking to implement it in the future. I'm looking to ways to increase our provability and transparency and very much appreciate your feedback.

Do you understand that gigadice is not provably fair ?

Please refer to this topic as our system may not be the what you're used to seeing but it is provably fair.

[knowitnothing]

For what's worth, so far you have entirely sidestepped the discussion regarding the provably fair method used at gigadice. Can't you clearly explain it ?

Anyway, here is how I understood the process. For this example I took the bets 1 and 8 at http://gigadice.com/verification.php?betid=1 and http://gigadice.com/verification.php?betid=8. Bet 1 rolled 18.71 with user seed 208606, Bet 8 rolled 56.03 with user seed 597414. To check the outcome is the expected one, concatenate the rolled number, the user seed, and the daily secret of 61f476d793488e3d47fd348011c203084c60be24 for these rolls. Apply SHA 512 on the concatenated message and take the hex digest, if they match the one published at "Server Seed (Hash) for that Roll" for that bet, then the result is the expected one. For these rolls, the hashes match -- EXCEPT it is missing the most important step: WHAT did it do to roll 18.71 and 56.03 there ?

There are yet two other issues about how you're handling this (beyond not properly answering it earlier). First issue: the hash of the daily secret 61f476d793488e3d47fd348011c203084c60be24 is not shown anywhere, if it is I can't find it. Second issue regards the way you describe your method, if it is done exactly as specified there, then it is not provably fair again.

Here is the part that is wrong in every instance: """Prior to betting, you receive a "Server Seed" and a "Client Seed." The Server Seed is a combination of your roll, your client seed, and our secret - hashed""". This is telling me I get a user seed before the bet is placed, it doesn't clearly say that the player sends its own seed. /If/ it is not the player who specifies his seed, then it is not provably fair and it should be obvious why that is the case. The description regarding "Server seed" is also confusing, but I mentioned this in an earlier post.

Since this is relatively long, let me resume: 1) you are not describing how the rolled number is picked; 2) the way you describe "user seed" makes it not provably fair; 3) "server seed" is confusing as it is not a seed of anything.

...
It would be impossible or very illogical to force the user into submitting a client seed every bet, we do however allow users if they feel the need to change it if they feel the need to. If you're wondering how the rolls are determined it is through a simple php rand function.

Wow, take some time and think about what you just wrote there. How can the user possibly know that the roll was done in a provably fair manner considering what you just wrote ? Here is the result of "a simple php rand function": 32, who can I know I did it in a fair manner ? You (the player actually) have no way to check that with this current method.

Pay attention to this: neither the user seed nor the daily secret have any effect in the rolled number. If you know of any site that do this, you picked the wrong example to follow.

I have answered this multiple time at the moment the client seed doesn't affect affect the roll but we're looking to implement it in the future. I'm looking to ways to increase our provability and transparency and very much appreciate your feedback.

Do you understand that gigadice is not provably fair ?

Please refer to this topic as our system may not be the what you're used to seeing but it is provably fair.

Can you give a proper answer on where am I wrong ? Can you show how your system is provably fair after all those points above ?

According to the very own topic you mentioned, you managed to: a) make an unprovable fair system; with b) unprovable results. What am I supposed to take from that thread ?

[Mooshire]

For what's worth, so far you have entirely sidestepped the discussion regarding the provably fair method used at gigadice. Can't you clearly explain it ?

Anyway, here is how I understood the process. For this example I took the bets 1 and 8 at http://gigadice.com/verification.php?betid=1 and http://gigadice.com/verification.php?betid=8. Bet 1 rolled 18.71 with user seed 208606, Bet 8 rolled 56.03 with user seed 597414. To check the outcome is the expected one, concatenate the rolled number, the user seed, and the daily secret of 61f476d793488e3d47fd348011c203084c60be24 for these rolls. Apply SHA 512 on the concatenated message and take the hex digest, if they match the one published at "Server Seed (Hash) for that Roll" for that bet, then the result is the expected one. For these rolls, the hashes match -- EXCEPT it is missing the most important step: WHAT did it do to roll 18.71 and 56.03 there ?

There are yet two other issues about how you're handling this (beyond not properly answering it earlier). First issue: the hash of the daily secret 61f476d793488e3d47fd348011c203084c60be24 is not shown anywhere, if it is I can't find it. Second issue regards the way you describe your method, if it is done exactly as specified there, then it is not provably fair again.

Here is the part that is wrong in every instance: """Prior to betting, you receive a "Server Seed" and a "Client Seed." The Server Seed is a combination of your roll, your client seed, and our secret - hashed""". This is telling me I get a user seed before the bet is placed, it doesn't clearly say that the player sends its own seed. /If/ it is not the player who specifies his seed, then it is not provably fair and it should be obvious why that is the case. The description regarding "Server seed" is also confusing, but I mentioned this in an earlier post.

Since this is relatively long, let me resume: 1) you are not describing how the rolled number is picked; 2) the way you describe "user seed" makes it not provably fair; 3) "server seed" is confusing as it is not a seed of anything.

...
It would be impossible or very illogical to force the user into submitting a client seed every bet, we do however allow users if they feel the need to change it if they feel the need to. If you're wondering how the rolls are determined it is through a simple php rand function.

Wow, take some time and think about what you just wrote there. How can the user possibly know that the roll was done in a provably fair manner considering what you just wrote ? Here is the result of "a simple php rand function": 32, who can I know I did it in a fair manner ? You (the player actually) have no way to check that with this current method.

Pay attention to this: neither the user seed nor the daily secret have any effect in the rolled number. If you know of any site that do this, you picked the wrong example to follow.

I have answered this multiple time at the moment the client seed doesn't affect affect the roll but we're looking to implement it in the future. I'm looking to ways to increase our provability and transparency and very much appreciate your feedback.

Do you understand that gigadice is not provably fair ?

This is what I've been trying to get him to understand. He doesn't seem to get the difference between provably fair and provable results.

Provably Fair: The house picks a number in such a way that the user can verify that the house did not have any control over the outcome of the roll

Provable Results: The house supplies a way to show that the outcome did not change from when the hash/seed was provided and after the roll. There is no way to verify the house is not controlling the outcome of the roll.

GigaDice has provable results.


(He also doesn't know the difference between credited and accredited)