Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB

[wizkid057]

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.

[Biodom]

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 some misunderstanding that quite a few people would like to be clear about: 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'll just do a rundown of how payouts work in general and we'll go from there.

...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.

A pretty good writeup.
So, manual is basically the same payout as automatic, just triggered manually....OK.

I think that maybe you need corporate sponsors to bulk up the pool and reduce variance. No fee should be an attraction, one would think.
Personally, i see my long term wallets down to from slightly below 91% to slightly above 94% shares awarded after many months.
I cannot go back, obviously, but your pool needs some serious luck going forward, I would think.
Peace.
 

[wizkid057]

Figures we find a block while I'm working on coinbaser code updates, hence the weird block with no 1Rcode address.  At least we found a block!

[ineedit]

NMC payouts were all caught up yesterday
....  
The bulk of the remaining offline wallet funds are funds held and currently untouchable in the offline wallets from the withholding attack over a year ago which is awaiting legal confirmation before I can distribute it to affected miners from that time period.
...

Hey Wizkid, it's been awhile since I posted

I had forgotten about that case, how far has it got?

Thanks for the NMC, every little helps, I have converted it all into BTC and sent the bulk to you as tip for all your hard work in running a fair and honest pool along with having the patience to deal with the continual questions.

[Urza]

First of all, thank you for your hard work on the pool and for the detailed explanation.

...
The bulk of the remaining offline wallet funds are funds held and currently untouchable in the offline wallets from the withholding attack over a year ago which is awaiting legal confirmation before I can distribute it to affected miners from that time period.

Aside from that, as of now for some stats: there are roughly 30 BTC worth of funds as a the sum of all active miners who haven't yet reached the default or their set minimum payout.  There is about 1 block worth of payout queue backlog in offline wallet funds.  In total if every miner were to be paid their full balance today it would be a total of about 55 BTC.
...

1) Did I understand you correctly that all 298 BTC currently residing on the address 18d3HV2bm94UyY4a9DrPfoZ17sXuiDQq2B are not meant for payments for shalved shares of common miners ?
2) According to the numbers above, for the pool to be able to pay for all shelved shares the pool needed extra 25 BTC (55 BTC - 30 BTC) or basically one mined block. Is it correct?

[wizkid057]

First of all, thank you for your hard work on the pool and for the detailed explanation.

...
The bulk of the remaining offline wallet funds are funds held and currently untouchable in the offline wallets from the withholding attack over a year ago which is awaiting legal confirmation before I can distribute it to affected miners from that time period.

Aside from that, as of now for some stats: there are roughly 30 BTC worth of funds as a the sum of all active miners who haven't yet reached the default or their set minimum payout.  There is about 1 block worth of payout queue backlog in offline wallet funds.  In total if every miner were to be paid their full balance today it would be a total of about 55 BTC.
...

1) Did I understand you correctly that all 298 BTC currently residing on the address 18d3HV2bm94UyY4a9DrPfoZ17sXuiDQq2B are not meant for payments for shalved shares of common miners ?
2) According to the numbers above, for the pool to be able to pay for all shelved shares the pool needed extra 25 BTC (55 BTC - 30 BTC) or basically one mined block. Is it correct?

1) Shelved shares don't exist as BTC anywhere.  They've never been mined.  Actual funds are not anything to do with shelved shares.  And again, while unrelated to shelved shares, looking at the balance for cold wallet addresses isn't useful, since these wallets are used for other purposes.
2) The payout queue includes estimates for the current round.  So let's say the payout queue is at ~55 BTC.  The pool finds a block, 25 BTC is paid, and then estimates for the next round are included again bringing it back to ~55 BTC (+/- depending on who's still at/above minimum payout).

[wizkid057]

Hey Wizkid, it's been awhile since I posted

I had forgotten about that case, how far has it got?

Thanks for the NMC, every little helps, I have converted it all into BTC and sent the bulk to you as tip for all your hard work in running a fair and honest pool along with having the patience to deal with the continual questions.

I have most of the code in place ready to pay towards the share log the withholder funds, but I'm waiting on the go ahead from Eligius's 1-man legal team...

And thanks for the donation!  Much appreciated.

[Urza]

1) Shelved shares don't exist as BTC anywhere.  They've never been mined.  Actual funds are not anything to do with shelved shares.  And again, while unrelated to shelved shares, looking at the balance for cold wallet addresses isn't useful, since these wallets are used for other purposes.

