Multichain decentralized cashier for gaming

  1. Accept payment in USDK for a specific player pubkey on a specific table. Each table will have a chipsize variable, so $100 would get you 100 chips at a $1 table, but only 1 chip at the $100 table. Since chipsize is a table specific abstraction, the cashier just needs to know the amount deposited and be able to provide proof of deposit for the player to use at the table. To avoid fractional chips issues, the cashier will need to be told about a tables chipsize and it would only accept funds in multiples of that. Maybe any excess becomes a donation.
  2. The player will present proof of deposit and obtain the proportional amount of playing chips. In reality, the user would need to have opened a CHIPS LN channel to the dealer and fund it with enough CHIPS to support the gameplay. Since the LN denominations can be set to very small amounts, the same 100 CHIPS would be enough for a lot of playing. CHIPS is designed to scale to a very large number of users. Care must be taken to not allow the same proof to obtain table chips more than once, but since each cashier deposit is tied to a specific table, that just requires that each table keep track of all the txid accepted for deposits.
  3. Each table needs to maintain a balance for each player that is allowed to be played. The amount of CHIPS will likely be many multiples of the actual amount deposited, so the table needs to reject any attempts to spend via LN the table chips that is in excess of what the player has! This list of table balances is a critical part of the cashier protocol. Whenever the balances changes, all the players and dealer need to update the player balances and attest to the correctness. In the event that consensus cannot be achieved on this, then all play at the table needs to stop and the last achieved consensus be used for withdrawals. This drastic step is needed to have a strong reason for all nodes to agree on the table balances and for non-consensus to arise only when there is a bona fide dispute.
  4. At the beginning of each game, all the players know the balances of all the players. A game specific sequence of signed events happens which creates a set of changes to the player balances. Given the set of signed events, anybody can deterministically determine the new balances and all the player nodes, along with dealer and other authorized nodes would validate the new balance and attest to it. This concept of players, dealers and other nodes being able to attest to a specific game implies that when creating the deposit, the list of approved pubkeys needs to be submitted. The table (this includes all current players, dealer, approved observers) would then make sure that the list of approved pubkeys is valid. To achieve this, a table needs to be able to be queried to obtain the current list of approved pubkeys. Now, it is possible that players come and go, which means that each player would need to be able to update the list of approved pubkeys. This would require attestation by a majority of existing approved pubkeys, say N/2 + 1. That will allow the active list of approved pubkeys to constantly evolve and it is a property of the table. Changes to the approved list of pubkeys is thus attested to by the table and given the starting list of approved pubkeys and all the changes to this list as the play has proceeded will allow proof of the current approved list of pubkeys at any given point in time.
  5. Each table is responsible for maintaining the list of approved pubkeys along with player balances. When a player decides to cashout, he must leave the table and get an attestation from the rest of the players that he left the table at a specific timestamp with a balance of X. It is possible for an evil table to try to cheat and say that players have more balance than they actually do, however, these games are zero sum games so the total balance deposited to the table is sufficient for paying any valid amount from that table. If a table will be colluding against a specific player with N/2+1, it is like a 51% attack and this will work. It could be that the threshold needs to be set to N, where N is the number of players, but that would open the case of funds being frozen in the event any player goes missing, ie. via rage quitting. There is no need to lock in the exact MofN needed as it can be a table parameter, along with external observers. For large stakes games, it is suggested to have a relatively large number of trusted members being observers, so there can be 7 independent observers to ensure 51% attacks are not being done.
  6. The last thing that needs to be done is to properly handle a withdraw. The player would request the table to leave the table and at that point, the player is not able to play anymore as his table chips balance is set to zero. In exchange, the players current attested balance is generated. This means signatures from the table. The player would submit that, along with the set of approved pubkey changes the table generated for the duration of playing. Combined, this allows the cashier to verify that the player has a peer validated balance that can be withdrawn. This is the only thing that can be done with the balance and it can only be withdrawn to the players pubkey. That eliminates using valid proofs to make an invalid destination address.

--

--

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