CHIP and a Chair - Let’s use Bitcoin’s Lightning Network to create a Poker Game

We forked Bitcoin and created CHIPS. This new project is more of an internal component of the Komodo ecosystem.

CHIPS will be the only coin in our ecosystem which would be using Segwit, and the Bitcoin Lightning Network technology. The technology is excellent for micropayment channels.

There won’t be any ICO for CHIPS, but we are looking for people who actively participate in the development or testing. We will certainly need as many people for that as possible.

Many different casino and poker games could use CHIPS

For Pangea Poker I needed a way to implement gaming chips. Lightning network (LN) seems a very attractive solution. However, because LN requires the latest BTC I had to fork Bitcoin 0.14 to get a testable environment.

fork of BTC 0.14
fork of Elements lightning C daemon

Please refer to the docs for the original projects; I made little changes to them as possible.

Privatebet (BET Komodo assetchain) is implementing a generic decentralized gaming platform and will be using CHIPS for the internal ledger of the in-game betting results. However, specific plans are subject to change until it is all finalized.

Since the casino games will have a relatively short lifetime, as long as the market price of CHIPS does not change very quickly, people can purchase CHIPS to use inside the games, and then redeem them via BarterDEX at close to the same price. Maybe even some time limited pricelocking can be implemented with CLTV.

Dealing Table Sets for Pangea Poker

After posting various questions and issues with LN, it seems that multisig won’t be available for quite a while. So, I need to have a different method to deal with table bets.

Here is what I propose:

Each table has a "dealer" who is the responsible node for managing CHIPS. Externally, each dealer would have posted a performance bond of up to XXX KMD with some arbiter.

Each player that joins a table would have their independent amount of CHIPS, but they open a payment channel to the dealer.

the dealer opens a payment channel to each player as they join, which means the dealer needs to have at least N times the average number of CHIPS for each player's channel.

For each hand, the LN payments are made to the dealer. At the end of each hand, the dealer pays out to the winning player(s).
In the even the dealer does not make the required payment, the arbiter would be contacted, and the validated amount would be distributed from the performance bond.

There is some risk of a dealer using the same performance bond for many games and waiting until there is more than his performance bond in his hands. So, a reputation of the dealer will need to be a factor in how much people would feel safe in betting per game.

From the early stages, this won't be an issue, and eventually, we should be able to have a multisig (or blockchain) controlled LN account.

Background of our Pangea Poker Project

SuperNET team did not start Pangea Poker. The original project ran into technical issues during the bear market and disbanded.

I agreed to take over the development under the condition that it does not impact the other things I needed to get done. It did have a GUI and a working alpha release about two years ago, but then the NXT thing happened, and KMD dPoW, notary nodes, pax, 5% APR, hacker attacks, LP nodes, BarterDEX and a few other things intervened.

Anyway, I have generalized the decentralized card shuffling and dealing to handle any number (up to 255) and many more players (32 to 64) than needed for standard poker. The generalized gaming platform will be under Privatebet (BET assetchain), which is 60% owned by JUMBLR. So this rather directly relates at this point.

I am still in the process of finalizing the low-level protocol, but the test programs are creating randomly sized decks with a random number of players and shuffling/dealing face up and face down pretty well. The protocol has an externally generated encrypted deck that is combined with a deterministic shuffle based on every player's shuffling (with a commitment step to prevent there being any "last player" to shuffle).

What this means is that before revealing of the player's shuffle after the commitment step, nobody will know the ordering of the cards. Afterward, all players will know the order in the encrypted deck. But it is encrypted. To decrypt (and to solve any player disconnect issues), when dealing each card the MofN shards (using Shamir's secret sharing) are sent to the destination player by the other players, so only the player who gets the card can see it. If it is a face-up card, it is just decrypted by all players, and it is possible to verify that each card is valid and the entire deck has a checksum to make sure each card is actually on the deck.

At this point, the low-level protocol is sufficient for most use cases, especially ones without any face down cards, like roulette, slot machines, craps and most casino games. For high stakes poker, the small attack vector of the external deck creator colluding with a player exists. Even in this case, all it would allow is for the colluding player to see the face down cards, but that is quite an advantage in some cases. I have a way of making it so that even with collusion no player or even deck creator would know what the cards are, but it will be quite a bit of work to do that and also allow recovery from player disconnects, so I wanted to solve other parts first.

Still, a matter to integrate generalized game play state machines on top of this, but that is a matter to create a complete list of events possible for each game and a game evaluator based on these developments. Easier said than done, but conceptually just a lot of tedious work so I am not worried about that part.

What I am dealing with now is how to address the betting. I was surprised at how fast poker players play online poker. Coin confirmations are just too slow to keep up, not to mention a lot of blockchain bloat. While investigating various possibilities, I looked into LN and so far it is very promising. To experiment with this, I need a new Bitcoin fork that ideally I can make any required changes to. So I made CHIPS. I also forked the Elements C based LN node and got it working with CHIPS. At least it is talking about it, but no peer to peer transactions yet.

The tricky issue is that players need to commit funds to an unknown outcome while the current hand is being played. Who controls those funds? If it is a multisig, then what happens if N-M players disconnect? When players lose, they lose financial incentive even to stay connected. One possibility is to create ever smaller MofN destinations as each player leaves the game, but all of that is more latency and lots of complication.

Once the LN code is integrated into the Privatebet platform, that will allow instant bet processing and combined with a cashier functionality. I think it can be leveraged to work in all the BarterDEX currencies. The one big question is whether LN directly supports MofN owned addresses. Based on my current understanding of the LN architecture I don't see any reason it can't, but I highly doubt the early implementations already have this working, so I will likely have to add such functionality into LN. An alternate method that uses the existing LN functionality would be to have a "dealer" node that safekeeps the table-stakes and have a way for the players to sign off on a game's result. In this case, the conversion of CHIPS back to whatever original currency would be contingent on MofN sign off or some other dispute resolution. Some issues are left to be solved.

For now, I just need to get more familiar with what exactly LN can and cannot do and at that point finalize the method for integrating CHIPS into Privatebet. One interesting idea is to allow the purchase of CHIPS by different currencies at market prices and enable them to be redeemed into various currencies. That way you could end up trading coins by playing games.