Improved Game Channels and Ephemeral Timestamps

Image for post
Image for post

Improved Game Channels

Scalability is a critical difficulty for blockchains in general. If one tries to put entire game worlds (like Huntercoin and Chimaera) onto a blockchain, this is even more true. Therefore, off-chain solutions are critical for the future development and success of these projects.

A possible concept for off-chain interactions are game channels [1]. In the simplest case, they can be used to perform two-player, turn-based games. It is possible to generalise the concept to other situations, but for the purpose of this post, we will consider this situation for simplicity. (The same ways to generalise the concept as described in [1] can be applied, though.)

Roughly speaking, such a game works like this:

In theory, this system enforces that the game is performed fairly and in a trustless manner. No-one can abuse it to “steal” the locked funds without properly winning the game (or if the opponent stops to respond).

However, an attacker might repeatedly wait with sending a next move, let the opponent dispute, and then resolve the dispute. This is not a “rational” behaviour, but it could be used to annoy players on the network and bloat the blockchain in a bid to discredit any project built on top of game channels. This kind of behaviour would also force (both) players to repeatedly pay transaction fees to the miners for including their dispute and resolution transactions.

We believe that there is an evolution to game channels that fixes this issue. Before we can describe this protocol, let us introduce “ephemeral timestamps” first — the core technology that enables the improved game channels.

[1] http://www.ledgerjournal.org/ojs/index.php/ledger/article/view/15

Ephemeral Timestamps

Ephemeral timestamps are a feature of a blockchain-based P2P network, which can satisfy these properties:

The actual implementation of this feature looks like this:

Finally, let us discuss how this implementation satisfies the claims:

The Incentive with Fee Promises

Let us now discuss the incentive structure provided to miners by the “fee promises” attached to timestamping requests. It is of course very important to give miners an incentive to include requests into their blocks, and it is not directly clear that this is possible without actually paying a fee for the mere request alone. However, we believe that the system described above provides sufficient incentive for miners.

The idea is this: Even if a time-stamping request does not by itself pay the miner a fee, there is a certain probability p that the user creating the request will actually want to use it later (as otherwise it would be pointless to create the request in the first place). p can actually be measured in a real system by the miners and/or the network. Then, since the user needs to pay at least the promised fee F to the original miner upon usage of the timestamp, the miner can (on average) expect a gain of p F for confirming the request.

It can of course be that p is quite low, but this just means that the fee promise F needs to be high enough to compensate the marginal cost that the miner has (e. g., in longer propagation time of its block). Furthermore, we believe that this cost will be rather low, since the processing of timestamp requests should not be very expensive to the miner and the network.

However, one potential issue remains: Even if there is some overall average probability p that each request will be used later and thus actually pays fees, a particular user could still send an unlimited number of timestamp requests for free with the intent to just DoS the network and never pay any fees. If this turns out to be a problem, we can solve it by limiting the rate at which individual users can send requests: We can require that each time-stamping request must be signed by the private key of an output holding some minimum amount M of coins, and allow each such output to be used only for one request in each block. With a maximum number C of coins in existence, this implies a hard cap of C / M timestamp requests per block. Thus, as long as there are at least some legitimate users in the system (which have a non-zero probability of using their timestamps later on), p will be bounded from below and thus provide a non-zero incentive to miners for including every timestamp request.

(Instead of a strict rule that each output may only do a single request per block, one could also leave the decision to the miners. By requiring deposited coins, one adds “valuable identities” to the requests. With that, miners themselves can decide upon the rate of requests they accept from each such identity, and how they limit spam.)

Finally, note that if the ephemeral timestamps are used in a setup for game channels as described in the introduction, then the security deposits come for free: In this situation, one might require each timestamp to be linked to one of the game-opening transactions and signed by one of the keys published by the players. This leads to a similar effect on adding a “valuable identity” and preventing abuse, while not requiring any additional effort on the side of the users.

Game Channels Again

Let us now finally come back to the topic of game channels, and discuss how ephemeral timestamps as discussed above can be used to improve them. The idea here is pretty simple: For creating and resolving disputes, we no longer require nodes to get certain transactions mined. Instead, they should send the corresponding data as timestamp requests. By doing so, there is no actual cost in fees as long as all disputes get resolved. Overall, the dispute process between Alice and Bob looks like this:

This procedure ensures, in particular, that as long as a player is honest himself, he need not pay any fees except if successfully making a claim or counter-claim. In this case, he also gets the prize money for sure, which then ideally pays for the fees and some. So a dishonest player can never actually cause damage to the honest player, except for delaying the game to a certain limit.

There is one tiny issue that remains, though: If a player determines that her chance of actually winning the game is very small based on the current state, she may decide to stop responding instead. This doesn’t cause any extra loss for her and the opponent will get the prize, but will need to wait a bit longer for it and also needs to pay some more in fees. This, however, is probably not a very bad situation, and we believe that it won’t be a big problem in practice. (Since, as mentioned, it is at least ensured that an honest player can never have any actual loss, and gets at least the prize money minus fees if the opponent misbehaves.)

— By Daniel Kraft

Written by

True blockchain gaming

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store