b!z
Legendary
Offline
Activity: 1582
Merit: 1010
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 17, 2013, 02:58:11 PM |
|
It is not provably fair, and the link he provided does not claim that it is provably fair.
From what I can see, you can prove how the results are calculated, but you cannot prove that it is fair.
![](https://ip.bitcointalk.org/?u=http%3A%2F%2Fstatic2.fjcdn.com%2Fcomments%2FAre%2Byou%2Bfor%2Breal%2Bman%2BJesus%2BChrist%2Bdo%2Byou%2Bnot%2B_84dee4bd81a89f503bbb65ca10940327.jpg&t=665&c=UF_zaqArfG4pUw) No, I am not. Maybe you should sit down and think about how wrong you are.
|
|
|
|
bit777
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 17, 2013, 04:37:54 PM |
|
We don't have control over either of the 2 hashes. They both come from the blockchain. Hence, we cannot manipulate the outcome in any way. Hence it is provably fair.
That's not how it supposed to work. Provably fair means you give the players a key before they place the bet, which they can then use after they've lost or won to confirm that there was no cheating. If you check our explanation on site, you will see that we give the players an option to check each transaction themselves.
|
|
|
|
DiamondCardz
Legendary
Offline
Activity: 1134
Merit: 1118
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 17, 2013, 04:55:14 PM |
|
I can use rawtransactions and bankrupt your casino within a few minutes-an hour depending on my bankroll. Terrible idea.
|
BA Computer Science, University of Oxford Dissertation was about threat modelling on distributed ledgers.
|
|
|
cwil
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 17, 2013, 05:02:01 PM |
|
Just to be clear, the bit777 instant gamble uses the hash of the txid of the incoming transaction plus the txid of a second transaction, and this second transaction originates from the bit777 wallet, correct? If this is so, then it would be trivial for bit777 to determine the result of any instant gamble through methods described in this thread.
I have no reason to believe this is actually happening, but I think that is the point b!z is trying to make. Regardless, the majority of the games on bit777 aren't provably fair as defined by the bitcoin community anyway, so I doubt it matters to anyone gambling there. You could easily just use the sdice method of generating a secret per day, hashing it, and releasing the hash. Generate your result as secret+hash and then no one can complain.
|
|
|
|
DiamondCardz
Legendary
Offline
Activity: 1134
Merit: 1118
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 17, 2013, 05:40:54 PM |
|
Just to be clear, the bit777 instant gamble uses the hash of the txid of the incoming transaction plus the txid of a second transaction, and this second transaction originates from the bit777 wallet, correct? If this is so, then it would be trivial for bit777 to determine the result of any instant gamble through methods described in this thread.
Yep, you're right about that. bit777 could create any bet result quickly.
|
BA Computer Science, University of Oxford Dissertation was about threat modelling on distributed ledgers.
|
|
|
bit777
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 17, 2013, 05:49:20 PM |
|
No. The second hash is generated by blockchain.info API, over which we have 0 control. The way their api works is like this:
A player deposits money to a blockchain.info address - with a generated by the player transaction id blockchain.info reroutes the transaction towards the final destination (our wallet address) - blockchain.info generates their own transaction id
We combine the player transaction hash and the blockchain.info generated hash to receive the final value.
We don't have control over either one, since we don't initiate either transaction of the 2. We cannot manipulate either one, and the player cannot manipulate the blockchain.info one. So it cannot be cheated by either party.
|
|
|
|
tonino
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 17, 2013, 05:53:36 PM |
|
following this discussion now with big interest. I hope at the end we all will know what really is and who is provably fair.
|
|
|
|
DiamondCardz
Legendary
Offline
Activity: 1134
Merit: 1118
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 17, 2013, 05:54:31 PM |
|
No. The second hash is generated by blockchain.info API
Oh, that's completely fine then. Assuming you don't have a secret kind of alliance with blockchain.info. ![Wink](https://bitcointalk.org/Smileys/default/wink.gif)
|
BA Computer Science, University of Oxford Dissertation was about threat modelling on distributed ledgers.
|
|
|
bit777
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 17, 2013, 05:57:31 PM |
|
No. The second hash is generated by blockchain.info API
Oh, that's completely fine then. Assuming you don't have a secret kind of alliance with blockchain.info. ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) Unfortunately we don't! I would love to have our game right inside the wallet similar to the way SD has theirs ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
imagereply
Newbie
Offline
Activity: 42
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 17, 2013, 07:10:37 PM |
|
|
|
|
|
imrer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 17, 2013, 08:14:34 PM |
|
I don't believe it's a good idea.
|
|
|
|
cwil
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 17, 2013, 08:31:13 PM |
|
No. The second hash is generated by blockchain.info API, over which we have 0 control. The way their api works is like this:
A player deposits money to a blockchain.info address - with a generated by the player transaction id blockchain.info reroutes the transaction towards the final destination (our wallet address) - blockchain.info generates their own transaction id
We combine the player transaction hash and the blockchain.info generated hash to receive the final value.
We don't have control over either one, since we don't initiate either transaction of the 2. We cannot manipulate either one, and the player cannot manipulate the blockchain.info one. So it cannot be cheated by either party.
You're using the receive method in their api then? ( https://blockchain.info/api/receive?method=create&address=$receiving_address&callback=$callback_url) If so, then I no longer believe you have the ability to alter the results in your instant win game. Thanks for clearing that up.
|
|
|
|
bit777
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 17, 2013, 08:33:55 PM |
|
No. The second hash is generated by blockchain.info API, over which we have 0 control. The way their api works is like this:
A player deposits money to a blockchain.info address - with a generated by the player transaction id blockchain.info reroutes the transaction towards the final destination (our wallet address) - blockchain.info generates their own transaction id
We combine the player transaction hash and the blockchain.info generated hash to receive the final value.
We don't have control over either one, since we don't initiate either transaction of the 2. We cannot manipulate either one, and the player cannot manipulate the blockchain.info one. So it cannot be cheated by either party.
You're using the receive method in their api then? ( https://blockchain.info/api/receive?method=create&address=$receiving_address&callback=$callback_url) If so, then I no longer believe you have the ability to alter the results in your instant win game. Thanks for clearing that up. Yes that's correct. And it very much reproduces marcotheminer's idea (or a very similar one) in a non-cheatable way.
|
|
|
|
b!z
Legendary
Offline
Activity: 1582
Merit: 1010
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 18, 2013, 04:30:51 AM |
|
No. The second hash is generated by blockchain.info API, over which we have 0 control. The way their api works is like this:
A player deposits money to a blockchain.info address - with a generated by the player transaction id blockchain.info reroutes the transaction towards the final destination (our wallet address) - blockchain.info generates their own transaction id
We combine the player transaction hash and the blockchain.info generated hash to receive the final value.
We don't have control over either one, since we don't initiate either transaction of the 2. We cannot manipulate either one, and the player cannot manipulate the blockchain.info one. So it cannot be cheated by either party.
You're using the receive method in their api then? ( https://blockchain.info/api/receive?method=create&address=$receiving_address&callback=$callback_url) If so, then I no longer believe you have the ability to alter the results in your instant win game. Thanks for clearing that up. Yes that's correct. And it very much reproduces marcotheminer's idea (or a very similar one) in a non-cheatable way. The real concern is that there could be a chance that Blockchain.info is generating TXIDs, until it creates one that benefits the casino. We all know that the chance of this happening is probably zero, but it is not 100% provably fair. This could cause players to be concerned, even though it is very unlikely that there is a cooperation between blockchain.info and bit777. The provably fair system implemented by casinos such as satoshidice cannot be rigged by the operator or any other parties, since it is backed by cryptography. Is this not correct?
|
|
|
|
bit777
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 18, 2013, 11:12:56 AM |
|
No. The second hash is generated by blockchain.info API, over which we have 0 control. The way their api works is like this:
A player deposits money to a blockchain.info address - with a generated by the player transaction id blockchain.info reroutes the transaction towards the final destination (our wallet address) - blockchain.info generates their own transaction id
We combine the player transaction hash and the blockchain.info generated hash to receive the final value.
We don't have control over either one, since we don't initiate either transaction of the 2. We cannot manipulate either one, and the player cannot manipulate the blockchain.info one. So it cannot be cheated by either party.
You're using the receive method in their api then? ( https://blockchain.info/api/receive?method=create&address=$receiving_address&callback=$callback_url) If so, then I no longer believe you have the ability to alter the results in your instant win game. Thanks for clearing that up. Yes that's correct. And it very much reproduces marcotheminer's idea (or a very similar one) in a non-cheatable way. The real concern is that there could be a chance that Blockchain.info is generating TXIDs, until it creates one that benefits the casino. We all know that the chance of this happening is probably zero, but it is not 100% provably fair. This could cause players to be concerned, even though it is very unlikely that there is a cooperation between blockchain.info and bit777. The provably fair system implemented by casinos such as satoshidice cannot be rigged by the operator or any other parties, since it is backed by cryptography. Is this not correct? Yes, technically you are correct. If there is a hidden alliance between us and blockchain.info, then the fairness can be jeopardized.
|
|
|
|
|