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

Not everyone donates with a percentage! I'm pretty sure our fastest miner has donated quite a bit in other ways.

Definitely a milestone. Which makes it even more interesting that none of the top 20 miners in the Top Contributors list show any donations to the pool despite having received hundreds of BTC mining on Eligius. Thanks to wizkid for adding the donation stats; now we know who really appreciates this pool.

Could it be time to update the subject? Looks like Eligius has crossed the 3000Th border.

CONGRATULATIONS WIZKID AND LUKE-JR!

The balances.json includes data from when the pool was SMPPS and towards the end of the SMPPS days new miners were getting paid something like 5% PPS because of all of the extra credit built up, which will definitely skew your data.  I chose to trim this data out of the hypothetical miner graph, since CPPSRB does not have this issue.  However, any miner who was around prior to the switch to CPPSRB will almost certainly have a much lower percentage of shares rewarded.

The issue with any luck graphing, as I mentioned before, is that it just doesn't help anything.  It tends to cause more confusion than anything which is why I just avoid doing luck stats.

But since you're throwing luck-based stats around, I should probably clarify why they're useless so that people don't get the wrong idea.

The following are true as of this posting:

• 99.4% of all shares accepted by Eligius-Ra have been accepted in the past 6 months, however Eligius-Ra has been in operation for over two years.
        
  • Eligius itself has been around longer than this even, however Eligius-Ra is the latest revision of the pool and the longest running.
  • Further, 76.9% of all shares accepted have been in the past 60 days.
  • 51.7% of all shares accepted have been in the past 30 days. Thats over half of all accepted shares done just in the past 30 days.
  • As explained a long time ago (somewhere in the old thread) this will skew any luck stats, especially if the recent month has been unlucky (it has)
  
     
• I replaced the SMPPS reward system was replaced with CPPSRB on or about October 2012.
     
  • Due to the way SMPPS works, and a combination of a run of bad luck, miners near the end of this time were earning only a few % PPS, with the rest going to "extra credit".
  • In fairness to those loyal to the pool, the credit earned under SMPPS was passed through to the switch to CPPSRB for all miners who had SMPPS extra credit in case the pool were lucky.
          
    • This credit is added into the 'credit' value in balances.json, and internally kept by the CPPSRB code in the unlikely event that pool gets so lucky that it can start paying this extra credit.
       
  • Veteran miners who are still mining with the same address as they were when SMPPS was active will always show a large difference in the amount of shares rewarded due to this.
  
  
  
• Pool-wide long term accepted shares paid is 98.0%. (Slightly higher when ignoring pre-CPPSRB blocks, however due to the points above is a mostly pointless stat now since the majority of data is recent)
     
  • No this is not just like mining at a pool with a 2% fee
          
    • Expected long term earnings can never be 100% or more due to orphaned blocks. This is for every pool!
    • If a pool has a fee, it is taken after varaince, ie from the 98% rewarded.  So a pool with a 2% fee is thus only rewarding 96.04% PPS, where Eligius, with 0% fee, is awarding 100% of the subsidy of all blocks mined.
            
       
• "Luck" (accepted shares vs expected) for the past 30 days is ~95%, making it a below average month.
     
  • Taking into account the info above (over half of all long term accepted shares being within the past 30 days), it should be obvious how any long term luck stat will be skewed tremendously by just the recent bit of bad luck.
  
  
  
• Even though my stats above are based on accepted vs expected shares, the amount of blocks per day has also increased along with the clumping of data towards the present, making stats based on balances almost equally skewed by short term bad luck.

Lets ignore SMPPS and other factors for a moment and just focus on these two relevant ones: a) short term (30-day) varaince has been a few % below average; b) over half of all data has been collected in the past 30 days (and all data spans over 2 years)
Using just those two points alone is enough to make it very obvious why any luck stats will be skewed towards the unlucky even if supposedly based on the full long term data, which, as I mentioned previously, can be confusing for people to understand.

The only luck/variance stat even close to worth mentioning is the one that shows that variance does tend to and historically has evened out over time and towards the expected value.  Anything else just causes confusion.

