Topic: Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB - page 46. (Read 1061485 times)

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



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.

If older hardware in particular were having some issue with not submitting shares where it mattered, then this would fit pretty well with the pools listed all of which would have a disproportionate amount of older hardware.  Eligius's average hash rate per connection is ridiculously low... like, under 25Gh/connection in total at some times.  Average hash rate per active user is about 4 Th/sec, with only the top ~15% of active users being >= 4 Th/sec.

I really wish there was a reasonable and cost effective way to verify this theory, or some better way to mitigate the issue.

Edit: Potentially related... does anyone have any block find stats for hash power that has gone through NiceHash?  Doubt it, but, I was going through some stats and noticed that none of the hash power ever pointed at Eligius from there has every found a block as far back as I have user agent->share correlation data.  Something like 6x blocks worth of shares submitted from there without blocks, just with the data I have on a per share basis.  Correlating those with those users, those users haven't found blocks either further back than my user agent data goes, so probably more than 6x.  I may ban nicehash connections if this tally rises much more.

I'm honestly not sure why anyone would buy hashes at a premium to point at Eligius anyway.

You may be right - there seems to have been a drop in profitability for a few pools, although the "pool profitability" measure also includes orphaned blocks.

Not so much - That's just the last one week's summary as a comparison to the 52 weeks summary - sorry I forgot to mention that. If you go to the link and look at the 52 week summary, it's still wrong, since I was quoting Slush's results, I think.

To answer your question more directly, no, I haven't been drinking, just trying to post between seeing patients which is not such a good idea.

To be clear, below I've posted the updated tables from the current post, weekly first and 52 weeks second.




Yes I did. Thanks for checking, and FTY I just posted this week's results - click on one of the tables below.

Those numbers really reinforce my thinking that there is something in older hardware that is not submitting winning shares (either by intentional design, or due to cutting corners and screwing something up when it comes to really high difficulty).  Especially when the only large pool that is right where you'd expect them to be regarding luck is the one that makes their own hardware and runs a massive private farm.

Umm no.  In order to be worse it would have to vary more than mine which has varied a little but not a lot (sometimes miners stop hashing, sometimes the internet goes down).  Ergo, a number worse than 94% indicates someone who was mining less consistently than me.  

Regardless OrganOfCorti already made the same point using the maths.

you quoted Slush's numbers here...I see correct numbers in the table, thanks for commenting and doing a great job with your blog.

ooc? What you been drinking man?

It's 90.3% and a CDF of 99.9% ... reading from your image ... which is like ... woah who screwed up the luck there ...

Well, this is a bit self-contradictory...

Hey Biodom,

I apologise if my post was misleading, but the post refers to the "luck" of the pool, not individual miners - they are affected by their own variance (in finding shares) and the reward method variance.

Including luck and orphans, over the past year the pool as a whole has a profitability of 97.4%, and the CDF is 80.2% which is not so unusual.

Well you are right about one thing, bad luck is at the root of the explanation.  However that 91.4-91.6% luck absolutely does not describe a miner that has had a stable hashrate and been mining continuously for a year on this pool.  You would have a number closer to 94-95% at least.  I can't tell you what it would be exactly because my hashrate has varied a bit here and there but my long term numbers on two addresses are both over 94%.

Reward system failsafed last night when my new code didn't respond to a query from it quickly enough.  Sorry about that.  As always, not really an issue... just lags stats until it catches up, which shouldn't be too long.

The 128 and 256 second numbers come from the reward system, assuming it's running.  If it failsafes then those numbers get frozen in time.

The other numbers the stats build from scratch using the webserver copy of the raw share submission database, so generally those will be working if the stats are up and running.

128 and 256 sec averages are 0 for me, but 22.5 minutes is showing correctly.

estimated change +0.0. not a lot, just 400 GH, but still...

My post actually said that I was puzzled, and then you explained (in more pertinent part of your post) how estimated change is handled.
I stayed, but now actively considering leaving for the following reasons:
 
That long term account which you referred to has luck of 91.4-91.5% right now, which should have almost never happened according to this:
http://organofcorti.blogspot.com/2015/07/faq-bitcoin-mining-and-luck-statistic.html

there is only 1/1000 chance of luck being 91% in 1000 blocks solved by a particular pool.

The account that you referred to, again, has 91.4-91.6% long term luck (more than a year).
In the last 12 mo your pool solved 1644 blocks or close, if I am not mistaken, so probability is even smaller than 1/1000 (organofcorti has no numbers for >1000 blocks).
basically, it can only happen less than one time (one year period)  in 1000 years.
I know that you have some ad hoc timing explanation, but ad hoc does not explain statistics.
While NOT suggesting or implying (directly or indirectly) that something is intentional, it looks likely to me that some calculations are not done right at the back end.
I don't know what it is-stale shares handling, manual payout cutoffs, higher than 100% luck calculation, etc, but in the end it is just not right, and by not right I mean that these numbers are very unlikely to happen.

Wizkid I would just ignore those people, they don't and probably never will contribute anything to the bitcoin community and besides there is a faq that they are too lazy to read.  Personally I really like the web front end, its easy to use and the idea of no accounts just using your address is pure genius.  Its really cool how everything is out in the open, retains the bitcoin feel where you can lookup any address and see the history.  Keep it up 

Estimated change is the estimated change in your balance if the pool found a block at that moment. It is not earned and not locked in until the pool finds a confirmed valid block. The "As of last block" portion is locked in, assuming the last block remains valid.

The estimated change is basically the value of all shares that you have in the top 25 BTC of the pool-wide share log at that moment. This goes down if you lose hash rate, or if the pool gains hash rate (since your relative contributions per block would be less, not that you actually make less overall). It goes up if you add hash rate, or if the pool hash rate goes down.

The last block was pretty long, so likely no change in balance in your time window (not sure on timezone for your times).  All blocks are listed on the stats page with UTC timestamps.

Again, apologies for taking some offense. I get so many people who have been so misinformed about mining that look to blame the pool or me for their ignorance, directly or indirectly.  Your post read a lot like, "my balance changed for no reason, the pool must be cheating me."

I mean, I literally had someone threaten to sue me for the 100 bitcoins that I supposedly owed them for their week of mining at like 50 Gh a couple of months ago.  Seriously.  He was basing his numbers on some outdated profit calculator that some eBay seller linked to that used a difficulty from pre-ASIC days, probably to screw someone that didn't know better (successfully). It was sad, funny, and highly annoying.  And stuff like this happens daily, although not necessarily to that extreme.  At least a dozen times per day I get people wondering why they can't find their stats, or that their stats are wrong, only to find out that they're CPU mining or misunderstood how much they should be earning, or whatever.

I agree that the stats and website need a full overhaul to make some things more clear and better looking overall. But they are correct as they are.  The balance numbers come directly from the reward system and are just parsed and displayed.

First of all, I have absolutely NO accusations, just trying to understand how the calculations work, seriously, so please don't take offense.
That said, I don't think that you explained this, at least not at the level I assume most will understand.

What exactly is an estimated change? Estimated change, i suppose, by common definition of the word is something that happened ALREADY, right?
So, how estimated change can go down EVEN if one miner is disconnected? How did future affected the past, unless this word means something else in this context.

Still, manual payout at point B (today) was exactly the same amount that miner earned at point A ( EDIT: actually at 12:43 this morning, sorry), which is OK If no blocks were solved between 12:43am and 3:27 pm. I don't know this for a fact, but assume that it is correct-you can confirm it if you want.
Then the question is: if remaining miner was hashing during this 14 hour period AND estimated change went backwards (less at point B then at point A), then WHERE did its hashing go?

Bottom line- I have the same miner pointed to your pool; I would have left if i thought that something is purposefully wrong.
I just looked for some clarification, no need to be upset, really.

Manual payouts have nothing to do with the estimated change.  They just reduce the "As of Last Block" portion to zero, generally, since the stats kind of treat manual payouts as basically a block with no block reward to keep things simple.

There is one address in the last manual payout that received 0.1844xxxx, which was 1CaEjfFqpqzhzZp9EyEu3tzE34LoByDN2s and it's hashrate dropped in half in the past 24 hours, which would fully explain a halving of the estimated payout.  This is easily determined with publicly available data (the manual payout transaction in the block chain and the info provided in your post), so I'm not exposing any private info here using any non-public info.

