http://betcoin.eu/roulette/
If you transfer 0.1 btc it should be enough for a first test.
Please don't use Internet Explorer. It's not tested in that "/&%§$ browser and may not work.
REMEMBER: it's a beta!
(and looks ugly)
Topic: We Need Roulette - page 3. (Read 8338 times)
Here we go.
http://betcoin.eu/roulette/
If you transfer 0.1 btc it should be enough for a first test.
Please don't use Internet Explorer. It's not tested in that "/&%§$ browser and may not work.
REMEMBER: it's a beta!
(and looks ugly)
http://betcoin.eu/roulette/
If you transfer 0.1 btc it should be enough for a first test.
Please don't use Internet Explorer. It's not tested in that "/&%§$ browser and may not work.
REMEMBER: it's a beta!
(and looks ugly)
Thanks DaMan cant wait to try your game out.
Same here
Thanks DaMan cant wait to try your game out.
Yeah, IMO All the current Roulette games are rigged for the op.
On one of them, I just kept clicking Spin.
But assoon as a hold down the enter key instead of clicking spin I lost 80% of the time
Wheres the fucking Good system Fuck all this bullshit, It's a buncha codeknobs trying to grab a few coins
On one of them, I just kept clicking Spin.
But assoon as a hold down the enter key instead of clicking spin I lost 80% of the time
Wheres the fucking Good system Fuck all this bullshit, It's a buncha codeknobs trying to grab a few coins
You only speak the truth!!
Hmmm, so maybe I have to implement the hash function first.
I am ready for a public beta with my roulette game.
----------------------------------
But note:
- all graphics + user interface are just a function test
- if the gameplay works, all graphics have to be done from scratch up and a nice table + wheel will be rendered
- there is no hash function right now. So if you give it a try, be sure you understand that!
- in the public beta version are only smallest value jetons -> 0.01, 0.02, 0.03 and a round limit of 0.1 btc.
----------------------------------
There are no fees. All payouts greater than 1 btc have to be done in two moves, because we cant calculate the correct bitcoin transaction fee for large amounts. So if you click payout, you will receive 99% of your accounts balance, if it is greater than 1 btc. All lower values should use 0.0005 btc transaction fee.
I have to wait for a few network transactions and will do the first »test without testnet« by my own.
If you would like to give it a try, send me a message or check back a little later ...
kind regards!
I am ready for a public beta with my roulette game.
----------------------------------
But note:
- all graphics + user interface are just a function test
- if the gameplay works, all graphics have to be done from scratch up and a nice table + wheel will be rendered
- there is no hash function right now. So if you give it a try, be sure you understand that!
- in the public beta version are only smallest value jetons -> 0.01, 0.02, 0.03 and a round limit of 0.1 btc.
----------------------------------
There are no fees. All payouts greater than 1 btc have to be done in two moves, because we cant calculate the correct bitcoin transaction fee for large amounts. So if you click payout, you will receive 99% of your accounts balance, if it is greater than 1 btc. All lower values should use 0.0005 btc transaction fee.
I have to wait for a few network transactions and will do the first »test without testnet« by my own.
If you would like to give it a try, send me a message or check back a little later ...
kind regards!
Yeah, IMO All the current Roulette games are rigged for the op.
On one of them, I just kept clicking Spin.
But assoon as a hold down the enter key instead of clicking spin I lost 80% of the time
Wheres the fucking Good system Fuck all this bullshit, It's a buncha codeknobs trying to grab a few coins
On one of them, I just kept clicking Spin.
But assoon as a hold down the enter key instead of clicking spin I lost 80% of the time
Wheres the fucking Good system Fuck all this bullshit, It's a buncha codeknobs trying to grab a few coins
I was thinking that too. The more you played it the more you'd be able to find out which 20 numbers or whatever were the ones in play. In that case, you could actually screw over the op pretty easily. Good times.
The only way I can think of to prove all 38 are included would be to present the player with 38 buttons, each with a hash of a string which included the number, then have the player choose one of the 38 buttons, and that would be the winning number for the roulette bets.
Sounds complicated, but I'm not sure if there's simpler way for absolute proof.
perhaps you could use the principle of inverse to solve this problem. 38 numbers, you choose 1. Instead of the computer actually playing the number(s) selected, it would play every number BUT that one. That way, if it actually lands on the spot where nothing is placed, it knows to pay out the user.
Wait...I'm not sure that made sense at all. hah
I didn't quite understand, no.
Also, when I said 38 buttons, I meant in addition to the roulette betting table, not as a replacement for it.
Too impractical an idea anyway.
Hah agreed. Roulette remains a kinda-rip-off.
I was thinking that too. The more you played it the more you'd be able to find out which 20 numbers or whatever were the ones in play. In that case, you could actually screw over the op pretty easily. Good times.
The only way I can think of to prove all 38 are included would be to present the player with 38 buttons, each with a hash of a string which included the number, then have the player choose one of the 38 buttons, and that would be the winning number for the roulette bets.
Sounds complicated, but I'm not sure if there's simpler way for absolute proof.
perhaps you could use the principle of inverse to solve this problem. 38 numbers, you choose 1. Instead of the computer actually playing the number(s) selected, it would play every number BUT that one. That way, if it actually lands on the spot where nothing is placed, it knows to pay out the user.
Wait...I'm not sure that made sense at all. hah
I didn't quite understand, no.
Also, when I said 38 buttons, I meant in addition to the roulette betting table, not as a replacement for it.
Too impractical an idea anyway.
I was thinking that too. The more you played it the more you'd be able to find out which 20 numbers or whatever were the ones in play. In that case, you could actually screw over the op pretty easily. Good times.
The only way I can think of to prove all 38 are included would be to present the player with 38 buttons, each with a hash of a string which included the number, then have the player choose one of the 38 buttons, and that would be the winning number for the roulette bets.
Sounds complicated, but I'm not sure if there's simpler way for absolute proof.
perhaps you could use the principle of inverse to solve this problem. 38 numbers, you choose 1. Instead of the computer actually playing the number(s) selected, it would play every number BUT that one. That way, if it actually lands on the spot where nothing is placed, it knows to pay out the user.
Wait...I'm not sure that made sense at all. hah
I was thinking that too. The more you played it the more you'd be able to find out which 20 numbers or whatever were the ones in play. In that case, you could actually screw over the op pretty easily. Good times.
The only way I can think of to prove all 38 are included would be to present the player with 38 buttons, each with a hash of a string which included the number, then have the player choose one of the 38 buttons, and that would be the winning number for the roulette bets.
Sounds complicated, but I'm not sure if there's simpler way for absolute proof.
Wouldn't it be easy for the game op to rig the table to have a extremely low winning ratio for a game like this? =/
Indeed. This means whoever creates it has a very good chance of making a significant amount of BTC. The players, not so much.
Not really. You'd just need to show an MD5 hash of the game outcome, before the bets are placed. Spoils the fun a bit of 'spinning' the wheel, but it's all digital anyway; no reason the random number can't be chosen in advance.
Because if the random number is chosen *before* bets are placed, and an MD5 hash of that number displayed, then the operator doesn't know what bets will be placed and whether or not the player is going to win or not.
1. System generates random number, 1-38 (or 37).
2. Page displays some kind of hash, based on this number.
3. Player places bets and submits
4. System checks what they have won and shows the player exactly how the MD5 hash was generated so that the player can verify the number was chosen before bets were placed.
But if the op puts only 20 numbers in the random generation, he has decreased the win ratio and yet it still appears as if it's a random hash based on 38 numbers. I suppose there would need to be some way to display previous rolls...but even then...it seems so easy to put the odds in the op's favor.
You could make it so that your data string contains all numbers, and the winning number is the first one... so you scramble the 38 numbers and hash the following string:
9,8,2,1,5,4,12,3,15... etc, etc etc (all 38 numbers)
The winning number is 9... after the game, you can show the player the md5 and also show them the data string which has 9 coming first.
You could still fake it so that 17 for example never came first, but over time I'm sure people would start to notice that 17 never wins.
I was thinking that too. The more you played it the more you'd be able to find out which 20 numbers or whatever were the ones in play. In that case, you could actually screw over the op pretty easily. Good times.
Wouldn't it be easy for the game op to rig the table to have a extremely low winning ratio for a game like this? =/
Indeed. This means whoever creates it has a very good chance of making a significant amount of BTC. The players, not so much.
Not really. You'd just need to show an MD5 hash of the game outcome, before the bets are placed. Spoils the fun a bit of 'spinning' the wheel, but it's all digital anyway; no reason the random number can't be chosen in advance.
Because if the random number is chosen *before* bets are placed, and an MD5 hash of that number displayed, then the operator doesn't know what bets will be placed and whether or not the player is going to win or not.
1. System generates random number, 1-38 (or 37).
2. Page displays some kind of hash, based on this number.
3. Player places bets and submits
4. System checks what they have won and shows the player exactly how the MD5 hash was generated so that the player can verify the number was chosen before bets were placed.
But if the op puts only 20 numbers in the random generation, he has decreased the win ratio and yet it still appears as if it's a random hash based on 38 numbers. I suppose there would need to be some way to display previous rolls...but even then...it seems so easy to put the odds in the op's favor.
You could make it so that your data string contains all numbers, and the winning number is the first one... so you scramble the 38 numbers and hash the following string:
9,8,2,1,5,4,12,3,15... etc, etc etc (all 38 numbers)
The winning number is 9... after the game, you can show the player the md5 and also show them the data string which has 9 coming first.
You could still fake it so that 17 for example never came first, but over time I'm sure people would start to notice that 17 never wins.
Wouldn't it be easy for the game op to rig the table to have a extremely low winning ratio for a game like this? =/
Indeed. This means whoever creates it has a very good chance of making a significant amount of BTC. The players, not so much.
Not really. You'd just need to show an MD5 hash of the game outcome, before the bets are placed. Spoils the fun a bit of 'spinning' the wheel, but it's all digital anyway; no reason the random number can't be chosen in advance.
Because if the random number is chosen *before* bets are placed, and an MD5 hash of that number displayed, then the operator doesn't know what bets will be placed and whether or not the player is going to win or not.
1. System generates random number, 1-38 (or 37).
2. Page displays some kind of hash, based on this number.
3. Player places bets and submits
4. System checks what they have won and shows the player exactly how the MD5 hash was generated so that the player can verify the number was chosen before bets were placed.
But if the op puts only 20 numbers in the random generation, he has decreased the win ratio and yet it still appears as if it's a random hash based on 38 numbers. I suppose there would need to be some way to display previous rolls...but even then...it seems so easy to put the odds in the op's favor.
Wouldn't it be easy for the game op to rig the table to have a extremely low winning ratio for a game like this? =/
Indeed. This means whoever creates it has a very good chance of making a significant amount of BTC. The players, not so much.
Not really. You'd just need to show an MD5 hash of the game outcome, before the bets are placed. Spoils the fun a bit of 'spinning' the wheel, but it's all digital anyway; no reason the random number can't be chosen in advance.
Because if the random number is chosen *before* bets are placed, and an MD5 hash of that number displayed, then the operator doesn't know what bets will be placed and whether or not the player is going to win or not.
1. System generates random number, 1-38 (or 37).
2. Page displays some kind of hash, based on this number.
3. Player places bets and submits
4. System checks what they have won and shows the player exactly how the MD5 hash was generated so that the player can verify the number was chosen before bets were placed.
Wouldn't it be easy for the game op to rig the table to have a extremely low winning ratio for a game like this? =/
Indeed. This means whoever creates it has a very good chance of making a significant amount of BTC. The players, not so much.
Not really. You'd just need to show an MD5 hash of the game outcome, before the bets are placed. Spoils the fun a bit of 'spinning' the wheel, but it's all digital anyway; no reason the random number can't be chosen in advance.
Wouldn't it be easy for the game op to rig the table to have a extremely low winning ratio for a game like this? =/
Indeed. This means whoever creates it has a very good chance of making a significant amount of BTC. The players, not so much.
Not really. You'd just need to show an MD5 hash of the game outcome, before the bets are placed. Spoils the fun a bit of 'spinning' the wheel, but it's all digital anyway; no reason the random number can't be chosen in advance.
Wouldn't it be easy for the game op to rig the table to have a extremely low winning ratio for a game like this? =/
Indeed. This means whoever creates it has a very good chance of making a significant amount of BTC. The players, not so much.
Wouldn't it be easy for the game op to rig the table to have a extremely low winning ratio for a game like this? =/
what are you talking about? http://www.bitcoingamer.com?donateto=1MbV7wq4Dhi2iSGQxgTKkVKtH5AbEET6Xe has had one for months
oh, multiple bets. sorry, sheesh. I remember cash cow had one, but it seems dead and gone. The closest thing I know is Dragon's Tale
I hate to say it but Dragon's Tale is kinda fun, if you have some BTC to blow. I definitely don't think you can win much, but the IDEA is what makes it quite awesome.
what are you talking about? http://www.bitcoingamer.com?donateto=1MbV7wq4Dhi2iSGQxgTKkVKtH5AbEET6Xe has had one for months
oh, multiple bets. sorry, sheesh. I remember cash cow had one, but it seems dead and gone. The closest thing I know is Dragon's Tale
Jump to: