So yesterday after this last posts me and haitch kept crunching some numbers through PM in order to see if by the math we could figure out how the pool do the payout exactly, and as i am going to show you, we found something interesting, still not sure because we didn't made the math to any other payment to check if we got it right, but since i don't have the time this weekend, maybe someone can do some more math to confirm if we are right ;D
So this is was what we got after some more querys to the db:
His real current block shares:
mysql> select * from Shares where blockID = 331119 and accountID = 18412210141346961862;
+---------+----------------------+------------------------+----------+--------------------------+------------------------+
| blockID | accountID | share_fraction | deadline | deadline_string | miner |
+---------+----------------------+------------------------+----------+--------------------------+------------------------+
| 331119 | 18412210141346961862 | 0.000017342427070079117 | 539821 | 6 days, 5 hours, 57 mins | burstcoin-jminer-0.4.7 |
+---------+----------------------+------------------------+----------+--------------------------+------------------------+
1 row in set (0.00 sec)
mysql>
so this was his real current shares for that block : 0.000017342427070079117
His real historical shares:
So here appear the funny part... If we do the sum of the last 50 current shares and then extract the percentage from there, that will led us with a difference of +-5% for what he actually received, so we check what would be his historical shares 4 blocks to the future and that didn't make sense because his historical shares kept decreasing so the difference would be even bigger if the calc was made 4 blocks in the future, so we check what would be his historical shares 4 blocks in the past and that number (0.23633178800952656%) make a lot of sense due to the pool wait 4 blocks to confirm if the block was not forged in a fork, so using the historical shares of 4 blocks behind in time it would be a pretty clever manouver because will only use verified numbers by its own code...
So now the math (xP) :
current block: 0.000017342427070079117
historical shares: 0.0023633178800952656
2146+76 = 2222 (total payment received by pool for the block 331119)
2222 *.98 = 2177.56 (less the pool fee of 2%)
2177.56 - 152 = 2025.56 (1 burst for the fee of pool transaction + 151 burst for fees of transfers for miners)
2025.56 * .6 = 1215.336 (total pool current share percentage)
2025.56 * .4 = 810.224 (total pool historic percentage)
810.224* 0.0023633178800952656 = 1.91481687 (your share of the total historical share percentage)
1215.336 * 0.000017342427070079117 = 0.02107688 (your share of the total current share percentage)
so @BurstMiner1 should have got 1.91481687 + 0.02107688 = 1.93589375 burst (or 193589375 NQT)...
He received 1.93734903 so the difference will be 0,00145528 burst and probably this difference exists due to some round up i am not making exactly like in the code ;D
So to Sum up what i am saying with all this numbers is that it uses the current block share of the current block (obviously) and that for the historical shares it uses the historical shares of 4 blocks behind in time to make sure it doesn't use compromised results that can happen during a fork
So now we need to confirm this by making the same math for another block (with the same miner or a different one) and this math should also be made to bigger miners (this miner has only 10Tb mining, wich is good but would be cool to compare it to larger miners because i am pretty sure that if you are a larger miner you are not so affected by the fees we now know we all have been paying in ninja clones)... It would be cool to compare it with other pools too to see if the results are close enough to the reality... There is nothing more i think we can discover by the math that will lead us closer to the meaning of the code xD
Well this was my version of reverse engineering the pool code without read a single line in there, if someone that can look at the code can easily confirm if this is true or not but this is based on a bunch of querys to the db, some assumptions, a lot of math and a lot of hits with my head in the wall... LOL
Hope it helps ;D
