Merging all the changes till deck updation at player ID

docs/protocol/predictable_betting.md

@@ -43,7 +43,7 @@ The cumulative bet amount collected on various possible predictions of the bet i
 | false	      | 300(200+100)  	      |
 
 Here in the prorata bets, the winning bet amount is calculated as follows:
-Lets say the commision taken by host is 5% and validator nodes is 5% for simplicity. In that case 97% of the bet amount is distributed to the winners.
+Lets say the commision taken by host is 5% and validator nodes is 5% for simplicity. In that case the remaining 90% of the bet amount is distributed to the winners.
 ```
 winning_bet_amount  = bet_amount+ 90%(all_bets_lost_amount) * (bet_amount/all_bets_win_amount)
 ```
@@ -55,7 +55,7 @@ all_bets_lost_amount = 300
 U1_win_amount = 100 + [90%(300) * (100/800)] = 133.75
 ```
 
-Like wise if we recompute all for all the users the final bet settelement table looks as follows:
+SO the final bet settlement amoutn for all the users based on the outcome A won over B is as follows:
 
 | User        | A wins on B | bet_amount | bet_settlement |
 | ----------- | ----------- | ---------- | -------------- |
@@ -102,19 +102,19 @@ Here the host can make a counterbet to the existng bets to change the status fro
 The most important thing in the predictable betting is the outcome of the event, and how this outcome of the event is legitimately provided to evaluate the bets. Here we are relying on the validator nodes to feed the outcome of bets and in return the validator nodes gets incentives in answering the bet queries. Its important to note here that the validator nodes are elected by the bet community who are trustworthy in the bet environment and in order to become a validator node one must need to meet certain constraints and guidelines set by the bet community.
 
 To become a validator node one must
-a. Go through the election prcess, where the chips holders vote for a specific validator node applicant.
-b. The validator node must show the proof that they possess 50k CHIPS.
+* Go through the election prcess, where the chips holders vote for a specific validator node applicant.
+* The validator node must show the proof that they possess 50k CHIPS.
 
-Whenever the host posts the bets, those bets are visible to all the validator nodes. The job of the validator nodes is based on the outcome of bet the validator nodes answers the queries and store them in the local in the local DB against the specific bet ID. 
+Whenever the host posts the bets, those bets are visible to all the validator nodes. The job of the validator nodes is based on the outcome of bet the validator nodes answers the queries and store them in the local DB against the specific bet ID. 
 
 Once the outcome of the event is revealed in the real world, the host sends requests to the validator nodes to get the outcome of the bet and evaluate the bet accordingly to settle the betting amounts. If the host fail to process the bet with in the time window specified, the users can raise dispute requests with the validator nodes where in which the validator nodes will process the outcome of the bet and settle the funds. The validator nodes gets incentivised for being honest in answering the bet queries and for being available in responding to the host nodes.
 
-The incentives to the validator nodes are based on the queries it answers. The more queries it answers the more incentives it gets. We discuss in detail about how the system is resilient against the dishonest validator and host nodes, and how the dishonest will be moved out of the network and costs incurred for being dishonest in later sections.
+The incentives to the validator nodes are based on the queries it answers. The more queries it answers the more incentives it gets. We discuss in detail about how the system is resilient against the dishonest validator and host nodes, and how the dishonest host/validator will be moved out of the network and costs incurred for being dishonest in later sections.
 
 ## Lets talk about API's
 
 ### Listing the bets by host
-Host nodes are the ones who are responsible in creating the prediction markets by posting the bets. In `bets.ini` host lists the bets and publish them to the players when the player node connect to the corresponding host. The sample congiguration data in the `bets.ini` looks as follows:
+Host nodes are the ones who are responsible in creating the prediction markets by posting the bets. In `bets.ini` host lists the bets and publish them to the players when the player node connect to the corresponding host. The sample configuration data in the `bets.ini` looks as follows:
 ```
 [bets]
 [bets:0]
