Topic: Provably fair for investors? (Read 4773 times)

Oh, seed server... well, only if the seed server and gambling site do not collude. But that's already stated in the system description, so the performance may be affected, but so far it seems fine. We'll have to see how well it does over time I guess. (Maybe it's been running for awhile now, I've been out of the gambling scene for a bit.)

I guess there is one or more person that will found this way because if they know something that is not right, they will search with every ways they can. we know that everything in the internet is not 100% secure and there will be a gap for the security hole and this will be use by the person which want to find that "secret".

Yes, it's actually exactly the same, so it's nice to see it on a real site (and performance seems fine.)

Only difference I guess is that I said "weekly audit" but instead they "force seed-reset" from user on tipping/withdrawing/etc. but that's same idea (and probably more user-friendly.)

It seems that bustadice has a system that is provably fair for investors.

Just thought it was worth mentioning here.

Yes, there is a way. For slow games, like lotteries or raffles. Not dice games where you need or want the result instantly.

If the game can wait about 10 minutes or even an hour after, you have one of several methods: just use external data (block hash after time is up, real life lotto results, news published the next day = no one knows those until after they come out); you still must trust the site owner to pay out your wins. If the game is a dice game where I roll, and I want to know if I won or not within 1 second after, there isn't a good solution for that. You simply trust the site owner.

sorry if my question sounds stupid but I will not be shy to ask cause I am very interested to see a solution for this problem

owner knows the secret and could cheat.......is there no way that no one will know the secret or will have access to the secret but only after the come out?

something like a multi password like multisig

The problem with a site not having a "provably fair for investors" system is the fake whale, or fake shrimp (salami slicing their own profits). There is currently no known or decent system for fast or speedy dice games that will work. The casino can have their own "in-house" players that look like normal players to everyone else, but have the advantage of knowing the secrets needed to win. There is no way to reliably detect that since they can always just play as close to the house edge as possible and have just a tiny little bit more profit than they should have, no one will notice.

Isn't most of this public knowledge anyway ? The dice rolls and all its history should be on the site. The total waged btc and total profits and losses are shown on many casino sites. These can be wrong if the casino is dishonest but I think that it would be foolish to do that as it will be picked up too easily. How would someone hide the true profits of a casino anyway ? I dont understand why ypu would need a method to verify investments when there are methods to prove dice rolls therefore its just a matter of working out the profits and if the share is equal to the share the casino offers like 50% or whatever.

I agree that the best solution is when no trust needed but maybe I missed this solution in case it exists already.maybe it is there but not workable for games that need many bets in a second. RHavar had the perfect solution but not for games with autobet or many bets a second

I think you're going in the wrong direction. That would be concentrating trust; the ideal solution wouldn't require any trust.

Well that would be some kind of MoneyPot with a slightly different setup and focus. Personally not interested at all in running such service though :X

please let me ask a question. an hypothetically one

lets say a new or untrusted casino like Jackpotracer will ask a trusted user like dooglus, RHavar, Nico etc to do the audit for his site to secure investors and players coins. yes I know it was already mentioned that we could could work together with Audit and run with the coins. but what if the trusted audit also gets the investors coins as escrow and audit same time? I am sure dooglus RHavar and Nico would never partner up with Jackpotracer to steal investors coins as imo they would never run with investors coins and have anyway their trust.

there will always be investors who will not trust anyone but there are many who will trust those users I mentioned

those 3 actually could open an Audit and escrow company for many old and new casinos and it should work imo

what is your opinion?

Totally agree if we are not trust with the site easy just never invest our money on them so i have think same like, this is useless idea.

Have you heard of Contingency? It does just that.

https://thebitcoinstrip.com/blog/the-next-chapter-of-crypto-gambling.html

IMO, as long as there is a chance for the site owner to run away with the investors money, then this idea is useless. No matter how much provably fairness strategy there is on a site, you will still have to trust the owner not to run with your investment. It the same with players as well, a 'provably fair' site does not literally mean its a trust-worthy site.

Overall, its still a good idea and adds a layer of protection from hackers, and investors will have the peace of mind that the owners are not cheating them by making fake whales. Of course, that statement is only true if you are 100% sure that the audit server and the owner are not colluding to cheat you. Maybe someday there will something like a 'trust less' investment.

-uni

The other day we had a topic about "provably fair for investors" again: https://bitcointalksearch.org/topic/bitsler-invest-1787647 I also posted about this 2014 idea. Overall I still don't think it's worth making because of performance loss and not really provably fair (just audit.) It indeed also doesn't remove the risk of site owner running with all money. But it's nice to think about such concepts sometimes

If i understand correctly, this idea of this thread is to make it 'provably fair' for both players and investors. Investors don't have to worry about the site owner making fake accounts and winning.
On the other hand, you are also correct, If the owner of the site just decides to steal and run away with investors money, then there is nothing you can do about it. So in the end, investing would still mean you need to trust the owner of the site to not run with your money because no amount of provably fairness strategy can stop that.

I keep thinking about "provably fair" method that protects the investors too. This all narrows to the fact that site owner should not be able to predict bet results. The only ways to achieve this would be:

- dependence on an external service that participates in generating results - but then you need to trust this service instead, plus the performance issues
- decentralized rolling - again, performance, reliability, plus someone would need to design the thing.

Right now dice sites are capable of running ~ 300 bets per second. It's hard to imagine a truly decentralized system that would achieve similar performance without significant delays.

I hope a system like this emerges at some point, it's just not there yet.

Cheers,
Ethan

I really like your idea, it's great and excellent. I used to think about it, but I did not have an answer for myself. Betting and investing is one of the noteworthy things we need to consider carefully, because It greatly influences the outcome of betting and investing. And most importantly, anyone who builds a gambling site, it needs to be fair, that's the decisive factor, and I'm sure the founders of the site have The trick is to increase the odds, so that they can be more profitable. That's something we need to keep in mind

Nope you understood perfectly.
I'm saying that the whole idea is a bit useless, that's different.
And also saying that because it's a bit useless, the project will not really move.

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.

This is impossible to make, period

There is always someone in the chain who can be blamed if something goes wrong.

I would assume this could be a stream socket between the 2 servers so it's only 1 connection. I am not an expert in that, but if you optimize it I am sure you can make it very quick. But yes, still that would be a disadvantage / technical challenge.

I have service which perform remote calls for wallet deposit and withdraw operations using HTTPS - it takes from 1 to 5 seconds on server side (for visitors it can take longer despite CloudFlare CDN). It's ok when people do such operations once in a while but having 20-50 open connections per second (~100 total) to remote service doesn't look like good idea.

Still replacing session after remote call once per minute per visitor could work to save server resources. But it will allow 1 minute window for hacker.

Interesting idea nonetheless.

The audit server gets only hashed data and gives a random seed. It cannot calculate the outcome because the client/dice server - seeds are still hashed. Let's have an example

My roll on PRC:


They use "n:s:n, n:c:n" in a HMACSHA512 function, so the hash is:
3d97495c452f2d603436606a64004944f66a3102df44c4d483cb3372ea83ff973c37e8b3fd8f9aa aa8c23bd8f8f1e60ae517b1d6033759c785a2e3bc34c036d4

3d974 = 25.2276 = correct


So what would happen is that the audit server generates a random seed and gives the SHA512 hash to the player (or dice site who forwards it to player)

Audit seed hash (to verify it afterwards):

The dice site gets all the info of the roll, hashes it and sends it to the server + bet ID, for example:

betid and SHA512(betid:amount:chance:serverseed:clientseed)

=
and 8892974

Audit server saves this information and sends back the seed:


Calculation now will be "n:s:n:a:n, n:c:n" in a HMACSHA512 function (s=server seed,a=audit seed,n=nonce,c=client seed) and the outcome can be calculated.

This can all happen within 0,1 second.

What will we get from this:

1) Audit server gets only hashes so cannot calculate the outcome.
2) Dice site cannot calculate the outcome in advance. Also the audit site will have a list of all rolls + IDs. If any bet ID doesn't match the HASH of the dice site > there is a problem. In theory you could get all the hashes of all today's bet and make one SHA512 code of it and the dice site can do the same. If they don't match 1 of the bets have not been executed or is manipulated.
3) For the player there is not that many changes. Generally players don't like a seed that changes every roll because in theory the server could change this based on martingale strategies etc. I am not sure how this could be fixed the best.
4) For the investor, he can check if all the bets are really made and if he trusts the audit server he knows none were manipulated. It does require less trust though(!) because 2 people need to "be scamming" together instead of only the dice site owner. Also in case of a hack, they cannot really abuse the server seed.

Wait okay, I think i figured it out.

From the audit servers perspective:


1. the "client/server" seed hash comes in, say it's '1234abcd'. No other data about the bet is received.
2. the audit seed is released every hour, so that users bets can be validated (although they will have to wait an hour) and it hashes together with '1234abcd' to create the new "audit/client/server" hash '5678efgh'.
3. broadcast the hash '5678efgh' back to the site for roll derivation and broadcasting the win/loss of that bet.

Is this right? Interesting, I'll have to think about it some more, but that could make the 'fake whale' scenario considerably more complicated.

So the audit server I don't believe would even have to work with the site server for a fake whale from the audit server to cheat investors though, right? Or am I misunderstanding something?

If you have 5 different players, you will only need 1 fake player's seed. The owner can just loop through seeds for this fake player to find a seed that gives the "right" outcome. So that would not proof anything extra, "better yet" it creates possibilities for the owner to scam normal players (non-investors) - (make a "fake bet" after 4 bets of a big bet, so you can modify that seed to make the big bet lose)

Therefor it needs to be an external extra seed, from an audit server that doesn't work together (hopefully) with the owner (this server can give the hash of the seed in advance to the player so he won't be cheated). Or an external site that could create random data (like Twitter) where it must be important that specific future information will be included and it has a lot of information so it cannot be manipulated.

The method of passing it off to another server doesn't solve the problem of that servers admin betting, and ripping investors off instead of a site admin. Mostly the additional bets (previous 5 nonces might work better) just complicates it a bit, but it makes it possible for sites to cherry pick bets.

but isn't it that once you add one more seed/player unknown to the operator (who is operating the fake bets), it will change the result that that the operator will not know the outcome, even if he has multiple fake user logins playing?

Well for the problem the dice site needs to publish the hash of the info (including bet ID, amount, nonce, chance, seeds) before it is able to calculate the result, get an extra seed after that, then to calculate the result. It would be not possible to change any seed or amount/chance because it was published before it could calculate the outcome.

The extra seed cannot be from the server or the player(s) because in the "fake whale" situation these are the same. It would be fairly easy for a dice site owner to generate 3-5 fake bets from "different players" to generate a winning big roll.

Just to be clear here, are we're referring to future bets as an analogue for tweets? If so, it would be possible to do:

1. bet recieved, logged and site roll hash calculated and broadcast.
2. 3-5 new bets received.
3. first 3-5 non-contiguous user bets nonces are used to re-salt the hash, and the id's of those bets are stored.
4. broadcast outcome.

Some problems:

1. User verification still seems overly complicated.
2. Still not totally unhackable for a site admin, who could just alter the order he processes incoming bets to ones that win, but the same thing could be done with tweets.
3. bet responsiveness relies on site activity.

Can anyone think of how to involve the audit server in step three instead to solve this problem.

That is an interesting approach.

The problem in solutions like that is that you cannot really let the dice owner decide which tweets are included (otherwise you could include/exclude the last tweet to change the outcome - assuming every micro/millisecond-second tweets appear.) So I guess it would work like this:

- dice site publishes hash of bet info (ID, client/server seed, amount, change, nonce) in advance - same as "audit server idea" + a timestamp and timestamp in future of + 1(?) second (or not timestamp but ID + future ID if consecutive.)
- get tweets specifically from that timestamp to future timestamp - make hash of it
- use it for calculation

This could be done all in 1-2 seconds (I think )

