Quote from: Biodom on January 19, 2016, 01:40:34 AM

I don't think that I edited out anything important- just initials for the second wallet address mentioned by the other poster.

1. regarding point#1: it would help to have more luck, but it is unpredictable, as we all know. Close to 100% luck luck during some substantial time frame like several months would definitely be helpful to increase hash rate.
2. regarding payments-maybe I misunderstood the other poster who said that there was a lot of btc in a side wallet(s), which then was partially transferred to a Change wallet. If so, I assumed that it was btc mined prior to the time of manual payout and if it was so, i don't think that current minimal payout level of a particular wallet is relevant and being or not being in the queue might not be relevant as well.

I think that here lies is some misunderstanding that quite a few people would like to be clear: specifically, why you have to be in the queue or above minimal level to get manual payout if manual payout is for some prior work, assuming that it is so.

thanks

Yeah, if I could increase luck, for sure that would be done... but, in that case I probably would head to Las Vegas instead of running a non-profit mining pool. lol.

I'm not 100% sure what you're getting at with #2 and your last sentence, so, I'll just do a rundown of how payouts work in general and we'll go from there.

Miners submit shares. These shares build the share log. New shares are stacked on top of old shares. Shares are stored in the share log in the order they are received, tagged to the miner that submitted it along with the value of the share. They remain there until they're rewarded. They never expire.

The pool finds a block. The entire block subsidy (currently 25 BTC) and the block's transaction fees are added to the pool's fund counter internally. The pool uses 100% of its internal funds counter to reward as many shares as possible starting at the top of the share log (most recently submitted share prior to the block being found). Generally there are at most a few satoshi left in this internal counter, which rolls over to the next round since the sum of the shares paid don't always add up to exactly 25 BTC+transaction fees. We can't really pay partial shares because that just doesn't make sense and would make the code overly complicated. Much simpler to rollover 8 satoshi to be added to the next round's funds, which evens out anyway because the previous round probably rolled over a few satoshi as well. But anyway, this increases the "As of last block" balances of all accounts, which is the amount actually earned by the miner and is due to the miner (assuming none of the related blocks are subsequently orphaned/stale).

Then, the block's coinbase transaction is inspected and validated to match a previously generated Eligius coinbase transaction, which would include payout estimates for the current round. Any addresses paid by the transaction have that amount deducted from their balance at the pool, since it would be paid out. Generally addresses paid like this will be brought to 0 balance. Occasionally latency will cause the estimated payout in the coinbase to be a hair lower than it should, and that balance it left in the "As of last block" balance. It's still earned and never lost so it will be paid out, of course.

Sometimes the block's coinbase transaction doesn't directly pay miners and the coinbase transaction instead pays one or more of Eligius's offline wallets. Usually this happens with quick successive network blocks where the pool wasn't able to verify everything and produce a payout list prior to giving miners new work. So, miners still have their balance that Eligius owes them ("As of last block"), but it isn't immediately deducted like in the above case since no payout was made to miners yet. The miners that should have been paid remain in the payout queue. This is why the payout queue get's longer, generally. It's always best to get miners on the latest work to reduce stales rather than wait until the pool has verified the payout list and full block template. The difference is generally just a couple of seconds, but seconds count.

When I process a manual payout, the payout queue is read from the top down and addresses are paid until the offline wallet runs out of funds (there are multiple) or the payout queue is paid in full. Again, estimates for the current round which are included in the payout queue on the web site are NOT included in manual payouts since this would mean the pool would be paying for a block that hasn't been found yet. The "As of last block" balance is used, not the sum after current round estimates.

The payout queue is based on the time of the address's last payment from Eligius. The longer it has been since the last payment, the higher the position in the payout queue. If a miner's estimate puts them above the minimum payout after they've been mining for a long time to reach their payout threshold, they can enter the queue pretty high in priority. On the other hand, miners who tend to mine enough to reach the minimum payout will generally end up near the bottom of the queue since their balances are always young.

The payout queue is independent of the shares being rewarded. 100% of every satoshi from every block mined by Eligius is rewarded to our miners. All of it. 25 BTC+transaction fees. Unfortunately, paying 2000+ addresses in every block would be silly, so we don't do that. We have a minimum payout. So a local pool balance builds up ("As of Last Block") until the minimum is reached, at which point the miner enters the payout queue in a position based on their last payout (or first share time if they've never had a payout). Then they are paid when the pool finds a block that pays the top of the payout queue, or they are paid when I do a manual payout that pays towards the payout queue.

But, not matter how you look at it, 100% of the funds mined by Eligius end up paid to miners. Obvious exception being donations.

Hope this helps. I'm not sure how much clearer I can make it.