pool.burst-team.us payout confusion
-
@iKnow0 the math is done and now thanks to you is correct the only data we don't know exactly for the math be 100% correct is how many accounts submitted a valid deadline to the pool in that block, this data could be collected if the printscreen @BurstMiner1 was from the complete page because on top of the pool page says the amount of miners that submitted a deadline... If we had this value we would replace it for the 333 and add 1 burst to it like i did in my math ;D
-
@gpedro for block 331119 there were 244 nonces submitted by a total of 151 miners.
-
@haitch ok so @BurstMiner1 has the following shares in the block 331119 (retrieve from the screenshot):
current block: 0.0017% or 0.000017
historical shares: 0.222% or 0.00222-
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.002220 = 1.79869728 (your share of the total historical share percentage)
-
1215.336 * 0.000017 = 0.020660712 (your share of the total current share percentage)
so @BurstMiner1 should have got 0.02066071 + 1.79869728 = 1.81935799 burst (or 181935799 NQT)...
He received 1.93734903 so probably some difference in some round decimal somewhere ;DIf i do the same math but only for 151 fees collected before doing the distribution (meaning the pool fee didn't collected extra fee like the remaining payments) the result is 1.82025619 so it collects something even less than 1 burst per address with a submitted nonce in that block ... I'm out of clues right now xD
-
-
@gpedro not all miners will be paid as most goes to deferred payment until the payment threshold is reached.
if you do it with 20 miners getting payed, which seems reasonable its not too far off. See Below.

-
@gpedro I believe the historic value at time of calculation is used, so it may have changed between screenshot of block won, and calc done three blocks later.
-
@iKnow0 As far as i understand it has to be 1 burst from each account that submitted a deadline because all this payments are done to the threshold...
I find more likely that his shares have changed between his screenshot and the end of the block in the case of the current block or his historical shares changed between the screenshot and the calculations 3 blocks later...
-
@gpedro unfortunately the call to "current_shares.count" which determines how much fee is going to be deducted, is in a library file I don't have the source for - so no idea what it's returning.
-
@haitch what language is the whole thing? C/C++?
-
This post is deleted!
-
-
@gpedro I honestly not sure - didn't look like C++ to me, but I'll defer to those that know the languages.
-
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 ;DSo 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
-
-
This post is deleted!