Edit: Here is a screenshot of that address's hashrate and balance graph.  I see no inconsistency.



You'll see the estimated reward line started falling off as soon as the hash rate fell off, until the percentage of shares in the top 25 BTC of the share log being added was evened out with the new hash rate as the old shares were buried.  Then a block was found that brought a bunch of those back to the top and since the hash rate was still halved, it taped off and leveled at about half the original amount, again since the hash rate halved.

The green line jumped to indicate the manual payout.  Notice the other lines were unchanged.  The purple line *just* jumped near the end because we just found a block.  Looking again in the next few minutes and the blue line will be jumped above the purple line again based on the shares at the top of the share log, likely all based on the current hash rate since the last round was unlucky and wouldn't un-bury the only shares from a day ago yet.  Edit:  I stand corrected, it wasn't a terribly unlucky round, so it is once again including some old shares (at the original double hash rate) in the current estimate.  Nice.

To answer your last question about why it doesn't always pay at whatever payout level, that's the payout queue growing slightly and delaying payouts a couple of blocks, giving the balance a little longer to grow before it pays out, hence the manual payouts to catch things up.

Most recently some back end tweaks have the coinbaser delayed a little longer than originally when there is a network block change, and causes a few additional blocks to not help the payout queue automatically.  This was a safety item to make sure that my new code never double pays.  I'd rather have to do an extra manual payout than double pay miners that, historically, won't just give those funds back.  Yes, this happened in the past and I paid miners the difference out of pocket since it was my coding error that caused it (all documented somewhere in this giant thread).  So, caution is definitely key.  I have things mostly back to speed since I've testing my new code to death over the past week or so.

(Edited with additional info)

Final edit:  Apologies for going into this so much, and basically calling out a miner, but I greatly dislike it when people try to make it look like the pool or myself is doing something wrong when that's clearly not the case.  In this instance saying that the estimated change went down for no reason without mentioning the very important fact that the hash rate had indeed cut in half.

yes, this would be nice, otherwise statistics that web site shows is very puzzling, especially with manual payouts.

Example:

20:31 pm (yesterday) as of last block 0.1844.... btc. eligius pool at 8866th
estimated change +0.0249.... btc
3:27 pm (today) manual payout exactly the same the number that was at 20:31 pm yesterday eligius pool at 8785th
estimated change +0.0134.... btc

Question-where is all the hashing that miner did since 20:31 pm went? Estimated change is lower (by 50%) than 17 hours ago.
Also, why it hangs out and does not automatically payout at around 0.04-0.05 BTC?

EDIT: the fact that site statistics presentation was puzzling to me does not mean that I thought that something is inappropriate.

Alright... I busted out the heavy duty duct tape this time and got the web server back online  The bubble gum I used last time dried up and broke

Jokes aside, web server should be up and fine for now.  Admittedly I've just done a temporary fix and will work on a long term solution to the issue probably this weekend.  Keep in mind, as always, that the web server and the pool servers are completely independent of each other and the pool servers rarely have any issues since I've worked pretty hard to get the pool back end stable.  The web server side of things has no access to any of the pool servers and just receives copies of the relevant data to its database pushed from the pool servers.   It runs on slightly outdated hardware that I'm working on updating as well to improve performance.

Thanks everyone!

On a side note, I'm looking to do a site and stats visual overhaul to get Eligius's web-side of things to be as good as the the back end.  Unfortunately front end stuff is not my area of expertise.  If anyone is skilled in that area and is willing to volunteer some time to help with the overhaul please let me know.  Specifically I'm wanting to just make the site a real site without relying on obscure URLs for stats and such.  eligius.st/stats or stats.eligius.st with a visual look that fits the rest of the site kind of like Gateway69 was volunteering with the drupal powered current front page.  He's been MIA for a while.  I'm not fond of drupal or most preexisting content management systems.  Basically I just need some help with a template that I can integrate the stats into along with the main web page data easily and I can take it from there to whip up one nice integrated site.  I think it's LONG overdue. Thanks in advance!