Topic: Breaking: Shuffle-based Provably Fair Implementations Can Cheat Players (proof) - page 2. (Read 4659 times)

Isn't it a bad implementation though? They generate the 30 initial numbers, without your client seed, and they can generate what ever they want, and you can't verify that they cheated with the inital generation. So while it is technically provably fair, because of how the initial shuffle is generated, they could create a higher house edge by predicting what the gambler likes to do (ie over 7) and generate the inital deck so it is more likely to get under 7? They should just get rid of the initial generation and play with a fair deck (5 ones, 5 twos, 5 threes, e.t.c)

Thank you for the replies.

I don't know much about mining either particularly in this case on what the nonce is etc.


https://en.bitcoin.it/wiki/Nonce

So the nonce value is set by the miner. I was thinking it was automatically computed or something..




Yeah    Never thought of that.


So the block hash is the only reliable (or most reliable) string in a block that can be used for provably fair?

pevpot had an extremely robust system that would make it provably fair for investors: https://web.archive.org/web/20151213003346/https://www.pevpot.com/provably-fair

But like all on-chain games, is doomed by a poor UX

yeah, wtf? I never heard of this site, but they seem to do it in the worst possible way. As you note, it allows a miner to costlessly cheat the site. (miners can have a fixed nonce, and purely fiddle with the coinbase) and theoretically allow the site to cheat players (I doubt this would happen though, if they were sophisticated to know how to cheat players they would realize players can do the exact same attack against them).

Making bets on the last (couple?) digit of the block hash seems a lot smarter, as now miners have to discard blocks in order to cheat, which is rather expensive.

This is the same type of deflection Nitrogensports is infamous for. They have a clearly rigged Blackjack system but whenever anyone questions it they link to "provably fair". Good to see hard data out there that doesnt make the Casino skeptics looks crazy.

Disclaimer: I am not a mining expert, so anyone please correct me if I am wrong here....



satoshinonce would not be fair for investors and that site is technically not even provably fair for the player.

For player: if satoshinonce is also a miner, they could specify block-nonces (last 1 or 2 digits only) in their mining software which makes the incoming transactions/bets lose (or at least whichever is best for them.) So even if they have 2% mining power, players would most likely lose 2% more often. That's why I think for the player it's better to have TX+VOUT+SECRET like Luckyb.it (and SD before.) Might be tough to change it since.. well.. the site is called "Satoshi Nonce".

For investor: if satoshinonce is also a miner, they could adjust the mining software to only check nonces with 2 specific last digits and include some of those winning 98x transactions in it (and not even broadcast those transactions before finding the block!) Then if they find a correct block, they send it out including those winning transactions. It seems like a guaranteed way to win with no risk. So doesn't help investors much. Would be even worse for investors with TX id though obviously.

Also miners who like to attack/cheat satoshinonce can do this right now BTW. But I assume that adjusting the mining software to only use those specific nonces might take some work and I guess with the low max bet it's not worth it for them.



Ps, hope TrevorXavier doesn't mind we are going a bit off-topic here It's still somewhat on the same topic of faulty provably fair implementations though (:

You bring up a good point.

When I first published the side-channel attacks a couple years ago, some casino operators dismissed it by saying things like, "We would never cheat," or "if we did this, we'd get caught" or "if we were caught, we'd lose all our players," without addressing their implementations of provably fair. So, they are countering a cryptanalysis with a PR/marketing spin, which doesn't make sense.

By saying, "We would never cheat," without addressing their implementation, they are only offering a simple promise of fairness, which is no different than a non-provably fair casino.

Yeah, I read that. (just read don't think it is possible part too many times )

I wanted to know your opinion on everything except that part - If satoshinonce accepted investments, is such a risk entirely eliminated?




I think decentralized trust-less gambling/investing is very possible.




Er.. was saying, provably fair wouldn't be invented if we kept thinking - it will not solve all the problems and all we need to do is trust the casino owner.


(edited)

provably fair was invented for the player and imo the best invention in gambling business so why to do it away? please correct me if I am wrong

Yes, that's why I said "fast game"




I agree.

Although in theory in the future there could be true decentralized trust-less gambling/investing with sidechains and investors that run some program to sign transactions/bets on the fly (like JoinMarket.) That would mean all investors have to put their BR in a (own-controlled like their own computer) "hot wallet" though and it's not as fast as dice now. Also I am not sure how the random process would work (either dependent on miner or third-party like most ETH smart contract gambling atm.) So I am not sure how practical it will all be, but sounds like a technical interesting project when the time is there

If everyone is really going to trust the owners we could do away with the provably fair too.

let's say this problem is solved and investors can't be cheated by casino owners. it will not solve the hit n run option for a casino owner imo and this would mean that investors coins are always at risk

at the end the magic word will be trust (the casino owner)

This one http://satoshinonce.com/ (don't know if this is still running fine) appears provably fair to an investor?

I don't think it is impossible, it will just be slow. We need one variable that is not determined by the server or the client and cannot be influenced by either but becomes known soon-after like a block hash?

That's a great question. This is a common issue among crypto-developers. You may have heard the mantra from developers, "Write it, even if it breaks." Unfortunately, crypto-developers aren't afforded the luxury. If crypto is implemented and breaks, it can cause direct harm. Total losses, breached accounts, really bad stuff. Look at Meteor. They had SRP implemented but reverted back to bcrypt because maintaining the crypto code required far more resources that were best used elsewhere.

In a nutshell, I had penned an implementation a couple of years ago, had it in peer review but it quickly became cost prohibitive.

Granted, I can't speak for an organization that is interested in the research. It may end up being a benefit to all. Some time and resources to fully publish, maintain, and be there to actively improve the work.

I am pretty skeptical about that and I still don't think it's possible for a fast game like dice. But yeh, if you don't publish "how" then we cannot check it obviously (:

If the goal is to increase transparency and honesty, why would one hold it back?  Just curious. 

It's not like people are going to automatically jump at a new company that first introduces the method.

I have a fair method for investors – will publish in due time – but currently in talks with another group that wants to license it to be first-to-market.

Either way, it appears likely to be open-sourced.

Betting on sidechains (with 1s blocks) where investors are all part of each multi-sig ("smart contract") transaction(=bet) by running a program like JoinMarket.

Okay, no, currently that is not possible

Logs/code irrelevant tbh.

I once made an audit idea that was discussed again last month (here) but not really worth the effort.

Any suggestions on how to make this as transparent as possible?

Not a concrete solution, but what if trusted members were able to pop under the hood periodically and check the logs and back-end code?