My apologies to wizkid. I wouldn't have responded at all if this user's posts weren't pointed out in my thread. This kind of derailment is why I had my thread converted to self-moderated, but I also won't let somebody hide in another thread spouting provably false information.
No worries. I hate people (even people without a clue) spreading false information period. Feel free to jump in whenever needed.
Sorry for the lack of attention to the thread. Been keeping busy with the pool, work, and other RL projects.
I'll try to address some things I see since I last posted.
That's awesome! I didn't realise Eligius did this! The coinbase message is a message encoded in the coinbase. I know that doesn't help much, but rather than OT this whole page, just check this link:
What I understand from your quote is that Eligius is considering allowing miners to add to the coinbase message - fantastic! You can get your little bit of bitcoin immortality right here.
Eligius has always let people suggest text for the next block's coinbase text. (Not many have recently)
Merged mining + 'Eligius' tag + extranonces take up a good chunk of the coinbase text, but, there is some room left.
I have been working on several different methods where the coinbase text for the next block can be chosen by miners in a more automated way, possibly some type of queue. There has been some demand for it, so hopefully have some more details on that soon, since it should be fun. On a side note, Eligius miners using GBT have been able to append the coinbase text using bfgminer's coinbase-sig option for any blocks they find.
The payout queue has nothing to do with luck directly. Basically, when a block is found, miners are rewards for that block under CPPSRB. At the same time, the system tries
very hard every block to include payouts to miners who have reached the minimum payout as per the payout queue. If every block were able to do this, the queue would almost never deviate from 1 block deep. However, occasionally different fail-safes will prevent the system from including automatic payouts in the block directly and instead sends the block reward to the pool's offline wallet. Miners are still rewarded for this block under CPPSRB as normal, but since no miners were actually paid yet the queue grows by about a block (depending on how many miners get pushed over the minimum payout by this block's rewards).
When the queue gets long I ask CPPSRB for a sendmany transaction to submit using the cold/offline wallet funds to pay off the payout queue, catching everything up instantly and getting us back to only 1 block or less of people in queue. I do many checks on this data before submitting it to make sure that everything appears sane, so, I try to wait a bit between manual payouts because they are a little time consuming.
I didn't notice it in the FAQ, but does the Maximum Reward line in the graph represent the 100% PPS earnings? Should the pool go on a run of faster blocks and clear its payout queue, will the unpaid + everpaid line reach the max reward line?
Yes... And no.
Each time you submit a share, the pool records it in the share log, at it's straight PPS value. When a block is found, 25 BTC worth of shares (starting from the most recent) are paid.
If the pool is unlucky, and it took more shares than average to find the block, some of the shares submitted for that block cannot be paid (since the pool does not have the money to cover them). The pool "remembers" those shares; they are shelved.
If the pool gets lucky, and it took less shares than average to find a block, pool will have some BTC left after paying every share submitted for that block. It will therefore pay whats left to the most recent shelved shares.
However, paying everybody like that in every block would be a problem: First, small miners would only get micropayments in every block; and it would be dust that accumulates in their wallet (and increases their fees when they use the coins). Second, some clients have a bug in which that cannot support a too big amount of outputs per transaction. (Doing payments like that in Eligius would cause more than 5000 output per transaction)
Therefore, Eligius implements a sort of tradeoff. Instead of directly paying the shares when they are found; it internally computes which shares are to be paid, and which shares are not (yet), without actually sending the money to the miner. Instead, it holds onto them until a given amount is accumulated (chosen by the miner), at which time the pool will send the coins.
Therefore, it means that even if the pool were to empty it's payout queue, it does not mean that everybody's shares ever submitted have been paid. It does mean, however, that nobody has accumulated enough rewarded-but-unpaid shares to be paid. (In those cases, the pool sends the block reward to an offline wallet, from which the miners will be paid when the payout queue gets long enough.)
Thus, about the graphs and stats:
The everpaid line is amount of BTC the pool has ever sent to you.
The unpaid+everpaid line is that amount, plus the value of all the shares the pool has rewarded to you, but has not set the actual money yet, because you have not met your threshold. (the unpaid amount is the amount marked in the "unpaid balance" in the table above the graph)
The maximum reward line is the total value of all the shares you ever submitted to the pool, including those it does not have the funds to pay yet.
If the pool gets lucky, "unpaid+everpaid" will get closer to "maximum reward", and may even touch it. However, they would not "meet" at the same time for all users, depending when that user joined. Most recent shelved shares being paid first, the pool would have to be lucky a lot longer to pay all the way back to 2012, when the pool began, than to pay all the shares of somebody who started one month ago.
However, nobody's payment will ever go above "maximum reward": once all your shares have been paid, all the extra coins go to paying other who have to yet been fully paid. Finally even if the pool were to clear it's whole backlog, then it would hold onto the extra coins until less lucky times.
^ This is a pretty good explanation. Thanks. (Yes, I dropped the end part about initial pool-wide bad luck since it could be confusing/misleading without the proceeding post)
Side note, looking into doing that self moderated thread now.