4. It might be a good idea or not, but I think it will be a bit more transparent if next to the accepted shares, rejected shares you included a new count named Dev Shares then we could keep track and see if it really is a 2% what you are taking away.
4. Yes, I am open to this idea. But simply counting the number of shares will just confuse people due to potentially different difficulties of shares. Once I figured out a right way to implement this, I will do it.
The Developer Shares may not be exactly 2% of the Accepted Shares as the miner share difficulty is likely different from the developer share difficulty but still, it should be close.
For a more accurate number, that accounts for the difference in difficulties, a few calculations can be introduced.
1) "avgDevD", the average difficulty of the developers shares.
2) "avgMnrD", the average difficulty of the miners shares.
3) "%diffD", the percent difference in difficulty or more precisely, the % increase or decrease in the average difficulty of the miners shares compared to the average difficulty of the developers shares. It looks like this:
%diffD = (avgDevD / avgMnrD) / avgMnrD * 100The "avgDevD" and "avgMnrD" values can just go into the bminer.log to lessen console clutter but with the "%diffD" value added to the console, the following equations can be used for verification and should increase confidence in the code.
Dev Shares = 0.02 * Accepted Shares * (1 + %diffD / 100)Miner Shares = Accepted Shares - Dev SharesMaybe there's an easier method but this one is not terribly complicated.