Topic: fixed version in OP (Read 1030 times)
Interesting dice game, i just made a wealth fountain a few days ago and it works, you can maybe check it out!
This is in NO WAY random.
I will have to look into it.
This is in NO WAY random. It is deterministic and predictable. I wrote a little contract in Solidity to demonstrate:
https://chriseth.github.io/browser-solidity/?gist=c4432bc46c6733652a4e784ed1efc20e
These are the completely predictable results I receive when testing with various combinations of list_length and address:
This address never wins:
false == wouldTheyWinDice(1, "0x446D1696a5527018453cdA3d67aa4C2cd189b9f6")
false == wouldTheyWinDice(2, "0x446D1696a5527018453cdA3d67aa4C2cd189b9f6")
false == wouldTheyWinDice(3, "0x446D1696a5527018453cdA3d67aa4C2cd189b9f6")
false == wouldTheyWinDice(4, "0x446D1696a5527018453cdA3d67aa4C2cd189b9f6")
This address wins when list length is even:
true == wouldTheyWinDice(0, "0xd7AAC26DA63A9B3e4beF54b5585A563A6ca248F9")
false == wouldTheyWinDice(1, "0xd7AAC26DA63A9B3e4beF54b5585A563A6ca248F9")
true == wouldTheyWinDice(2, "0xd7AAC26DA63A9B3e4beF54b5585A563A6ca248F9")
false == wouldTheyWinDice(3, "0xd7AAC26DA63A9B3e4beF54b5585A563A6ca248F9")
This address also wins when list length is even:
true == wouldTheyWinDice(0, "0xdAe545ef6946d833b6a2B34b3d8823da2788718a")
false == wouldTheyWinDice(1, "0xdAe545ef6946d833b6a2B34b3d8823da2788718a")
true == wouldTheyWinDice(2, "0xdAe545ef6946d833b6a2B34b3d8823da2788718a")
false == wouldTheyWinDice(3, "0xdAe545ef6946d833b6a2B34b3d8823da2788718a")
In reality, you have a 0% or a 100% chance of winning based on conditions which can be known in advance.
https://chriseth.github.io/browser-solidity/?gist=c4432bc46c6733652a4e784ed1efc20e
Code:
contract EthereumDiceDebunker {
function wouldIWinDice(uint list_length) constant returns (bool result) {
result = uint(sha3(msg.sender)) % 2==0 && list_length % 2==0 ;
}
function wouldTheyWinDice(uint list_length, address them) constant returns (bool result) {
result = (uint(sha3(them)) % 2==0 && list_length % 2==0) ;
}
}
function wouldIWinDice(uint list_length) constant returns (bool result) {
result = uint(sha3(msg.sender)) % 2==0 && list_length % 2==0 ;
}
function wouldTheyWinDice(uint list_length, address them) constant returns (bool result) {
result = (uint(sha3(them)) % 2==0 && list_length % 2==0) ;
}
}
These are the completely predictable results I receive when testing with various combinations of list_length and address:
This address never wins:
false == wouldTheyWinDice(1, "0x446D1696a5527018453cdA3d67aa4C2cd189b9f6")
false == wouldTheyWinDice(2, "0x446D1696a5527018453cdA3d67aa4C2cd189b9f6")
false == wouldTheyWinDice(3, "0x446D1696a5527018453cdA3d67aa4C2cd189b9f6")
false == wouldTheyWinDice(4, "0x446D1696a5527018453cdA3d67aa4C2cd189b9f6")
This address wins when list length is even:
true == wouldTheyWinDice(0, "0xd7AAC26DA63A9B3e4beF54b5585A563A6ca248F9")
false == wouldTheyWinDice(1, "0xd7AAC26DA63A9B3e4beF54b5585A563A6ca248F9")
true == wouldTheyWinDice(2, "0xd7AAC26DA63A9B3e4beF54b5585A563A6ca248F9")
false == wouldTheyWinDice(3, "0xd7AAC26DA63A9B3e4beF54b5585A563A6ca248F9")
This address also wins when list length is even:
true == wouldTheyWinDice(0, "0xdAe545ef6946d833b6a2B34b3d8823da2788718a")
false == wouldTheyWinDice(1, "0xdAe545ef6946d833b6a2B34b3d8823da2788718a")
true == wouldTheyWinDice(2, "0xdAe545ef6946d833b6a2B34b3d8823da2788718a")
false == wouldTheyWinDice(3, "0xdAe545ef6946d833b6a2B34b3d8823da2788718a")
In reality, you have a 0% or a 100% chance of winning based on conditions which can be known in advance.
Nice to see that ethereum now has a working dice game, i can only wonder what other good inventions we will see soon
This one is working too -> Bet On Hash
It's similar to a dice game. 6 people are playing in a round and the lucky ones will win.
Looks like we got our first winner!
1.496184 Ether to: 0x795f91176c40eb9e75647df5a436b7527d3f143c
Internal transaction ID:
https://etherscan.io/tx/0xf3421454e4e784166ab0bc37de4f251d0ee32ed0e333b37d2876807fc31b9842#internal
Enjoy gambling
1.496184 Ether to: 0x795f91176c40eb9e75647df5a436b7527d3f143c
Internal transaction ID:
https://etherscan.io/tx/0xf3421454e4e784166ab0bc37de4f251d0ee32ed0e333b37d2876807fc31b9842#internal
Enjoy gambling
Nice to see that ethereum now has a working dice game, i can only wonder what other good inventions we will see soon
I was one of the depositors
Unfortunately i`m not the winner, but i`ll gamble again soon, and next time i`ll be the winner
Unfortunately i`m not the winner, but i`ll gamble again soon, and next time i`ll be the winner
Looks like we got our first winner!
1.496184 Ether to: 0x795f91176c40eb9e75647df5a436b7527d3f143c
Internal transaction ID:
https://etherscan.io/tx/0xf3421454e4e784166ab0bc37de4f251d0ee32ed0e333b37d2876807fc31b9842#internal
Enjoy gambling
1.496184 Ether to: 0x795f91176c40eb9e75647df5a436b7527d3f143c
Internal transaction ID:
https://etherscan.io/tx/0xf3421454e4e784166ab0bc37de4f251d0ee32ed0e333b37d2876807fc31b9842#internal
Enjoy gambling
Wow its very exciting to see a gambling game finally!
I will play here!
I will play here!
Yes you are definitely wrong, the sha3 hash returns the hash of the input (address), which is a long sequence of bytes in the byte32 format.
I have specifically read the manual and I`m familiar with all variable types.
The '%' operator is the MOD operator, which is either 1 or 0, so we take the length of the byres in uint format, it will be a long number, and we see if the number is odd or even (50% chance),
I have specifically read the manual and I`m familiar with all variable types.
The '%' operator is the MOD operator, which is either 1 or 0, so we take the length of the byres in uint format, it will be a long number, and we see if the number is odd or even (50% chance),
In your current implementation you're only hashing the address, maybe you intended to hash the address with the length of the array sha3(address, array.length). The result will always be the same the way it's coded.
Different from different addresses. That is why the order variable is there. Depends on what order you deposit.
So that is 2 sources of entropy.
Quote
sha3(address, array.length)
that is the same as sha3(address) && array.length %2 from randomness standpoint.
Well, I'd love to hear other people's opinions. I'm pretty sure it's not the same. If someone's address' hash % 2 is not 0 it will never be 0, it's a static value. That makes that person unable to win in this game. If (false && true) always returns false. Only people whose address matches the criteria can win if the array's length is even. If you had used the formula I mentioned that would be different, because then the first result can be true or false depending on the length.
Edit: Either way, even if it worked the way you want it to, people can simply calculate the result before playing, thus knowing beforehand if they're gonna win or lose. There's nothing random about this.
Yes you are definitely wrong, the sha3 hash returns the hash of the input (address), which is a long sequence of bytes in the byte32 format.
I have specifically read the manual and I`m familiar with all variable types.
The '%' operator is the MOD operator, which is either 1 or 0, so we take the length of the byres in uint format, it will be a long number, and we see if the number is odd or even (50% chance),
I have specifically read the manual and I`m familiar with all variable types.
The '%' operator is the MOD operator, which is either 1 or 0, so we take the length of the byres in uint format, it will be a long number, and we see if the number is odd or even (50% chance),
In your current implementation you're only hashing the address, maybe you intended to hash the address with the length of the array sha3(address, array.length). The result will always be the same the way it's coded.
Different from different addresses. That is why the order variable is there. Depends on what order you deposit.
So that is 2 sources of entropy.
Quote
sha3(address, array.length)
that is the same as sha3(address) && array.length %2 from randomness standpoint.
Yes you are definitely wrong, the sha3 hash returns the hash of the input (address), which is a long sequence of bytes in the byte32 format.
I have specifically read the manual and I`m familiar with all variable types.
The '%' operator is the MOD operator, which is either 1 or 0, so we take the length of the byres in uint format, it will be a long number, and we see if the number is odd or even (50% chance),
I have specifically read the manual and I`m familiar with all variable types.
The '%' operator is the MOD operator, which is either 1 or 0, so we take the length of the byres in uint format, it will be a long number, and we see if the number is odd or even (50% chance),
In your current implementation you're only hashing the address, maybe you intended to hash the address with the length of the array sha3(address, array.length). The result will always be the same the way it's coded.
If we're talking about the first working Ether dice game, I think we at crypto-games.net have beaten you to that.
Of course, it's not using smart contracts, but you didn't specify that in your thread title.
Of course, it's not using smart contracts, but you didn't specify that in your thread title.
Ok I changed the title, it's a DAPP game.
Plus there was another dice game but their code was broken.
So we are the first working ether dice dapp game!
Good questions, let me address them!
Yes you are definitely wrong, the sha3 hash returns the hash of the input (address), which is a long sequence of bytes in the byte32 format.
I have specifically read the manual and I`m familiar with all variable types.
The '%' operator is the MOD operator, which is either 1 or 0, so we take the length of the byres in uint format, it will be a long number, and we see if the number is odd or even (50% chance),
Then we take the order of the depositor, either odd or even, wich is also 50%.
That gives us a mix of 25% chance. (50% * 50% /100)
Its the best random number generator system currently available since there is no RAND() function in solidity yet.
It's still a payout. The money goes in is the total deposit, and the money that goes out is the total payout.
Therefore you can see how much money went in and went out. And you can calculate the fees from that.
I don't really have time to test the code right now, but I'd be quite cautious, there are some quite sketchy things about it.
I could be wrong, but as far as I know, sha3 always returns the same hash given a certain input. In other words, if you address' hash % 2 isn't 0, it will never be, and so, you'll never get to win no matter how many times you try. I haven't checked yet, but I bet the the owner's address (or an alternative account of his, if he's smart) conveniently matches the criteria. I'll report back with results soon.
Also, there are no dice involved here, the payout logic depends on your position in the entries list and the aforementioned hash result. Hardly random.
I could be wrong, but as far as I know, sha3 always returns the same hash given a certain input. In other words, if you address' hash % 2 isn't 0, it will never be, and so, you'll never get to win no matter how many times you try. I haven't checked yet, but I bet the the owner's address (or an alternative account of his, if he's smart) conveniently matches the criteria. I'll report back with results soon.
Also, there are no dice involved here, the payout logic depends on your position in the entries list and the aforementioned hash result. Hardly random.
Yes you are definitely wrong, the sha3 hash returns the hash of the input (address), which is a long sequence of bytes in the byte32 format.
I have specifically read the manual and I`m familiar with all variable types.
The '%' operator is the MOD operator, which is either 1 or 0, so we take the length of the byres in uint format, it will be a long number, and we see if the number is odd or even (50% chance),
Then we take the order of the depositor, either odd or even, wich is also 50%.
That gives us a mix of 25% chance. (50% * 50% /100)
Its the best random number generator system currently available since there is no RAND() function in solidity yet.
Quote
// payout fees to the owner
if (Fees != 0)
{
owner.send(Fees); //send fee to owner
Total_Payouts+=Fees; //update paid out amount
}
Why count the money the owner gets from fees as a payout? It's a bit misleading.if (Fees != 0)
{
owner.send(Fees); //send fee to owner
Total_Payouts+=Fees; //update paid out amount
}
It's still a payout. The money goes in is the total deposit, and the money that goes out is the total payout.
Therefore you can see how much money went in and went out. And you can calculate the fees from that.
If we're talking about the first working Ether dice game, I think we at crypto-games.net have beaten you to that.
Of course, it's not using smart contracts, but you didn't specify that in your thread title.
Of course, it's not using smart contracts, but you didn't specify that in your thread title.
I don't really have time to test the code right now, but I'd be quite cautious, there are some quite sketchy things about it.
Another thing I find odd is this:
Also, there are no dice involved here, the payout logic depends on your position in the entries list and the aforementioned hash result. Hardly random.
Quote
if(uint(sha3(gamblerlist[list_length].etherAddress)) % 2==0 && list_length % 2==0 && Bankroll > 0) //if the hashed length of your address is even,
{ //which is a 25% chance, then you get paid out all balance!
gamblerlist[list_length].etherAddress.send(Bankroll); //send pay out to participant
Total_Payouts += Bankroll; //update paid out amount
Bankroll = 0; //bankroll update
}
I could be wrong, but as far as I know, sha3 always returns the same hash given a certain input. In other words, if you address' hash % 2 isn't 0, it will never be, and so, you'll never get to win no matter how many times you try. I haven't checked yet, but I bet the the owner's address (or an alternative account of his, if he's smart) conveniently matches the criteria. I'll report back with results soon.{ //which is a 25% chance, then you get paid out all balance!
gamblerlist[list_length].etherAddress.send(Bankroll); //send pay out to participant
Total_Payouts += Bankroll; //update paid out amount
Bankroll = 0; //bankroll update
}
Another thing I find odd is this:
Quote
// payout fees to the owner
if (Fees != 0)
{
owner.send(Fees); //send fee to owner
Total_Payouts+=Fees; //update paid out amount
}
Why count the money the owner gets from fees as a payout? It's a bit misleading.if (Fees != 0)
{
owner.send(Fees); //send fee to owner
Total_Payouts+=Fees; //update paid out amount
}
Also, there are no dice involved here, the payout logic depends on your position in the entries list and the aforementioned hash result. Hardly random.
I`ve talked with BetGod over Skype a few hours ago, and I`ve also reviewed his code, and from my 8 year javascript programming experience and from my proven stable and working TreasureChest contract track-record, I can safely say that his code is safe.
Keep up the good work, we need ethereum casinos too!
Keep up the good work, we need ethereum casinos too!
I`ve filled up the balance with 1 Ethereum to get started, I believe this casino will grow big, we are the first ones that do work without bugs! 
Happy gambling, good luck!
Happy gambling, good luck!
Jump to: