Oh sorry, I came from api.bitcoin.cz via a link, didn't see that this was a different site.
Thanks.
Topic: That score-based reward formula is catastrophically contraproductive (Read 732 times)
June 25, 2011, 10:59:12 PM
Are you talking to which pool operator?
June 25, 2011, 10:49:10 PM
So, I'm new here, and immediately dissatisfied, sorry to bug ya with that.
I read about these changes to the reward calculation.
I don't want to spoil the party, but I think this will not do any good to the pool over the long term, so I better mention my problem.
What I recognize is that the calculation achieves the absolute opposite of what it is supposed to do (those logarithmic charts won't show it however).
What's the purpose of inventing a regressive calculation to prevent users from disconnecting if I can earn more with one share submitted relatively close to the end of the block than with more than 10 shares that were submitted during the block. Every scriptkiddy is able to come up with a scraper that automates connecting only in the very last %% of the block. I think that is not what you had in mind, since somebody has to do the work at the beginning, at that one should damn well be paid.
My very first contribution earned me 0.00017928 BTC for only 2 out of 1950683 total shares, which took my poor GPU about 10mins and took place some minutes before the block was finished.
My second contribution now rans for 2 hours and produced 8 of shares so far (somehow the last share took significantly longer than the ones before, which is not honered by the formula either). My total earnings on that one are estimated at 0.00000002 BTC now, for much more factual work. How is that making any sense? If I am not lucky to submit the 9th share I will get nothing for that heat I produced.
IF you really wanted to prevent users from partial disconnecting from blocks, you MUST come up with a totally different formula, one which honours steady distribution of shares over time, and NOT only the most recent one(s) at the end. This current calculation is completely devastating and I won't continue with your Pool at the moment.
Your original share-based system was more honest. To achieve what you are looking for, you have to measure the total distribution of shares over time, not the distance to the last one, which is greatly oversimplifying the matter and blatantly wrong, since calculation of a share is not evenly distributed over time. You must check whether shares were submitted over the total time range.
Alternatively, come up with a registration for the next block, so nobody can join the party later on, and check whether share submission per client was at about the same time than submission of other participants.
my 2ct
I read about these changes to the reward calculation.
I don't want to spoil the party, but I think this will not do any good to the pool over the long term, so I better mention my problem.
What I recognize is that the calculation achieves the absolute opposite of what it is supposed to do (those logarithmic charts won't show it however).
What's the purpose of inventing a regressive calculation to prevent users from disconnecting if I can earn more with one share submitted relatively close to the end of the block than with more than 10 shares that were submitted during the block. Every scriptkiddy is able to come up with a scraper that automates connecting only in the very last %% of the block. I think that is not what you had in mind, since somebody has to do the work at the beginning, at that one should damn well be paid.
My very first contribution earned me 0.00017928 BTC for only 2 out of 1950683 total shares, which took my poor GPU about 10mins and took place some minutes before the block was finished.
My second contribution now rans for 2 hours and produced 8 of shares so far (somehow the last share took significantly longer than the ones before, which is not honered by the formula either). My total earnings on that one are estimated at 0.00000002 BTC now, for much more factual work. How is that making any sense? If I am not lucky to submit the 9th share I will get nothing for that heat I produced.
IF you really wanted to prevent users from partial disconnecting from blocks, you MUST come up with a totally different formula, one which honours steady distribution of shares over time, and NOT only the most recent one(s) at the end. This current calculation is completely devastating and I won't continue with your Pool at the moment.
Your original share-based system was more honest. To achieve what you are looking for, you have to measure the total distribution of shares over time, not the distance to the last one, which is greatly oversimplifying the matter and blatantly wrong, since calculation of a share is not evenly distributed over time. You must check whether shares were submitted over the total time range.
Alternatively, come up with a registration for the next block, so nobody can join the party later on, and check whether share submission per client was at about the same time than submission of other participants.
my 2ct
Jump to: