feat: add rules note for algorithm to integrate outside hashrate.

NOTES_ALGORITHM.md

@@ -27,7 +27,13 @@ Every ten minutes, the algorithm will decide how next 10 minutes will be distrib
 
 ## Manage with outside HashRate
 
-Gupaxx could be connected to a xmrig proxy to control HR of every miners outside local machine.
+If miners outside the Gupaxx instance are mining on P2pool for the same address, Gupaxx will send too much on P2pool because it doesn't take extra HR outside his control into account.
+To solve this issue, it will look at the sidechain estimated HR (eHR) from status command of p2pool. It is an estimation based on passed discovered shares, their difficulty, the number of blocks between them etc...
+This eHR will be retrieved at the same interval as the algorithm.
+This estimated external HR(eHR) minus the local HR sent to p2pool will be removed from the mHR.
+
+If miners outside the Gupaxx instance are mining on XvB for the same address, Gupaxx will maybe send too much (more than enough for the round) or too less (could have been in better round) on XvB.
+To solve this second issue, it will remove from the required HR to get to rounds the average HR sent to XvB (retrieved by XvB API) minus what he is sending of its own.
 
 ## Examples
 
@@ -50,16 +56,32 @@ The first round type (Donor round) need 1kH/s and second round type (VIP Donor)
 5kH/s is enough for the Donor Round but not enough for the VIP Donor.  
 So 1kH/s is given to XvB node so that the miner participate in the Donor round.  
 
-**Hero mode**: 4 minutes are given to p2pool and 5 for XvB.
+**Hero mode**: 4 minutes are given to p2pool and 6 for XvB.
+
+### Example 3: the hardworker
+
+Miner has 5kH/s on Gupaxx
+He also have one remote miner that mines 2kH/s on P2pool and another one 8kH/s on XvB
+**Default mode**: 6 minutes are given to p2pool and 4 for XvB.
+Because to have at still one share per window, gupaxx need to complete the already existent HR on p2pool with 4 minutes (2kH/s). But after that, it still have 6 minutes spared (3kH/s) when only 4 minutes are needed to gain the better round of vip donor (10kH/s). So it will send only the necessary 4 minutes to XvB and give the 2 minutes not needed to p2pool.
+
+**Hero mode**: 4 minutes are given to p2pool and 6 for XvB. 
+
 
 ## Technical Implementation
 
 ### Knowing if a share is in PW
 
-P2pool node (PN) local API show only found shares and not current. It is not also showing the current height block of p2pool.  
+P2pool node (PN) local API show only found shares and not current.
-Gupaxx process will check every minute when a new share is found, and how much time passed since the last. While verifying if mining on mini or main chain, it will calculate if the last share found is still valid.  
+Gupaxx process will check frequently the output of the p2pool command "status" without impacting the console output of the P2pool tab to get the current shares.
-This way Gupaxx will know if a share is currently in the window.  
+
-This method is only an estimation, a better way would be to know at which block the share is found and which block height the network is currently at. But P2pool API doesn't offer these information by API but by command.  
+### know oHR on P2pool
+
+Gupaxx watch for sidechain HR for his address on the output of status command of p2pool in a way that do not disturb the output of console in the UI.
+
+### know oHR on XvB
+
+Gupaxx receive these data from XvB API.
 
 ### Knowing the HR generated by Gupaxx