Protocol changes documentation update

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,34 @@
+## 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 depends on the game state, and at any state player has the choice to rejoin with in the 20s window of time, if by any reason player fails to rejoin the following will be the dealers action towards it:
+  -  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 table and dealer IDs.
+  -  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.
+
+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 information that is associated with the player is generated during the deck initialization process and which is
+  -  Player keypair
+  -  Deck privkeys (Each card represents a keypair, so 52 cards privkeys)
+  -  Players shuffling pattern
+
+  The public information that needs to stored/provided locally 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)
+
+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 player info

docs/verus_migration/verus_migration.md

@@ -22,7 +22,9 @@ In bet we are representing the data in JSON format and exchanging it over socket
 
 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. 
 
-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