Potential problems:

- Have to make sure that the "future timestamp" is really in the future, otherwise dice site can choose which tweets to include. And with +1 second it will be hard for the investors (and even players in this case!) to verify that this doesn't happen for any bet. Perhaps users could setup their own server to accept this data so you can really log and verify it with your own server time etc. If 10 users get this data real-time and verify it, I guess it could work and is better than 1 audit server. In theory you could do this even client-side I guess so all online users verify it in real-time mm.

- Twitter firehose seems pretty exclusive, but I understand that was just 1 example

dice game I think will be faster, which have always win: D

It also needs to be widely available and stored unalterable for bet verification.

We need a low latency, difficult to manipulate, independently accessible source of entropy. That's all.

Something like Twitter's firehose API might work - get entropy from a large selection of the latest global tweets xor'd. Due to the volume, it wouldn't be possible to manipulate it because another user's single tweet can completely flip your result.

i think for some games this decentralized solution will work, but for dice, which is supposed to be a fast game, it'll be almost impossible to implement.

I like this idea, I've spent a lot of time thinking about this problem without much luck. The problem here is that bets and investment changes have to be processed atomically such that an alteration to a users investment or bet is processed to completion, which affects max bet, etc. before any other bets/investments are made. So if you're sitting around waiting for a remote response, time delays on bets could actually require quite significant delays to get each bet processed completely. There are some kinda hacky work-arounds, like dropping the bet if the max wager/bet changes such that the bet is no longer valid, and batching bets together into a fifo queue so that data is only exchanged between the audit server once per 1-2 second but then users are always waiting a minimum of 1-2 seconds for each result. I'd say it's worth it IF anyone can come up with a 100% trustless way to organize the audit server though. It also makes verifying users bets significantly more complicated.

Also, if this is in response to recent events, I should like to note that players were the ones who were being defrauded, not investors, although this is an equally (if not almost more so) important threat.

Good line of discussion though, interested to hear others ideas, too.

Hello,

I am aware that current off-chain dice sites are provably fair for the users (if implemented correctly) but not really for the investors. This means if anyone (for example dice site owner or hacker) has the server seed they could fake bets (adjusting the server/client seed/amount/hi-lo/etc) to make sure they can win. I am wondering if there could be theories or methods to make this risk lower or a method so the investors would need less trust in the site owner for the "fake whale problem" and "hacker has server seed problem".



Only thing I could come up with is a third-party audit server. Basically:

Dice site sends hash of: (bet ID, client/server seeds, nonce, chance, amount) in advance to audit server, audit server returns extra seed. Audit server only has hashed server/client seed so doesn't know outcome. Final result will be calculated with that extra seed so in advance dice site doesn't know outcome.

Afterwards everyone could verify all bets to see the dice site didn't change the server seed to a winning one. Or if there are any missing bet IDs or changed amounts. So:

- House cannot cheat with "fake whales" (as long as you trust audit server.)
- Hacker that can get the server seeds will have to hack the audit server too, therefor this is less likely to happen.

Important:
- This only works if the dice site and audit server are from different persons and don't work together. So it still requires trust. Also it only focuses on this specific "abusing server seed" problem, not stealing the BR etc.

Notes:
- For performance it requires an extra external request per bet, although this should be possible.
- Transparency is important, should be easy for investors to verify. For example a weekly output of all bets from both the dice and audit servers + script to verify. Or more easy: dice+audit could both generate a hash of all info in same format of today's bets, then compare if it's the same.
- The user probably wants the hashed audit seed in advance, but this could be possible I think.




A trust-less, decentralized method would be better, but the bet results should be ready in 1-2 seconds and I think that will be difficult that way. Would be cool if someone has ideas for that though.
  


I expect the reply to this will be "not worth it since it's still not 100% proof." But still I am interested in alternative ideas or if this idea would be reasonable and at least better for investors? And if there is a flaw in my theory (besides trusting audit party to not work together), please tell me :>



edit: I think this would btw also work for sites that skip nonces, but that was not my intention or goal.

edit2: