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

[organofcorti]

I really wish there was a reasonable and cost effective way to verify this theory ...

Try this:  For any given user account (or provably grouped user accounts), define
normalised shares = each share divided by the the difficulty at which the share was submitted
X = sum(normalised shares)

Then for one block being solved by this user account , the lower tail CDF is:
CDF =  1 - exp(-X).

Notes:
1. If the user account has never solved a block, then the CDF will be greater than this when or if eventually they do submit a block.
2. If the user account has solved more than one block, you can use Wolfram Alpha to calculate the CDF - there's a howto in point 6 of this post: http://organofcorti.blogspot.com/2015/07/faq-bitcoin-mining-and-luck-statistic.html

Edit: Potentially related... does anyone have any block find stats for hash power that has gone through NiceHash? 

They're a proxy, so I think you have to believe their stats. You could use the method I gave above to check the CDF though.

[1713465679]

1713465679

[1713465679]

1713465679

[1713465679]

1713465679

[1713465679]

1713465679

[wizkid057]

I really wish there was a reasonable and cost effective way to verify this theory ...

Try this:  For any given user account (or provably grouped user accounts), define
normalised shares = each share divided by the the difficulty at which the share was submitted
X = sum(normalised shares)

Then for one block being solved by this user account , the lower tail CDF is:
CDF =  1 - exp(-X).

Notes:
1. If the user account has never solved a block, then the CDF will be greater than this when or if eventually they do submit a block.
2. If the user account has solved more than one block, you can use Wolfram Alpha to calculate the CDF - there's a howto in point 6 of this post: http://organofcorti.blogspot.com/2015/07/faq-bitcoin-mining-and-luck-statistic.html

Edit: Potentially related... does anyone have any block find stats for hash power that has gone through NiceHash?

They're a proxy, so I think you have to believe their stats. You could use the method I gave above to check the CDF though.

Ah yeah, I check CDF and similar metrics against the user stats data all the time.  Part of the issue is that many many accounts have never submitted a block, and most are too slow to reasonably have been expected to.  The ones that have submitted blocks, and have mined long enough to have useful stats, are all within reasonable ranges.  I've correlated using usernames, along with non-public metrics... but the network difficulty is just too high to get meaningful results.  The fact is that most miners just won't ever submit a block anyway.  With 85% of users being under 4Th/sec, that's something like 3 years on average for those users to find a block, at the top of the 85% list.  There's also nothing preventing anyone from changing usernames and whatnot.  So for 85% of the users (~50% of the pool) most of them will never solve a block.  Only a small portion of them will.

I've checked accounts that haven't solved blocks by checking the difficulty achieved by all of their shares in the database against their expected amounts, and haven't found anything too crazy in that data either... although that data is much shorter-term than it used to be since I don't have unlimited space for storing full share submissions indefinitely.  Hardware that screwed up randomly or purposely wouldn't necessarily be noticeable this way anyway.

Edit: I actually misread your post and just realized you're talking about per-share stats.  I've done something similar, but I don't think this would help with potential winning share withholding detection for users who haven't submitted any blocks... or am I missing something there?

[notabeliever]

So the pool isn't finding blocks because hardware is old or average miner can only produce 4th? The #1 pool is using all S7's?
I was on slushes in the summer and they had dry spells for weeks on end until now so see what they did. I like this pool except for the long delay of payouts.


Decided to take my miner outside raise up to the block watchers and paraded around chanting "the block shall drop in the pool of Eligius"

[notabeliever]

YEEEEEEEEEEEEEEEEEEEES

block 385316 dropped in the pool

[btcmner]

In order to be worse it would have to vary more than mine

Please explain why.

[organofcorti]

Ah yeah, I check CDF and similar metrics against the user stats data all the time.  Part of the issue is that many many accounts have never submitted a block, and most are too slow to reasonably have been expected to.  The ones that have submitted blocks, and have mined long enough to have useful stats, are all within reasonable ranges.  I've correlated using usernames, along with non-public metrics... but the network difficulty is just too high to get meaningful results.  The fact is that most miners just won't ever submit a block anyway.  With 85% of users being under 4Th/sec, that's something like 3 years on average for those users to find a block, at the top of the 85% list.  There's also nothing preventing anyone from changing usernames and whatnot.  So for 85% of the users (~50% of the pool) most of them will never solve a block.  Only a small portion of them will.

I've checked accounts that haven't solved blocks by checking the difficulty achieved by all of their shares in the database against their expected amounts, and haven't found anything too crazy in that data either... although that data is much shorter-term than it used to be since I don't have unlimited space for storing full share submissions indefinitely.  Hardware that screwed up randomly or purposely wouldn't necessarily be noticeable this way anyway.

Edit: I actually misread your post and just realized you're talking about per-share stats.  I've done something similar, but I don't think this would help with potential winning share withholding detection for users who haven't submitted any blocks... or am I missing something there?

The user account share CDF will just tell you if their shares per block statistic is within a confidence interval which you could specify. The downside is, as you say, very few user accounts will have submitted enough shares to have solved one block anyway which makes this process less useful. For a big proxy pool or any user account that has submitted many shares, it could be useful. This might already be what you do?

[Biodom]

is eligius statistics working or not?
pool took three two blocks in the last 1-2 hr, but since last confirmed block the number "as of last block" did not change, instead reflecting a situation of three two blocks ago.

also a block three two blocks ago was confirmed already.
what's up with no automatic payout if it is confirmed >120 times already?

thanks

[btcmner]

is eligius statistics working or not?

Probably catching up, I would not worry about that.

[wizkid057]

Yeah, sorry folks.  I broke the stats and reward system with some changes I've made to optimize things that I haven't worked all of the bugs out of yet.  Causes the reward system to failsafe as a precaution, and then the stats fall behind.  As always the pool is working fine, and the stats are catching up.  I'll get a manual payout out as soon as these blocks confirm.

I'll also work on getting the kinks worked out this weekend.

[notabeliever]

Did everyone notice the bitcoin difficulty is 10% more at 72.72G

[sloopy]

Full disclosure:
I read all of the pool posts pretty regularly.
I read wizkids comment regarding something up with the mining scene. Hardware, something smells bad, etc
Tonight I read eleuthria's comments.

I'm not going to get into too many specifics regarding my mining situation. It is nothing much at all.
 However I will be straight up with a few folks if any questions are posed via PM.

Anyway, I had an S3+ and an S7 both submit block finds to kano.is in 23 days and I will say what I have is a small amount of hash. I am not mentioning kano.is to discuss the differences between the pools in any fashion.

I am stating this to say these are both old and new miners, supposedly I should be running exactly what the manufacturer is in their own halls, at least for a time period long ago and now.

MY question would be...
 are you saying one of those miners should have previously or current day receive a higher number of block finds / payouts?
Or the S7 will score more than the S3+ hash for hash?
Is this observation made from both of your experience with your own pools and observing across the entire network?

I have had the S3+ mining since approximately January 15 of this year.
The S7 is a batch 1 which came in a week or so after the Holiday in China
Which we are still waiting on some word regarding compensation.

I think I hear you saying the S7's solve more blocks than an S3 at the same cost for both?

I am asking you to spell it out for me heh.

Edit for clarity of my opinion:
I think it was luck given opportunity.
But I am very interested in the discussion.

[notabeliever]

I don't know enough about it however my S1 + S5 could not find a block in 23 days. My S5 was struggling these past days and I think the difficulty is too much for them. Now is Antpool made up of S7's and that is the reason for them finding blocks or is pool hash. Luck means something and I just don't think its the kind of luck when playing the lottery. I think its having advantages in miners over others. The same when I try to mine 250kh against 200mh, why would I bother to try.

Look I compare the S7 like when I went from an S1 to the S5. I basically shutdown the S1 because the hashrate wasn't worth it.

This pool is great and as some of us get the S7's the miningfield will get neutral.

[Biodom]

Q: why the automatic system dilly-dallies and does not automatically pay up once the 120 confirmations are there?
I have some wallets that paid up and some that didn't regardless of the amount of btc there (way above the cutoff).

[wizkid057]

Q: why the automatic system dilly-dallies and does not automatically pay up once the 120 confirmations are there?
I have some wallets that paid up and some that didn't regardless of the amount of btc there (way above the cutoff).

Not 100% sure what you're asking.  The pool side doesn't much care about confirmations.  As long as confirmations on a block (or more specifically, a payout transaction) remain > 0, the pool is happy.

Once a coinbase/generation payout reaches 120 confirmations (100 in some clients) then it is spendable.  Eligius has no control over this and it's up to the user's wallet to make it spendable at the right time.

As for blocks that are failsafe blocks (like the few that happened recently due to my recently trigger-happy failsafe mechanism) those pay one or more of the pool's offline wallets so that those funds can be used to manually pay towards the payout queue later (once those coinbase transactions are spendable and the failsafe condition is corrected).  In the meantime, and even before those blocks reach 120 confirmations, the payout queue simply grows by a block and continues to do payouts on a balance-age basis, with the oldest balances paid first.  Once you get a payout, you end up on the bottom of the list.  If you've been working towards a payout for weeks and cross the threshold you get inserted into the payout queue at the appropriate spot for your balance age at that time.

The payout queue is very dynamic and is constantly changing based on current estimates pool-wide.  At any moment a miner who's been working towards a payout for weeks could jump to the front of the queue with their weeks old balance.  Also a miner in the queue due to their estimated balance being over the threshold could pop out of the queue if they stop mining during an unlucky round and their estimated balance drops below the payout threshold.  Lots of things going on there.

If you reach the minimum payout, and your last payout was more recent than others in front of you in the queue, then your payout can be delayed by several blocks.  Meanwhile the payout you're preparing for grows beyond the minimum payout and is accurate for when you do either reach the top block in the queue or a manual payout is done.  (Manual payouts do not include estimates for the next block, obviously.)

