Quote from: un_ordinateur on July 13, 2014, 07:33:46 AM

Quote from: baddw on July 12, 2014, 05:58:35 AM

Quote from: PlanetCrypto on July 12, 2014, 05:39:53 AM

Quote from: baddw on July 11, 2014, 04:11:55 AM

Quote from: PlanetCrypto on July 11, 2014, 03:40:53 AM

So I think I got this payout queue threshold thingy wrong.

Would like some recommendations given the following:
Hashing @ 2.2 - 2.3 TH/s
Would like to be paid every 2 - 3 days.

Thanks in advance from a noob.

See link in my sig for payout threshold explanation. TLDR version: the higher you set your threshold, the sooner you will likely be paid once you hit it. If your threshold is low (1 day's worth or less) then you could easily see a 2-3 day variance in payouts.

Thanks, sorry to be so redundant. Interesting reading. Maybe make that explanation a sticky? Then it could a RTMFP, lol.

Well, there's a reason I put it in my sig: I got tired of having the same thing explained several times a week. You're far from the only one.

I just read your explanation: Very well done!

I just have a suggestion for a small improvement: You should make it clear that "shelved shares" represent an amount of work the pool recognises you have done but have not yet paid, for it has never found enough block to pay for them. So "shelved shares" are, by themselves, worthless; they do not reprensent an amount of coins the pool "owes" to you. They will, however, be payed in a "best effort" basis, as soon the pool finds coins to cover them, if it ever does.

On the other hand, your account balance reprensents coins the pool "owes" to you; that it has found enough money to pay for. The whole "account balance" thing, and payout treshold, is not essential to the CPPSRB system; in fact, miners could always be payed for their rewarded shares immediately, every time a block is found. This would, however, result in HUGE generation transaction with thousands of outputs, most of which are ridiculously small amounts. Although valid by the bitcoin rules, this would be undesirable because a) Certain clients have a bug in their handling of transactions with too many outputs, and b) The miners wallets would be made of hundreds of small amount outputs; when they will be spent, all these outputs will need to be merged in a single big transaction that will cost a lot in transaction fees to the miner.

So Eligius' operators have found preferable to delay the payout of rewarded shares until a reasonable amount has been accumulated by a miner. However, while the payout is delayed; the pool HAS that money on hand, and so, if it were to ever close down, it should have enough money in it's offline wallet to cover every miners' balances. (And none of their shelved share) One can check the balance of the offline wallet address (18d3HV2bm94UyY4a9DrPfoZ17sXuiDQq2B) and quickly check that it has enough money to pay for the entire payout queue (http://eligius.st/~wizkid057/newstats/payoutqueue.php/), the remainder being the balance of all the miners who have not yet crossed their treshold.

Thanks un_ordinateur and wizkid for the information! I will update the explanation post with this information when I get the chance. Of course, most of the explanation is already cribbed from stuff that you two (and many others) have posted; my goal is simply to gather it all in the same place for easy reference. "Owes" vs. "best effort" is an important distinction, and the fact that the payout queue/threshold is not essential to the system (which I had never considered before, although it makes perfect sense) will hopefully help illuminate and elucidate the pool's mechanisms for many people.