@@ -157,7 +157,7 @@ After connecting to backend from GUI, the GUI receives bet method from the backe
 		"confirmed_bets":[],
 }
 ```
-From the GUI the player picks one or multiple bets and send the info to the BE, lets say the player selects the bet "A wins on B" in that case the info the GUI send to BE is in the fowm as shown below:
+From the GUI the player picks one or multiple bets and send the info to the BE, lets say the player selects the bet "A wins on B" in that case the info the GUI send to BE is in the form as shown below:
 ```
 {
 	"method":	"bets_selected",	
@@ -199,4 +199,8 @@ Once the player BE receives the bets chosen by the player, it makes the tx to th
 		"confirmed_bets":[],
 }
 ```
-say if any other player matches the bet player by the player, then the bet info is moved from placed_bets to confirmed_bets.
+say if any other player matches the bet placed by the player, then the bet info is moved from placed_bets to confirmed_bets.
+
+## Using Verus IDs
+The above discussion of the bet uses the data part of the tx to hold the bets and its related info, using verus IDs handling bets will be much efficient. In later steps we develop betting protocols using verus IDs.
+

docs/verus_migration/game_state.md

@@ -1,6 +1,10 @@
 # GAME PLAY
 
-Once the deck shuffling its done, how the shuffled deck gets revealed, how the game moves and betting happens, how the verification of game state and settlement of funds happen is controlled by game play logic. At very high level there exists multiple states and the game progresses as the pariticipating entitites transition from one state to another. All the game state info is updated in the table ID, the game state info is crucial to handle the player disconnections. Any information that is verifiable is stored in the ID's and the information that is confidential to the player is stored in the local DB. The combination of info on local DB along with the info that was stored in the ID's is used for player rejoin and to raise the disputes. 
+Once the deck shuffling is done, revealing of shuffled deck, game movement, betting during the rounds, verification of game state and game info and settling of funds are controlled by the gmae play logic. At very high level there exists multiple states and the game progresses as the pariticipating entitites transition from one state to another. 
+
+All the game state info is updated in the table ID by the dealer, like the way dealer keeps on polling on the player IDs for the player updates, players keeps on polling on table ID for any updates to it. As and when the player reads the table ID and from the game state if it finds out that player needs to take an action then the player updates that corresponding action to the player ID.
+
+This game state info is very crucial to handle the player disconnections. 
 
 ## Different Game States
 

docs/verus_migration/player_joining.md

@@ -14,13 +14,13 @@ Any dealer can host any number of tables, dealer can reuse the same ID repeatedl
 -------------------------------
 There are couple of ways using which players can find the tables registered on the chain which are listed below, the recommended way is using the bet API `list_tables`, i.e by `./bet list_tables` which gives more information about the tables along with its names.
 
-1. Dealer ID contains the information about the tables, using the following commands one can list the available dealers in the system.
-   a. Using the bet API `list_dealers`
+1. Dealer ID contains the information about the tables, using the following commands one can list the available dealers in the system. <br>
+   * Using the bet API `list_dealers`
    ```
 	root@sg777-3 ~/bet/privatebet # ./bet list_dealers
 	[bet.c:bet_start:549] Dealers ::["sg777_d"]
    ```
-   b. By parsing the `dealers.poker.chips10sec@` ID using the bet API(`print_id`). Using verus client API(`getidentity`) also one can see the dealers info but that info is encoded in hex so we recommned using `print_id`.
+   * By parsing the `dealers.poker.chips10sec@` ID using the bet API(`print_id`). Using verus client API(`getidentity`) also one can see the dealers info but that info is encoded in hex so we recommned using `print_id`.
    ```
       	root@sg777-3 ~/bet/privatebet # ./bet print_id dealers dealers
 	[print.c:print_dealers_id:72] ["sg777_d"]
