This article describes the approach to paying for user transactions in the upcoming multi-player, turn-based, 3D fighting game, CryptoFights (https://cryptofights.io), utilizing the Bitcoin SV ledger.
CryptoFights is a mobile game built in a free-to-play model. Players interact with a central validator bot running on a BitPipe instance which performs match-making, audit-able random number generation, validates player actions, officiates forfeits, and writes game state to the blockchain. Validator is currently implemented in a trusted fashion but all actions are recorded to the ledger and audit-able. This could be replaced by a decentralized protocol or m-of-n signature scheme in the future.
Free-to-play obviously means that the player does not need to have crypto in order to play. One approach would be a second layer of identity stored within OP_RETURN data and transactions could be forwarded on through BitPipe and paid by the validator. That complicates the data structures, and we do not want to reinvent identity and cryptographic proof which already exist on Bitcoin.
This issues is solved by introducing Sponsors to the equation. Space is allocated within the game client and the battle arena for sponsorship billboards which are filled by paying for user's transactions fees. These payment transactions not only include the payment, but also the advertising payload stored in OP_RETURN. Sponsorship transaction outputs are constructed in the following fashion:
- 0 - `OP_RETURN <Sponsorship Protocol ID> <txnId of b:// billboard image> <txnId of b:// sponsor page> [<supported protocol>] ... [<supported protocol>]` where the last element may be repeated for each supported protocol or eliminated if there is no restriction.
- 1...n payment to validator address which covers the cost of sponsorship for one transaction. There will likely be many of these outputs. These can be P2PKH scripts for brevity, or multisig to allow revocation.
Validator indexes all sponsorship transactions and white-lists acceptable content. When a player joins a battle, the following procedure is executed:
- Client software sends request to validator to join battle.
- Validator generates a transaction to send one of the outputs of sponsor transaction to the player address and collecting any associated sponsorship profit margin. Validator does not transmit transaction, but stores it and returns txnId and output index to player.
- Client software constructs transaction including action payload and transmits it to validator BitPipe.
- Validator validates player action, applies game rules and updates state.
- Validator repeats step 2, and includes data in battle battle state and creates battle state transaction.
- Validator transmits all 3 transactions to the blockchain.
- Repeat 3-7 until battle is complete.
A battle consists of an unbroken chain of player actions and validator state updates, and each player action is generated by spending a transaction with sponsorship data included. As such, the sponsorship is preserved forever as immutable property of the battle. When players are participating in a battle, or when people rewatch the battle in the future, the sponsorship elements are presented natively in the client software.