Idea to show proof of randomness for gambling app without blockchain

[Watanabe Blue]

When designing a gambling game on the blockchain, there is the issue of randomness. Even if we take the timestamp of a block and hash this as a pseudo RNG, the problem is that (miner influence aside and assuming this suffices as an RNG source) there is a long delay between each block being mined, and also high expense in smart contracts particularly when accessing/manipulating the smart contract.

I thought of a potential way around this for gambling related and similar sites and wondered if it's been done before, and it not why not. The idea is simple:

Make the site centralized and only communicate with the blockchain after the game to resolve bets. How to then prove to the player that the cards are random? The idea is to generate 52 random new public:private key pairs before each game and send only the public keys to the player. Each public key represents a card from a 52 card deck. The player is the one that can then shuffle these public keys however they see fit, or alternatively use a fully transparent open source offline shuffler that the site will provide. The player sends these public keys back to the site in the order they wish, and the site confirms the order arrangement. After that, the game begins and each public key is "dealt". When a card is exposed, the site will reveal from its centralized database the corresponding private key for the public key of that card. The private key will simply return a hash % modulus 52 that will pre-determine what the card is. Eg: if the private key ends in "51" this will always represent the King of Spades.. a "38" will always represent a Queen of Hearts (for example). In addition to this, after the game is finished, all remaining private keys for the 52 public keys are exposed and the player can verify for themselves that they are indeed randomly distributed.

This way the centralized site cannot cheat since they must prove that the card they dealt is what it is via the % modulus 52 of the private key which is only revealed after the card is shown. The site cannot put the cards in a specific pre-determined order since the player will be the one to shuffle and determine the order of the public keys. The site cannot fabricate the card distribution since the player can verify for themselves that the cards are randomly distributed.

Player funds are then kept or returned with a winning at the end of each game or session via blockchain, thus saving huge delay times waiting for a new block to be mined for every card.

[domob]

Take a look at "mental poker" (e.g. https://en.wikipedia.org/wiki/Mental_poker).  That's very similar to what you describe.

[Watanabe Blue]

Take a look at "mental poker" (e.g. https://en.wikipedia.org/wiki/Mental_poker).  That's very similar to what you describe.

Very interesting read and thanks for sharing it! It does seem like this problem has been well thought out by a lot of people. I cannot help but notice however all the solutions on that page require both parties ("Alice" and "Bob") to both conduct encryption, which may require extra overheard for the player. With the idea above, the server "Bob" would be the only one encrypting, and Alice the only one shuffling the encrypted keys.

Perhaps I'm missing something as to why the extra complexity on that page is needed when we could do the modulus % 52 of the private key method and then let the player shuffle the public keys. I'm sure I'm missing something simple as to why this method isn't used.

Whatever method is used, I cannot help but see this as a fantastic solution to maintain trustlessness for gambling-related RNG in a centralized environment, and only interact with the blockchain when resolving the actual bets?

[domob]

I'm not an expert on these matters myself, but I think the problem that "encryption by both parties" solves is that in your case, the server actually knows the order of cards.  This may not be a problem for some games, but it would be a problem for poker between Alice and Bob (for instance).  And even in your situation, both parties shuffle the cards - the server has to do so before passing on the cards to shuffle to the player, as otherwise the player knows the order and can shuffle to his or her desired deck.