1

Here's a toy example of a game: the player is presented with N slot machines. They can click on each slot machine once, and when they do so, the slot machine rolls a random outcome (based on a predetermined set of outcomes and probabilities).

If the slot machine outcomes are rolled on the server, there is obviously no opportunity for the client to cheat: the server has full information to arbitrate which slot machines have already been rolled and what their outcomes were.

Suppose the client and server communicate only twice: once before the game starts, and once after the game ends. Is there any kind of protocol that can guarantee that the client cannot cheat?

Obviously, the client cannot simply report to the server what rolls the player achieved on all the machines; the client simply reports N jackpots.

Better would be for the client and server to agree on a method of determining the slot machine outcome, based on the image of a one-way function of the time stamp when the client clicks the slot machine. The client reports to the server the (time stamp, outcome) pairs for each slot machine, and the server can verify that the outcomes are correct given the time stamp.

But this protocol is still not secure; it may not be tractable for the client to invert the mapping from time stamp to jackpot, but it can try many possible time stamps and report to the server the N most favorable outcomes.

Is there any protocol that can guarantee (perhaps given additional assumptions about the computational power available to the client) that an untrusted client cannot cheat at this game? If not, is there an argument proving impossibility?

user168715
  • 119
  • 2

2 Answers2

5

No, you can't protect your game from cheats if rolls are made from the client.

The main point of failure of your protocols is here

The client reports to the server the (time stamp, outcome) pairs for each slot machine, and the server can verify that the outcomes are correct given the time stamp.

And you demonstrate its vulnerability below

But this protocol is still not secure; it may not be tractable for the client to invert the mapping from time stamp to jackpot, but it can try many possible time stamps and report to the server the N most favorable outcomes.

Nothing prevent the client from reporting a false timestamp. Moreover, even if there were a way to force the client to report every rolls correctly, in your particular case of a slot machine, the fact that the client might be able to guess its next rolls would be a critical vulnerability.

Xavier59
  • 2,924
  • 4
  • 18
  • 34
2

When it is a pure game of chance where the player interaction is just faked (like many gambling machines), you could use a deterministic pseudorandom number generator on both the client and the server. When the player buys coins, the server generates a seed for each coin and remembers it.

When the client wants to cash in their earnings, they reconnect to the server and tell them which coins they played. The server can now verify that it is a "winning" coin by simulating the game using the same seed.

However, this system falls apart as soon as the player can make any relevant decisions during the game. In that case it could play multiple variants of the coin and report the one where they scored the highest. There is no way for the server to detect that the client did that.

Another crucial weakness is that you can not let the player refund any unplayed coins, because if you let them they could request a refund on any "losing" coins and cash in the "winning" coins.

tl;dr: Just make it an always-online game with an authoritative server and dumb client. The gameplay restrictions aren't worth it.

Philipp
  • 49,384
  • 8
  • 129
  • 160