There are so many factors to why one miner would have a higher or lower % shares rewarded than another, none of which make any individual miner's contribution less likely to tend towards the expected variance, thus making it a uselessly confusing stat.  Newer miners will *always* have higher variance than older miners, with their shares rewarded bouncing from 0% to 100% for some time until the variance irons out.  Older SMPPS miners will almost always have a lower % shares rewarded because no SMPPS extra credit has been paid since CPPSRB was started.  Was the miner constantly active?  Did they start and stop mining at certain times when the pool was lucky/unlucky?  Many other factors contribute and I wont waste time listing them all.

This is why I don't publish luck data on the stats, because they're just not worthwhile stats overall, and they tend to confuse people more than help them understand anything about the pool.

Remember: Past variance does not have any influance whatsoever on future variance.

-wk

Unless I did a math mistake, it should be, since I took the openly available data at http://eligius.st/~luke-jr/raw/7/ to plot this graph. Considering that the pool has historically rewarded about 97% of all shares submitted, you are a lot under average.


I considered weighting each address per the amount of shares it submitted. I finally chose not to, because I really wanted to show the stats PER PER USER. If the reward system were to favor "big miners" over small ones, for example, then a weighted graph would not reveal it, because the data would be "drowned" by the big miners' data. But small miners, even if they are not significant to the pool, would be frustrated if the pool rewarded them very little, and that matters.

In fact, the top ten users "own" almost half the pool's hashrate, the 5000 other one sharing the rest. So "small" miners make up the most of the pool, and they are important. Many unsatisfied users means bad publicity for the pool, and bad publicity "hurts" the pool.

The same graph weighted per share would be interesting too! But it would not convey the "same" data.


The global variance graphs show the reward of an hypothetical miner over time. This graph is meant to show that things even out over time, and you converge toward "true" PPS over time. My graph is meant to show that this does not happens the same way for all user (depending when they started mining), and to give an idea of the spread of the reward.

Both these graphs are interesting on their own, they both tell different, but not unrelated, information.

I think it should be weighted according to total shares for each miner to be accurate.

Actually, the global variance graphs seems to be just this in another form

its seems today the pool luck is low...

Is that graph accurate? If so, I'm really in the lower 5% with only 92.88% of shares rewarded.

I get the point. Maybe you sould call it something like "Maximum potential reward per submitted share"? Then add another sentence like "(The pool has, historically rewarded [computed average] percent of all submitted shares.)"

Maybe it would be an interesting stat to have a graph that shows the distribution of "amount of users" as a function of "percent PPS"; to show that because of CPPSRB, and the date one has starded mining, the percent PPS is variable per user.

By taking the data from the API, it would be a graph looking like this:
https://www.dropbox.com/s/3d64buquo0hr7ml/Screenshot%202014-02-01%2020.35.39.png


It could also be interesting, then, to have on userstats page a graph of the evolution of your personal percent PPS over the last few weeks. Just like the graph you put on main page, but for you, and not for an hypothetical miner.


Nice! Looking forward to it!

---

It is both, in some way.

The ASICS don't have to do anything in that per se; they juste provide more hashpower. But since the network difficulty automatically adjust to an increase in hashpower, the asics, by themselves dont't do anything.

However recently, Eligius has gotten more and more larger of the whole network's hashpower. THAT does increase the odds of finding blocks rapidly. Still, it's no luck yet, it is just simple math. With 1% of the network's hashpower, we expect to find a block every 16 hours and 40 minutes on average; with 10% of the network, the expected block time is 1 hour and 40 minutes.

The expected block time is just that, an expectation. It might be shorter or longer, and THAT is luck. But the average block time (averaged over a few hundreds of blocks), must be (and is) the same as the expected block time.

Luck of a given block is the "expected block time" over "actual block time" (Well, technically, it is "expected number of shares (difficulty)" over "actual accepted shares", but the ratio should be the same/very similar if the hashrate does not change significally during a block). So a block with 200% luck would have taken 8h20m when Eligius had 1% of the network, and 50 minutes with 10% of the network.

Currently, mining a block in less than 5 min would take a luck of over 1100%, but when we the pool had 1%, it would have taken a luck of 20 000%. Thus, ASIC don't really have much to do to explain the quickest block we had recently. The main reason is that more people entrust Eligius with their hashpower, and we have got a big part of the network now. Thus, even tough very quick blocks (less that 5 mins) are still an unlikely event, they are nontheless much more likely now that they were months ago.

