Gambling Idea? Go or No?

[b!z]

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.

No, I am not. Maybe you should sit down and think about how wrong you are.

[bit777]

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]

I can use rawtransactions and bankrupt your casino within a few minutes-an hour depending on my bankroll. Terrible idea.

[cwil]

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]

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.

[bit777]

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]

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]

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.

[bit777]

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.

Unfortunately we don't! I would love to have our game right inside the wallet similar to the way SD has theirs

[imagereply]

http://www.crappie.com/crappie/attachments/florida/107554d1353838545-creeks-back-hijack.gif

[imrer]

I don't believe it's a good idea.

[cwil]

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]

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]

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]

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.