Topic: Provably fair for investors? - page 2. (Read 4782 times)

what i think si that it's time for dicegame to be decentralized also, you can bet against other gambler as a player, and not against the house, it would be more fair imho

are you saying that I didnt understand the main posting by NLNico? or maybe you didnt understand

Basically: no.

Mainly because it doesn't really matter... When you're an investor you're at the mercy of the website, whatever you do.

If you don't trust the site, don't invest. Because they can just leave with your money whenever they want...

hi

I know it is an old thread.

are there any new developments regarding this great idea?

thx

Thats right.. I really wish that someone could make a system to check these sites and make sure everything is fair.

There was lottocoin, and there is that casinocoin, and there is the chancecoin. dogecoin used to have semi-random block rewards for miners. But that got abused (people would only mine blocks with high rewards, since you could see a block before what the reward will be for the next block.)

Worthless alts. hahahahahaah.

But my idea was not an on-chain dice game. Still off-chain, but using the chain as the source of entropy for server seeds or audit seeds or something. The problem is the speed.

Here, we may not necessarily talk about block times, but transaction times. Transactions are near instant in bitcoin. Blocks take 10 minutes. Double-spends would have to be done within 5 to 10 seconds otherwise they lose the race.

The only way for something to be provably fair for investors, is if the site can't predict the outcome, therefore the roll result will have to be revealed after both client and server seeds have been committed. Nonce counting too, if that is used.

The only game that I can imagine can be provably fair for everyone are the slow ones. Lottery draws, for example. Or common table betting games, where multiple players bet on a single outcome. Or sportsbooks (you have to wait until after the game, right?)

Dice is just too fast. And no one wants to play slow dice anymore.

In the real world, lots of people play that numbers game which has 3 daily draws. No one plays the twice a week draw game, despite having a jackpot of millions. (okay, they do, but I was trying to make a point.)

Yeh that is interesting, just not sure about speed even with 1 second blocks.

PRC was lagging a bit so they limited the small bets (0.00001 or smth) to 0,4 per second. People complained already So if it's 1 per second (and sometimes even 2, 3 seconds?) probably more complaints. Remember the players don't really have to care about "provably fair for investors".

But it is interesting. Dicing on-chain on an worthless alt representing bitcoin bets is interesting I guess. But unfortunately I don't know enough about the technical specifics of the blockchain system to think it more through :X

In OP I only said "- The user probably wants the hashed audit seed in advance, but this could be possible I think." but I will explain that further.

1. The dice site generates a server seed, he will request a server-seed-hash-specific audit seed HASH too. And shows it to the player.
2. The player makes a bet with his client seed.
3. Dice site sends bet information (with server HASH and other details including amount,chance,etc so this can't be changed after the result) to the audit server. Audit server uses nonce (and checks if it's sequel) + audit seed to calculate the SHA512 of that combination. And returns that.
4. Dice site uses: client seed, server seed, nonce, SHA512 of audit seed + nonce > to calculate outcome.
5. Gives result to player and repeat.


In the end the player can request a new server+audit seed. So this will:

1. Player generate new seeds.
2. Dice site requests the audit seed with the original audit HASH and the server seed. Audit server gives audit seed and makes that seed invalid for future bets. With the server seed the audit server could recalculate all bets of this session.
3. Dice site returns the server + audit seed to the player.
4. Player can recalculate all bets with those seeds. He can also check the audit website with his audit seed to check all recalculated bets.


Still I think the "site profit" could be faked. So there would have to be a daily, weekly or monthly verification.

1. Dice site generates new server seeds.
2. Dice site sends old server seeds to audit site.
3. Audit site recalculates all rolls and can even calculate the site profit this way.



It helps against:
- skipping nonces / changing seeds etc
- easier verification for players
- fake whales and/or profit (loss)
- hackers cannot win with a server seed or cheat unnoticed



Would that work?

Obviously, once again, players+investors would need to trust the audit server. But it's better because BOTH the dice site and audit site would need to collude/cheat together. Is it worth the trouble? Not sure

My workaround avoids that problem.

1. wait for a player to bet
2. look up their result
3. if they would have won (and rand() < 0.5), take the win for a house bot and go back to step 2
4. give them their result

The audit server will agree with the dice site about how many wins and losses there were.

The problem is that we didn't commit to a player id with the audit server before asking if for the result.

I have one solution. 1 second block time alt-coin. All investors (and players) run the client, peer to peer, hosting it's corresponding blockchain. It won't even be used for it's coin properties, as the coin itself will not have much value, the value is that this "audit server" is in the hands of everyone else but the dice site.

The problem is implementing it. And a bunch of other technical details.

Then again, maybe that is not ideal, and until we can dissect it some more, not sure if it will actually work. (Will it mine? is it proof of work or proof of stake or sha256 or scrypt or X11 or X19 ... and all those other questions; how about a fork or a 51% attack, etc.)

The site still calculates the bets and could indeed decide to only take the winning bets for a site cheater account. But the losing bets would be still on the audit server and therefor the list of bets on both servers would not match.

However, the total investor profit could still be false I guess. Pretty simple to show only winning cheat house bets in the front-end and modify the profit based on that. Or just show false profit anyway, not like people are really calculating all the bets profits.

I guess the server seeds must reset every day/week/month and all the client/nonce/server seeds must be send to the audit server who can then recalculate all the bets. And verify those seeds of all bets by checking the previous saved SHA512 of all the info. If they didn't show a losing cheat house bet, it would appear in this verification. If the total profit is not the same, it would appear in this verification. If they changed a seed to a winning one, it would appear in this verification. If they changed the bet amount (so they win more, lose less), it would appear in this verification.



Obviously by now it gets so complicated that it is probably really not worth it. But theoretically I think it's still possible :p




Ps, provably fair for the player in this situation is atm only "audit seed hash per roll" which can be shown to the player in advance, so they can calculate it after the bet. Obviously this is a problem when the audit and dice site collude and make audit server seeds based on patterns of betting style. Perhaps there can be another way for for verifying the audit's seed.

Basically I opened this thread to get a discussion going, not to give the ideal solution

That seems like a hole in your system.

"in advance" of what? Not in advance of publication of the result, or of the betid.

As the dice site owner, you (the player) send me a bet request.

I make up a betid and send "betid and SHA512(betid:amount:chance:serverseed:clientseed)" to the audit server. Then I can see if the bet wins or not. If it wins, I have the site cheater account own the bet and win with it, then make a new betid for you and repeat.

Basically you'll letting the betid affect the bet's outcome, so I can keep trying different betids until you lose. For all the ones you would have won, my cheater account wins those.

@elm, I think all game sites allow you to check immediately. For some, you re-seed or randomize, get the previous server seed, then check your rolls or your shuffle or whatever.

For others, you wait a day. Win or lose, doesn't matter, everyone can check.

It's on the player to actually do the checking.

I doubt any site is provably fair for Investors. Even if the site owner says it, there is no way to know.  They could always be using seeds against the site investors for small amounts which accumulate to be big over time. And if the site is profitable all that time, then no one would even notice such practice.

please let me ask a question about provably fair for players. please dont kill me if you think it is a stupid one.

I fully agree with someone who mentioned that dice gamblers want to play fast and this is also good for the operator. how about a provably fair option where the losing player could check after the bets (maybe even a day later) if all was fair? IMO most of the the winning players will not want to check if it was fair.

thanks

That's a different issue altogether. Wallet security (cold and hot and online) and who the operator is, should be a different factor.

See, there are several levels of how you want people to trust in your site, both as a player and investor:

1. typical large fiat USD casino = audited RNG, licensed by some country, pokerstars, etc. = not provably fair
2. trusted bitcoin poker site = seals = not provably fair, but is time tested
3. provably fair for players = typical decent dice site, or card game or bouncing balls or lottery or whatever. = at least players can check
4. provably fair for investors = should also be fair for players = no good solution yet, or practical or viable.

At this point in time, the minimum requirement (except for poker, so far) should be at least number 3. Provably Fair for Players.

The other question is one for the operator. Does he have a threshold before disappearing and stealing other people's coins? If he or they do, what is it? Are they competent? Did they do best industry practices (such as using cold wallets properly), are they using time-tested hash functions such as HMAC-SHA512. Are they upright citizens of their own country with no records, are they known, does someone have their info?

All those other questions are of the non-technical nature.

I can be as honest as the Holy Father the Pope (of the Catholic Church), a living saint, but if I open a bitcoin game site that is not provably fair, no one is going to play there, let alone invest in it.

That applies to "provably fair for gamblers" too.

Basically it has nothing to do with provably fair at all and is a pretty obvious statement (yet underestimated by many.)

Just a bump for the topic, but there is already a decentralized way for the audit server to exist. The problem is the latency of this decentralized audit server, and how fast "transactions" pass through it. And if it's small enough and not well protected or designed, it can be killed, but not as easy as the centralized audit server.

The investors would host this audit server, like any other alt-coin. The small ones maybe not, but the bigger ones will definitely want to.

For slow games, like lotteries, cards games, plinko, keno, binaries, or other games that can wait 1 to 5 seconds, this is achievable. But for dice games, or anything that needs to be fast, this might be a problem.

It's easy enough to create one centralized server that can spit out provably verifiable source of entropy (with or without a hardware RNG), the problem is if that centralized server can handle the load of more than one dice site. Or a large dice site with lots of players.

The bitcoin network itself, limited by 1 MB blocks, can only do an average of 7 transactions per second.

And then some bad whale (or shark) decides to DDoS the new coin, or launch a 51% attack, or time warp, or some other yet unknown vulnerability.

Currently, random.org can spit out a secret a day, that is verifiable after the fact, but not before it. Another site, is called Little Bit At a Time, that has a secret every hour.

I could make my own server, that would spit out a secret every minute or every second, but that's as far as I would go.

Dice sites that would accept this trade-off would have to resign to keeping secrets secret longer than an hour or minute or second (like SatoshiDice the classic game that kept secrets daily) and can not allow players to randomize more often.

I may not be making sense, so please dissect this theory.

pm'ing you.

Anyone interested in putting up a dice site (or some other gambling site) with me? As far as I am concerned (and those who trust me) then it would be fair, but not provably. I understand dooglus had this problem for the longest time before launching just-dice, but decided to open it last year.

I lost almost 2 BTC overnight on DB; I invested the night before, the next day it was gone.