A short answer would be wrong either way here.

Shares are stored in the share log as a percentage of block reward based on the difficulty at the time it is mined. 

When a block is found and shares are paid that percentage is applied against that block's subsidy which is currently 25 BTC.

I just thought of something. Do shelved shares earned before a reward drop get paid at half the rate? (I'm presuming that they do....)

I've got a namecoin web wallet here: http://nmc-wallet.com/index.php

P.S. although looking now... the balance doesn't match what's on the block explorer 

that's interesting. before the RMA, regardless of pool, or ports in this case, my HW errors were at 1.6%. post RMA it has settled at ~.6% after roughly 14 hrs (just got the boards yesterday). Since there's a specified port for KnC, I use it. I only ran it on 3334 for about 30 min max this time. after switching to BFGminer and restarting, before and after using the KnC designated port, the HW errors were just over ~1%. I wasn't on 3334 long enough to see if it would go down as it did after a few hours mining at the designated port. I'll take your word for it though, as I know that even within the same month of a particular batch, the miners varied a great deal in performance. I'm not eager to test your statement given that my miner is doing what I want it to do. lol  As for your other comment, I concur that a flushwork fix is unlikely. I'd be surprised if there is another October batch fw update. I just checked the firmware page, and it seems that the boards i received for RMA had November batch fw, and I loaded October batch fw. works great, but guess I'll have to sort that out presently just in case. Thanks for the explanation of the problem, though. I was wondering what the deal was, since I hadn't noticed anything with my gear. Cheers!

I just have my namecoins sent to my cryptsy NMC address and I do what I need with them from there. 

Someone else mentioned the Namecoin block explorer, but since there is AFAIK no Namecoin web wallet, you'll need to have a namecoind running at some point to spend/exchange/etc. your payouts.   With that up and running, this will work:

your getting higher HW errors on 3334...watch it n see...then goto knc port n i bet it'll be lower But it also doesn't effect all units i don't think...but alotta units...I'm happy on knc port can't wait for knc to fix flushwork thou...doubt it'll ever happen thou

Why do you need a CGminer patch? I also have an oct unit, and actually just received my RMA of controller board and ASIC board. Also oct stock evident by the firmware. In both cases, I simply chose firmware that uses BFGminer (so, if fw 0.98 or earlier, I ran BertMod 3.0 and selected BFGminer - in case of received RMA replacements, which came with stock 0.99-E, I loaded 0.99.2 and selected....again....BFGminer) and can mine on port 3334 and the designated KnC port. CGMiner 3.9.1 which is embedded in fw 0.99.2 also worked fine for the 20 or so min it was running while I was configuring other settings on the miner. My original controller board and ASIC was from the mid-October delivery that could only run 0.95 successfully until 0.98 came around. Still worked just fine. if you're running fw 0.99.1 or 0.99.2, you should be fine so long as your not frying your gear trying to pump the voltage. While I have noticed differences between hashrate to the pool (not this one, but one I've used in the past) between CGMiner and BFGminer using BFL hardware, I've not had the same experience with the KnC. It seems about equal. I use BFGminer simply because I prefer it. What problems are you actually having?

Well, shit. I thought I had been paying you Well, I guess I really am now.

The options have been there for some time, but the code to actually take the donation % was incomplete, until now.

Edit: Just to clarify the reasoning, all of the CPPSRB code is self-auditing with many fail-safes.  It checks and rechecks balances and estimates and such and makes sure that the data matches up using multiple methods to do so.  If something happens that doesn't quite match, or is otherwise abnormal, it shuts down and waits for me to check on it.  Basically, to be secure, the donation acceptance part had to also be coded into all of the auditing portions also, otherwise the "missing" funds from the pool keeping the donations would trigger all kinds of internal alarms and fail-safes.  Plus additional security (such as re-verifying the signed messages more than once to verify that the donation %'s the system is using match what the user actually signed... if there is any question/discrepancy, it just keeps the donation amount at 0%.  Hope this helps explain why this has taken me so long to get it done!

Er? Didn't they already function? I've had it set up for a little while now... or was it not working?