1) They do exist as an amounts in BTC in the Eligius database (PPS part of CPPSRB).
Shelved shares, the payout queue, the minimum payout only define the order in which those amounts are converted to actual BTC when the pool mines a block.
The reason for my question was to try to estimate how far/close recent shelved shares are from a possible payout. That information is not visible on the user stats page.
If there are some extra funds on the Eligius accounts that are meant for miners then recent shelved shares are probably close and probably would be visible on the user page after the next manual payout.
If there are no such funds then I would guess that recent shelved shares would stay invisible for at least a month.

...
2) According to the numbers above, for the pool to be able to pay for all shelved shares the pool needed extra 25 BTC (55 BTC - 30 BTC) or basically one mined block. Is it correct?

...
2) The payout queue includes estimates for the current round.  So let's say the payout queue is at ~55 BTC.  The pool finds a block, 25 BTC is paid, and then estimates for the next round are included again bringing it back to ~55 BTC (+/- depending on who's still at/above minimum payout).

This was another question with the same purpose.
If the answe to it is 'yes', then it would take 1 or 2 lucky rounds for recent shelved shares to at least appear on the user stats page or even to be converted to actual BTC.
If the answer is 'no', than I don't understands what you included in 30 BTC and 55 BTC.

[wizkid057]

1) Shelved shares don't exist as BTC anywhere.  They've never been mined.  Actual funds are not anything to do with shelved shares.  And again, while unrelated to shelved shares, looking at the balance for cold wallet addresses isn't useful, since these wallets are used for other purposes.

1) They do exist as an amounts in BTC in the Eligius database (PPS part of CPPSRB).
Shelved shares, the payout queue, the minimum payout only define the order in which those amounts are converted to actual BTC when the pool mines a block.
The reason for my question was to try to estimate how far/close recent shelved shares are from a possible payout. That information is not visible on the user stats page.
If there are some extra funds on the Eligius accounts that are meant for miners then recent shelved shares are probably close and probably would be visible on the user page after the next manual payout.
If there are no such funds then I would guess that recent shelved shares would stay invisible for at least a month.

...
2) According to the numbers above, for the pool to be able to pay for all shelved shares the pool needed extra 25 BTC (55 BTC - 30 BTC) or basically one mined block. Is it correct?

...
2) The payout queue includes estimates for the current round.  So let's say the payout queue is at ~55 BTC.  The pool finds a block, 25 BTC is paid, and then estimates for the next round are included again bringing it back to ~55 BTC (+/- depending on who's still at/above minimum payout).

This was another question with the same purpose.
If the answe to it is 'yes', then it would take 1 or 2 lucky rounds for recent shelved shares to at least appear on the user stats page or even to be converted to actual BTC.
If the answer is 'no', than I don't understands what you included in 30 BTC and 55 BTC.

Still not sure what you're getting at.  The payout queue and CPPSRB rewards (which includes handling of shelved shares) have pretty much nothing to do with each other.  The payout queue is just Eligius's way of processing payouts in the coinbase transaction of blocks.  It's not required for shelves shares/CPPSRB/etc.  They're completely independent.

The funds actually in the Eligius offline wallets (NOT necessarily the balance you see for various Eligius related addresses) is generally due to miners AND is reflected in the payout queue.  Again, nothing to do with shelved shares since if the funds exist as real BTC anywhere, then the related shares are not shelved.  If it's in the payout queue (before estimates), it's not shelved.  Again, the two are not related.

Shelved shares also do not exist as amounts in BTC.  They are stored as a portion of the block subsidy for the difficulty at which they were mined.  (Not going to get into the details of that, but feel free to dig back 3 years or so to when the last reward halving happened for that discussion.)

There are never any "extra" funds, either.  If there are funds due miners that Eligius has, then the payout queue has grown by that amount as well.  Any funds Eligius has in its offline wallets due to miners have absolutely nothing whatsoever to do with shelved shares.

This has all been explained many many times.  I'm really unsure where the confusion is.

[Urza]

The funds actually in the Eligius offline wallets (NOT necessarily the balance you see for various Eligius related addresses) is generally due to miners AND is reflected in the payout queue.  Again, nothing to do with shelved shares since if the funds exist as real BTC anywhere, then the related shares are not shelved.  If it's in the payout queue (before estimates), it's not shelved.  Again, the two are not related.

This is a very important statement.
I always thought it was the other way around. That is why I used balances of the Eligius wallets to look up the amount of mined bitcoins.
Now I see where I was wrong.
Sorry for the misleading questions.
I my defence, some description near field "Total" on the payout queue page whould've helped.

Still not sure what you're getting at.  The payout queue and CPPSRB rewards (which includes handling of shelved shares) have pretty much nothing to do with each other.  The payout queue is just Eligius's way of processing payouts in the coinbase transaction of blocks.  It's not required for shelves shares/CPPSRB/etc.  They're completely independent.

