Provably fair for investors?

[NLNico]

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:

[T04D]

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.

[a1choi]

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.

[🏰 TradeFortress 🏰]

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.

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.

[T04D]

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.

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.

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

[sakira]

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.

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

[NLNico]

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

[T04D]

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.

[NLNico]

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.

[a1choi]

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.

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?

[T04D]

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.

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?

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.

[NLNico]

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.

[T04D]

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?

[T04D]

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.

[NLNico]

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:

8892974    NLNico    19:46    0.00000001 ฿    33x    <3.00    25.23    -0.00000001 ฿

client seed:
nico532523

nonce:
44

server seed hash:
DC8715EAFD90D3FD5E80C071D105F0E07EDC7E3D78C561B1CFEC706CC768D13C9C508A42D8805D4 B1A30485EF0690C88068411E29AFBA8A7592E6F34DB517685

server seed:
tZ2TmS0u4m6v7XXpHj0wpFesp6q/0bgk1UnscBTs+xP8nZ7tYwx2Z0JS857eZnEwgDWY9BYXnZXb99V9o7hrVHY=

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):

Code:

49EAE442D9C93E30511BF4F36CA929C2B8AB94E5E9712B4DCBFE449658DFAFA50E9C2F69F0D74BCC4EBA3A5EFB541B4F5D2614B33DBDDB5214BEABD596DBE9C6

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)

Code:

8892974:0.00000001:L3.00:tZ2TmS0u4m6v7XXpHj0wpFesp6q/0bgk1UnscBTs+xP8nZ7tYwx2Z0JS857eZnEwgDWY9BYXnZXb99V9o7hrVHY=:nico532523

=

Code:

5A18C5626F0960DDE3BE761FD35F496D769529107AA6917496782A8DF1CC68785B237193C5E53F7EF255963AC7A236836892C717582360B3A018D36F085D115C

and 8892974

Audit server saves this information and sends back the seed:

Code:

gbyhi5hkb32hkj5323k25b2

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.

[truedem]

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.

[NLNico]

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.

[der_troll]

This is impossible to make, period

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

[Dabs]

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.

[a1choi]

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.

pm'ing you.