Crypto Card Game

[Nagalim]

The purpose of this thread is to outline a design for a trading card game that is hosted by Peercoin. To maintain decentralization, we can use a PeerAssets protocol with a proof-of-burn issuance model whereby each card ‘unit’ requires burning 1 Peercoin to create.

We will say that a complete ‘deck’ is represented by an address that holds PeerAsset cards. We could have 0 digits and have each card be represented by an integer, but I want to think a little outside the box here. We cannot play this game normally, with many turns where cards are drawn, because we really want to keep txn fees as low as possible. So a deck need not actually contain integer cards. Instead, we could require a total deck size of unitary ‘1’ and allow additions of fractional points to accumulate to unitary. For example, your full deck could consist of 0.15 ppc, 0.6 btc, and 0.25 eth. Therefore, every deck costs ~1 ppc to create.

You now have an address with cryptogame PeerAssets that sum to 1. To initiate a game, use this address to send a txn to another decked out address that contains a call-to-arms in some way. The receiving address will then submit a duel acceptance transaction with 0 output. The block that this is confirmed in will act as an impatial judge by providing a random number seed through the block hash. The moment the transaction is submitted, the game is over and all that’s left is to tally the points.

You could also have the two parties submit their txns with a corresponding bet to a trusted third party that will then send the winnings to the winner. While this removes some decentralization, the trusted party can be chosen by the two participants to be basically anyone who can be trusted to tally the total and send the award to the winner.

The points tally can be extremely general and new cards can be added. Let’s assume an address has X Bitcoin, Y Peercoin, and Z Ethereum. The score tally can be any function f(x, y, z, block hash). As a simple first pass we could impose different separation of variable schemes like f(x,hash)+g(y,hash)+h(z,hash); but really any formula can be used. This can result in different cryptos having different algorithmic ‘powers’, such as ripple being a total multiplier, or tether adds a static value, or Peercoin changes the score exponentially. Really anything goes, the trick is to find a good way of balancing the different cards. This can be done via a normalization scheme (such as the integral of the function over all hash values must equal 1). It could potentially get quite complicated an nuanced.

Rules and card spawning will need to go hand in hand. However, the general idea would be to impose rarity on cards by limiting the cards to, say, one unit per 10,000 blocks. This has some real implications for the market that might pop up around these cards, as well as how to compose your deck. Maybe you’re stuck with an all ‘waves’ deck until other other cards become available. You would need to burn your coin in advance in order to wait in line for the rare cards, of course.

There can be other layers built on top, including graphics and guis. Companies could pop up that support the gambling aspect. Competitions could be run. There are limitless avenues to go with this. I think it’s worth talking about anyway, because it really showcases some of the possibilities of crypto.

[Nagalim]

Maybe you could use some off-chain LN-like techniques to reduce this whole thing down to one txn. The two parties timelock coins and give each other unsigned txns or something. However, without codifying the rules of the game into protocol, it will always require a referee. Maybe you could use multisig addresses so that the referee doesn’t need to be trusted, i.e. form a 2-of-3 multisig with the two players and the referee, then send the game initiation funds there. This would result in a total of 3 transactions, but seems the most straight forward way to include rewards without requiring infinite trust in a third party (can’t run off with funds but can be bribed).

The version that doesn’t have any referee is pretty cool though for the decentralization of it. It is quite difficult to do the award system in native Peercoin however without any smart contract functionality or centralized servers. Of course, you could create another PeerAsset that acts as a reward system, but that has all sorts of complications and likely introduces a centralization aspect in order to give the reward any value aside from bragging rights.

[Nagalim]

Turn the block hash into a number between 0 and 1 called ‘s’.

Start with a score s.

Tether:
For x Tether, add x to the score {s’=s+x}. This always comes first in order of operations.

Bitcoin:
For y Bitcoin, multiply the score by 2y+1 such that s’=s+y*2s. This is level 2 of order of operations.

Peercoin:
For z Peercoin, the new score s’=s+z*[e^(s)-e+2]. The irrational number e is approximately 2.718. This is level 3 of order of operations.

Each of these is a term proportional to the quantity of cards and added onto the score so that adding a small amount of a new card doesn’t change the answer much. This is the general form we are looking for. We also want to ensure that the integral of the addition from 0 to 1 given unitary cards is equal to 1.

[Nagalim]

Order of operations doesn’t matter if you don’t inter-couple the equations (which also makes balance and fairness proving super easy, just add a constant to literally any equation such that the integral is 1).

If you encode literally all the rules (in this closed addition-only form that’s not actually so hard) you can automate playing for keeps. You can use a flag to signal you are open to playing, then anyone can freely initiate a game. If they win, they take your tokens. If they lose, you get their tokens. In this way, the single game txn is not only the entire game, but also a movement of funds. The only complication is how to do the flagging process efficiently. Also that validating any of these txns requires resolving every game that’s happened, but again that isn’t necessarily that hard. It would require its own client though.

There will have to be an additional selection rule to prevent abuse of delta functions. Something like the equation must be continuous and differentiable and have all derivatives lower than or equal to e at all values between 0 and 1. We can add arbitrarily many rules here if we desire because these are done off-chain in the process of choosing which PAs are ‘real’ cards for this game, then hardcored in on client updates.

[Nagalim]

Minimal viable product here can be done on testnet with no changes to protocol. A horde of tokens can be created with the webapp and sent to friends and proxies. Then, an initiation txn can be sent as just a dust amount of tppc from one address to the other. Then we use a python program to tally the score and see who won. Out of all of this, we only need develop the ‘referee’ analysis program at the end.