Bitcoin Forum
November 11, 2024, 06:16:21 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: That score-based reward formula is catastrophically contraproductive  (Read 729 times)
frevd (OP)
Newbie
*
Offline Offline

Activity: 11
Merit: 0


View Profile
June 26, 2011, 03:49:10 AM
 #1

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
TiagoTiago
Hero Member
*****
Offline Offline

Activity: 616
Merit: 500


Firstbits.com/1fg4i :)


View Profile
June 26, 2011, 03:59:12 AM
 #2

Are you talking to which pool operator?

(I dont always get new reply notifications, pls send a pm when you think it has happened)

Wanna gimme some BTC/BCH for any or no reason? 1FmvtS66LFh6ycrXDwKRQTexGJw4UWiqDX Smiley

The more you believe in Bitcoin, and the more you show you do to other people, the faster the real value will soar!

Do you like mmmBananas?!
frevd (OP)
Newbie
*
Offline Offline

Activity: 11
Merit: 0


View Profile
June 26, 2011, 04:04:10 AM
 #3

Oh sorry, I came from api.bitcoin.cz via a link, didn't see that this was a different site.
Thanks.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!