@@ -178,3 +178,9 @@ While updating the players info in `t_table_info` key of the `table_id`, cashier
 }
 ```
 When cashiers update the `t_player_info` for a given `payin_tx` first they check for the duplicacy of the primaryaddress, if the primaryaddress is already been added to the `primaryaddresses` key of the talbe_id, then the cashiers computes the tx hash and compare it with the tx hash appended to the primaryaddress in the `t_player_info` key of the table_id. If tx hash match found, it simply means that the player details for which the cashier has been trying to update to `t_player_info` has already been updated(by another cashier) and in that case the cashier node simply drop its updation process and does nothing and incase if the tx hash is different then the cashier simply deposit back the funds in that tx to the primaryaddress present in the data part of that same tx.
+
+### What players can do on disconnection
+------------------------------------------
+On disconnections players are either allowed to rejoin or simply discontinue.  When player gets disconnected and couldn't join the table in a stipulated time then dealer takes appropriate action based on at what stage the game is in. If player wants to rejoin, player can simply rejoin using the command `./bet rejoin player` and more details about it are documented in [player rejoining](./player_rejoining.md
+).
+

docs/verus_migration/player_rejoining.md

@@ -0,0 +1,39 @@
+## Player Rejoining
+-------------------
+Bet stores the game related confidential information either in local DB or in local files on the node in which bet is running. If not all, most of the game related public information and the players information is stored across the verus IDs(specifically in player/table/dealer/cashier IDs). When the player gets disconnected, bet allows the player to rejoin and if the player fails to rejoin within the agreed time interval(atm, its 20s) then bet allows the dealer to make a decision based on the defined rules in order for the game to move on.
+
+The action taken by the dealer is depends on the [game state](./game_state.md), and at any game state player can rejoin upon the disconnection and the window of time interval to rejoin remains same at all game states. If by any reason player fails to rejoin dealer can take following action:
+  -  if the players disconnection happens before the deck shuffling then dealer raise a request to reverse the payin_tx and removes the corresponding players join info from the corresponding table ID and dealer IDs of the dealer.
+  -  if the players disconnection happens during the deck shuffling then dealer raises a request to reverse the payin_tx(dealer may chose to impose a penanlty of 5% on payin_tx or some fixed amount based on whichever is lower. The reason for penanlty is because as a part of deck shuffling players has already been spent many block fees for deck shuffling) and removes the corresponding players info from the table and dealer IDs and reset the game state to player joining state and will wait for other player to pitch in and fill the position.
+  -  If the players disconnection happens during the game, then the dealer considers players move as <b>fold</b> and proceeds with the game.
+
+Player disconnections at any game state and failure to rejoin will result in quashing previous updates made to the IDs and many cases players and dealers has to undergo the redoing process, due to which there always be going to be some penalty to the player and dealer disconnections and this penalty is mostly in block fees. 
+
+It's also possible that the player can raise a dispute request to claim the payin_tx while being in the game, to prevent any misuse of the dispute handling cashiers will always check if that payin_tx is attached to any game ID in any of the active tables exist atm, if the payin_tx is attached to the active game ID then cashier nodes will wait until the game gets finished to handle the dispute request from the player.
+
+### Data Needed for Rejoin
+---------------------------
+The secret/confidential information that is associated with the player is generated during deck initialization process and which includes
+  -  Player keypair
+  -  Deck privkeys (Each card represents a keypair, so 52 cards privkeys)
+  -  Players shuffling pattern
+
+  The public information that gets available on the player ID and needed for the player rejoin is 
+    -  game_id (This will be fetched from the game_id file, player no need to remember)
+    -  dealer_id (This will be fetched from verus_player.ini config)
+    -  table_id (This will be fetched from verus_player.ini config)
+Along with player ID the above information can also be fetched from the local config file such as `verus_player.ini`(which contains `dealer_id` and `table_id`) and from the file `game_id`(which contains `game_id`).
+
+All this secret information related to the player is stored under the local directory <b>/.game_info/player</b> on the node in which bet is running which is located under <b>bet/privatebet</b>. All these files in game_info are prepended with game_id, for a typical game the files stored locally by the player are:
+  -  game_id (contains the present game id to which the player made payin_tx)
+  -  game_id_str.player_key
+  -  game_id_str.deck_keys
+  -  game_id_str.deck_shuffle_pattern
+
+ The information from the verus IDs the player fetches during the rejoin is
+   -  Players payin_tx
+   -  Players game state
+   -  Shuffled and blinded deck
+   -  Public info of the table and other players info
+
+With the latest design changes as player updates all the game related info to the player ID, we also provide a provision to store the game related and player related confidential information to the player ID in encrypted form. This players data is encrypted using PIN/password that player configured locally and with this during player rejoin, player just needs to remember the locally configured PIN and with which player can rejoin.

docs/verus_migration/verus_migration.md

@@ -20,9 +20,11 @@ So with that in mind its important to notedown the following characteristics of
 
 In bet we are representing the data in JSON format and exchanging it over sockets, unlike socket communications with vdxf IDs we need to be cautious about space like how we storing the data on chain and what data we are storing on the chain. To minimize the storage space on blockchain we encode the data as compact strucutres. At the moment we using structures to encode the data for few APIs and eventually once we get clear idea on contents of each update and what exactly an ID can hold then we can map the ID data to a structure and encode in hex and store.
 
-How we going to create the ID's and managing them is an interesting thing to discuss on. The objective of bet is not just for poker but bet as a platform it has capability to host any card games, betting etc..., so with that in mind we create game specific ID's and any data relate to that game will be grouped under it. Lets say we have chips chain launched on verus, for poker game we register ID as `poker.chips@` and for blackjack we register ID as `blackjack.chips10@` and for betting we register ID as `bet.chips@` and so on.  Under chips the ID `poker.chips` groups all the information under it, and we again create subID's under `poker.chips` to organize the data for example a subID like `dealer.poker.chips` contains the information about the dealers and likewise `cashier.poker.chips` contains the information about cashiers. 
+How we going to create the ID's and managing them is an interesting thing to discuss on. The objective of bet is not just for poker but bet as a platform it has capability to host any card games, betting etc..., so with that in mind we create game specific ID's and any data relate to that game will be grouped under it. Lets say we have chips chain launched on verus, for poker game we register ID as `poker.chips@` and for blackjack we register ID as `blackjack.chips@` and for betting we register ID as `bet.chips@` and so on.  Under chips the ID `poker.chips` groups all the information under it, and we again create subID's under `poker.chips` to organize the data for example a subID like `dealer.poker.chips` contains the information about the dealers and likewise `cashier.poker.chips` contains the information about cashiers. 
 
-In the context of poker the more details about ID creation is mentioned [here](./id_creation_process.md) and about how we create and use keys without any conflicts is mentioned [here](./ids_keys_data.md).
+In the context of poker, find the following details about ID creation and use of keys to organize the data in IDs as below:
+1. [ID creation](./id_creation_process.md)
+2. [Keys and Data](./ids_keys_data.md).
 
 ### How we updating the ID's
 

privatebet/bet.c

@@ -544,13 +544,17 @@ static void bet_start(int argc, char **argv)
 	} else if ((strcmp(argv[1], "print_id") == 0) && (argc > 3)) {
 		print_id_info(argc, argv);
 	} else if ((strcmp(argv[1], "add_dealer") == 0) && (argc == 3)) {
-		add_dealer(argv[2]);
+		retval = add_dealer(argv[2]);
 	} else if (strcmp(argv[1], "list_dealers") == 0) {
-		dlg_info("Dealers ::%s", cJSON_Print(list_dealers()));
+		cJSON *dealers = list_dealers();
+		if (dealers) {
+			dlg_info("Dealers ::%s", cJSON_Print(dealers));
+		}
+
 	} else if (strcmp(argv[1], "list_tables") == 0) {
 		list_tables();
 	} else if ((strcmp(argv[1], "reset_id") == 0) && (argc == 3)) {
-		if (is_id_exists(argv[2], 0))
+		if (id_cansignfor(argv[2], 0, &retval))
 			update_cmm(argv[2], NULL);
 	} else {
 		bet_command_info();

privatebet/bet.h

@@ -249,9 +249,9 @@ struct verus_player_config {
 	int32_t player_id;
 	char dealer_id[16];
 	char table_id[16];
-	char primaryaddress[128];
 	char wallet_addr[64];
 	char txid[128];
+	char verus_pid[128];
 };
 extern struct verus_player_config player_config;
 

privatebet/client.c

@@ -1947,8 +1947,8 @@ void rest_push_cards(struct lws *wsi, cJSON *argjson, int32_t this_playerID)
 void rest_display_cards(cJSON *argjson, int32_t this_playerID)
 {
 	char *suit[NSUITS] = { "clubs", "diamonds", "hearts", "spades" };
-	char *face[NFACES] = { "two",  "three", "four", "five",  "six",  "seven", "eight",
-			       "nine", "ten",   "jack", "queen", "king", "ace" };
+	char *face[NFACES] = { "two",  "three", "four", "five",	 "six",	 "seven", "eight",
+			       "nine", "ten",	"jack", "queen", "king", "ace" };
 
 	char action_str[8][100] = { "", "small_blind", "big_blind", "check", "raise", "call", "allin", "fold" };
 	cJSON *actions = NULL;

privatebet/common.h

@@ -141,6 +141,7 @@ extern char dcv_hosted_gui_url[128];
 int32_t is_table_private;
 char table_password[128];
 char player_name[128];
+char verus_pid[128]; // This is the verus ID owned by the player to which player updates during the game.
 
 int32_t bet_ln_config; 
 extern int64_t sc_start_block;