Since Eligius has a minimum payout amount it's possible (and likely) that not all miners will have reached it every time the pool finds a block.  In aggregate, these amounts accumulate in the offline/cold wallets and slowly grow the payout queue over time, even if there are no fail safe blocks.  A manual payout is done to catch up the queue when it reaches a reasonable amount.  Even though the miners not reaching the minimum payout aren't being directly paid by each block, they can still enter the queue and be paid by the next block after they reach the minimum payout.

The minimum payout is important because it would be impossible and silly to pay every miner tiny dust payouts every block.  Even if having a coinbase transaction that allowed 2000+ outputs were feasible (it isn't, much over a couple hundred breaks most mining hardware) it would be crazy since miners would have to pay huge fees to spend their earnings when they combined hundreds of dust input coins in a transaction.

Hope this helps.

Edit: Honestly, it's not as complicated as it seems...

[Biodom]

Q: why the automatic system dilly-dallies and does not automatically pay up once the 120 confirmations are there?
I have some wallets that paid up and some that didn't regardless of the amount of btc there (way above the cutoff).

Not 100% sure what you're asking.  The pool side doesn't much care about confirmations.  As long as confirmations on a block (or more specifically, a payout transaction) remain > 0, the pool is happy.

Once a coinbase/generation payout reaches 120 confirmations (100 in some clients) then it is spendable.  Eligius has no control over this and it's up to the user's wallet to make it spendable at the right time.

As for blocks that are failsafe blocks (like the few that happened recently due to my recently trigger-happy failsafe mechanism) those pay one or more of the pool's offline wallets so that those funds can be used to manually pay towards the payout queue later (once those coinbase transactions are spendable and the failsafe condition is corrected).  In the meantime, and even before those blocks reach 120 confirmations, the payout queue simply grows by a block and continues to do payouts on a balance-age basis, with the oldest balances paid first.  Once you get a payout, you end up on the bottom of the list.  If you've been working towards a payout for weeks and cross the threshold you get inserted into the payout queue at the appropriate spot for your balance age at that time.

The payout queue is very dynamic and is constantly changing based on current estimates pool-wide.  At any moment a miner who's been working towards a payout for weeks could jump to the front of the queue with their weeks old balance.  Also a miner in the queue due to their estimated balance being over the threshold could pop out of the queue if they stop mining during an unlucky round and their estimated balance drops below the payout threshold.  Lots of things going on there.

If you reach the minimum payout, and your last payout was more recent than others in front of you in the queue, then your payout can be delayed by several blocks.  Meanwhile the payout you're preparing for grows beyond the minimum payout and is accurate for when you do either reach the top block in the queue or a manual payout is done.  (Manual payouts do not include estimates for the next block, obviously.)

Since Eligius has a minimum payout amount it's possible (and likely) that not all miners will have reached it every time the pool finds a block.  In aggregate, these amounts accumulate in the offline/cold wallets and slowly grow the payout queue over time, even if there are no fail safe blocks.  A manual payout is done to catch up the queue when it reaches a reasonable amount.  Even though the miners not reaching the minimum payout aren't being directly paid by each block, they can still enter the queue and be paid by the next block after they reach the minimum payout.

The minimum payout is important because it would be impossible and silly to pay every miner tiny dust payouts every block.  Even if having a coinbase transaction that allowed 2000+ outputs were feasible (it isn't, much over a couple hundred breaks most mining hardware) it would be crazy since miners would have to pay huge fees to spend their earnings when they combined hundreds of dust input coins in a transaction.

Hope this helps.

Edit: Honestly, it's not as complicated as it seems...

no kidding  

In the quote ^^^I was referring to your post on Nov 25:

Yeah, sorry folks.  I broke the stats and reward system with some changes I've made to optimize things that I haven't worked all of the bugs out of yet.  Causes the reward system to failsafe as a precaution, and then the stats fall behind.  As always the pool is working fine, and the stats are catching up.  I'll get a manual payout out as soon as these blocks confirm.

I'll also work on getting the kinks worked out this weekend.

I guess you decided not to do a manual payout after all.

[wizkid057]

Got held up with holiday related items.  I'll get it done before the end of the day tomorrow (well, today technically)

[enthus]

this is great pool, good support and admin active. thank you elgius

[wizkid057]

147.71950016 BTC in manual payments applied to balances from tx 4f927cc23c8fa83426960fcec283ec10a81174429513e89e6be8b0b8afa86a5b

[mavericklm]

i got nothing... is there another manual payment?

older user of this pool: All time total payout: 16.11127818 BTC

[wizkid057]

i got nothing... is there another manual payment?

older user of this pool: All time total payout: 16.11127818 BTC

Was your "as of last block" amount over the minimum payout?

If so you got a payout. If not then open a ticket so I can investigate, but almost certainly a simple explanation, or crappy wallet software/service.