I wanted to get an estimate of time required for recent shelved shares to be paid and a chance of such event.
May be you can add a total number of shelved shares for the pool on the statistics page?
From that number and the way it changes I would be able to uderstand the probability of a reward for the last shelved shares.
I realized that I can calculate those numbers from the statistics on the block list page.

[Lucko]

The bulk of the remaining offline wallet funds are funds held and currently untouchable in the offline wallets from the withholding attack over a year ago which is awaiting legal confirmation before I can distribute it to affected miners from that time period.

What can I do if a wallet from that time got compromised?

[wizkid057]

The bulk of the remaining offline wallet funds are funds held and currently untouchable in the offline wallets from the withholding attack over a year ago which is awaiting legal confirmation before I can distribute it to affected miners from that time period.

What can I do if a wallet from that time got compromised?

Nothing can be done on Eligius's side, since moving funds from one address to another is not possible.

Edit:  I suppose you could sign options that donate 100% of the address's earnings, so at least whoever compromised your wallet wouldn't get the funds.

[kano]

The bulk of the remaining offline wallet funds are funds held and currently untouchable in the offline wallets from the withholding attack over a year ago which is awaiting legal confirmation before I can distribute it to affected miners from that time period.

What can I do if a wallet from that time got compromised?

Nothing can be done on Eligius's side, since moving funds from one address to another is not possible.

Edit:  I suppose you could sign options that donate 100% of the address's earnings, so at least whoever compromised your wallet wouldn't get the funds.

Then why couldn't he do that to move it to another address?

[wizkid057]

The bulk of the remaining offline wallet funds are funds held and currently untouchable in the offline wallets from the withholding attack over a year ago which is awaiting legal confirmation before I can distribute it to affected miners from that time period.

What can I do if a wallet from that time got compromised?

Nothing can be done on Eligius's side, since moving funds from one address to another is not possible.

Edit:  I suppose you could sign options that donate 100% of the address's earnings, so at least whoever compromised your wallet wouldn't get the funds.

Then why couldn't he do that to move it to another address?

Because not even I can move funds between addresses in the reward system.  Not without removing all sanity checks and rewriting half of the code to get around the basic security premises behind the share log.  The only thing in place to even remotely do so are the donation functions, which require a signed message to work.  I can't set anyone's donation amounts for them, either, since I can't sign with their address.

I suppose a 100% donation settings, then afterwards a signed message to me with a new address to manually send the funds (along with a brief summary in the signed message so I can keep it for records) would work in this case, since the funds would be rewarded all at once at a known time.  This wouldn't work under normal circumstances, however, since donations only happen when shares are rewarded in the reward system and not when a payout is actually made.  Most people contact me after they already have a balance on an address they want to move funds from, which is literally impossible..... not to mention most of these people contacting me are just trying to scam anyway.

[adaseb]

I tried mining on my S2 a few days ago but after a few minutes, I was submitting many rejection shares. Like 1 approved share and 100 rejection shares and my speed was like 100-200Gh/s on a S2. Anyone know why? Only on this pool.

[wizkid057]

I tried mining on my S2 a few days ago but after a few minutes, I was submitting many rejection shares. Like 1 approved share and 100 rejection shares and my speed was like 100-200Gh/s on a S2. Anyone know why? Only on this pool.

Have any logs?  Global reject rate on Eligius is near 0% lately, so I'd be inclined to lean towards an issue on your end.

[adaseb]

I tried mining on my S2 a few days ago but after a few minutes, I was submitting many rejection shares. Like 1 approved share and 100 rejection shares and my speed was like 100-200Gh/s on a S2. Anyone know why? Only on this pool.

Have any logs?  Global reject rate on Eligius is near 0% lately, so I'd be inclined to lean towards an issue on your end.

It kept saying rejected due to high-hash something like that.

It worked for a few minutes and then later on, my speed on your pool slowed down and then it started giving me these errors. I can take a photo if you would like.

[wizkid057]

I tried mining on my S2 a few days ago but after a few minutes, I was submitting many rejection shares. Like 1 approved share and 100 rejection shares and my speed was like 100-200Gh/s on a S2. Anyone know why? Only on this pool.

Have any logs?  Global reject rate on Eligius is near 0% lately, so I'd be inclined to lean towards an issue on your end.

It kept saying rejected due to high-hash something like that.

It worked for a few minutes and then later on, my speed on your pool slowed down and then it started giving me these errors. I can take a photo if you would like.

"high-hash" means your miner was submitting shares that were below the difficulty at which it should have been submitting shares, which is a client/miner side issue.

[kano]

I think you need to switch the keccak mining back to sha256 ...

[wijawara]

Omg 3 days with no blocks. What is this? Shelved share heaven?