-
Notifications
You must be signed in to change notification settings - Fork 4
Kogs cc validation rules
Kogs cc operates with NFTs representing kogs, slammers, containers and packs. There are also non-NFT but similar objects like gameconfigs, players, games and batons. All NFTs and non-NFT objects contain EVAL_KOGS evalcode so they are sent over the kogs cc validation code.
NFT transfers with no kogs cc OP_RETURN vout are not validated and considered as kogs or slammers free transfers between users, the only exception is that such transfers are disabled with the kogs global pubkey (to prevent unauthorised transfers from game and container 1of2 addresses).
Other kogs transactions contain OP_RETURN vout with funcid and objectType fields. There are only two funcids possible: creation 'c' and transfer 't'. The objectType field determines the object structure type.
Some kogs transaction objectTypes are operation codes and validated by kogs cc validation function.
Those operations are: adding and removing kogs to/from container, depositing and claiming containers to/from game, slam data creation, baton or gamefinished object creation and stopping player advertising.
Other funcids are prohibited in the validation code (however they are still possible in object creation transactions that are not sent through the cc validation code as they do not contain cc inputs. Such creation transactions are validated when they are being spent by txns with operation codes. The descriptions of that are following below).
Batons indicate slam turn passing to a next player, they also contain the current state of the kogs stack and the won kogs by the players. The Gamefinished object is the final baton for a game and it also contains the won kogs by the players and yet the winner playerid.
Batons or gamefinished spend the previous initial game or slam data tx.
Gamefinished tx also contains token vouts to return the deposited containers to the owners.
The performed checks are:
- Load the previous initial game or slam data object, the loading function checks that the previous object is valid (see loading function checks description below)
- Load the previous game object and check the fixed baton amount value (TODO: combine with the previous check).
- Call baton creation function to create a test baton or gamefinished object and compare it with the validated object
- TODO: check in the baton creation function that the containers are sent into a game only with a validate 'deposit container' operation code (check this code in the opret when listing containers on a game), ignore the containers sent with a simple token transfer rpc
Only for gamefinished:
- check that all tx's 1of2 vin addresses match the gameid
- check that all container and slammer vouts are sent to the their owners by checking the destination pubkeys
- calculation of the winner player id based on the flipped-kogs-by-player array
Only for baton:
- check no spendings with global pubkey (to prevent spending from 1of2 addresses for batons)
- calculation of the new stack state and flipped-kogs-by-player array based on the slam data and the previous stack state
Checks in the baton and gamefinished creation function: checks for batons (maybe we need them only for the first baton...):
- check deposited container number == player number
- check each container size == config
- get playerid owners in each container and check owner size == playerid size (do we check playerid matches containerid creator pubkey?) (do we need to check that the set of playerids who deposited the containers match the set of playerids in the game?)
- get deposited slammers and check their number == player number (we do not check slammer owner pubkeys yet. How to check them?)
Operations of adding or removing kogs to containers are needed for organising user's kogs The checks are:
- load the referred container (the loading function also checks the container validity)
- check the container is still on the owner pubkey (not deposited already)
The checks only for the adding kogs operation code:
- check no spendings with global pubkey (to prevent spending from 1of2 addresses)
- TODO: maybe add check that sent kogs were on the container owner pubkey (to prevent sending other user kogs to the container)
Checks only for removing kogs operation code:
- check the tx has inputs signed with the container owner (to ensure this is the owner who claims)
- check that the all spent 1of2 addresses in the tx match the containerid
- check that all the kogs are transferred to the their owners and there is the only destination pubkey (maybe simply check that kogs are sent to the container owner?)
- the container owner pk matches the destination pubkey for the sent kogs
Containers are sent to a game to allow to make the kogs stack and begin slams. The checks are:
- load the referred game (the loading function also checks the game object validity)
- check the game is not started or finished (that is, no batons yet or gamefinished objects are already created)
Only for operation code of depositing containers to a game:
- check that there no spending with the global pk
Removed these checks for adding as all of them are checked in the baton creation function:
- for all the being sent containers get their owner pks and check if each owner pk has not already sent a container to this game
- get the game config and check for each container its kog size matches the param in the config
- TODO: check each owner is sending only one container and one slammer
- TODO: when getting kogs on a container, check that the kogs are sent into a container only with a validate 'add kogs' operation code (check this code in the opret), ignore the kogs sent with a simple token transfer rpc
Only for operation code of claiming containers from a game:
- check the tx has inputs signed with the container owner (to ensure this is the owner who claims)
- check all cc vins are valid 1of2 addresses corresponding to the gameid
- get owner pubkey for all the tokenid on the game address and for each token vout check each container and slammer is sent back to its owner
- TODO: maybe add a check that each cc vin must match the container vouts (to prevent sending containers to unknown vouts to try to destroy them, however the tokens validation code would guarantee that no token satoshi is ever lost so this is not possible)
The checks are:
- load the spent baton (the loading function checks the baton validity)
- load the game object (the loading function checks the game object validity)
- load the playerid (the loading function checks the baton validity)
- check that slam data creator pubkey matches the playerid creator pubkey
- check that arm-height and arm-strength are in the acceptable intervals
- check that there is no spendings with the global pk in the tx
The checks are:
- for the first cc vin load the initial advertising object (the loading function also checks the advertising object validity)
- check the the validated tx creator has normal vins signed with the pubkey that also signed the source advertising object (to prevent unauthorised spending from the global address where the advertising marker is located)
- check that playerid in the source ad object matches the playerid in the current tx
- check that no other cc vins exist that spend with the global pk
Common checks for NFT txns:
- check the opreturn and parse it into a C++ kogs object
- find the cc vouts and check if any of them match the tokens in the opreturn
- check that the total token amount == 1 sat
- for creation tx check that there are normal vin signed with the creator pubkey stored in the token opreturn
- for kogs, slammers, packs it is checked that the syspk is the creator
Common check for non-NFT txns:
- check the opreturn and parse it into a C++ kogs object
- TODO: for the creation tx check that there is a normal vin signed with the creator pubkey stored in the opreturn