I ran a year-long test comparing NastyPoP to standard p2pool payouts.  I had 2 identical S3s mining - one configured to get standard p2pool payouts, the other configured for NastyPoP.  At the end of the year, the data shows that the S3 getting standard p2pool payments made 96.99% of expectations.  The S3 on NastyPoP made 91.04%.

I calculated expected earnings by figuring out how much 440GH/s should have made using the following formula:
All data is available in an Excel spreadsheet for examination here: https://www.dropbox.com/s/vv7r7ejq2pquynl/pop_vs_p2p.xlsx?dl=0

Thanks!  You've had some great luck over on BCMonster .

No, it's not going to produce more or faster blocks.  At this point classic is nothing more than core with an increase to 2MB block size limit - and that won't even come into play until such time that the majority of blocks mined are by Bitcoin classic nodes.

LOL!

Wow!  Congrats again, guys!  Absolutely amazing luck.  That's a far nicer looking block than your first... 0.25BTC in fees this time

LOL... yeah, it's nice to see under 100% again .  Would be even nicer to see that reset from a block find!  I threw a couple PH at it over the weekend, but struck out.

That he was... he had a whole thread about solo mining with his S3: https://bitcointalk.org/index.php?topic=1132914.0

As far as I remember, it was a guy with an S3.

To address the concerns in your first reply... it's a tough bit of analysis.  In an ideal world, if the pool at 40PH was experiencing the same luck as the pool at 33PH, then it would be apparent that 7PH was withholding blocks.  If all 7PH belonged to a single miner, you found your culprit.  Unfortunately, the problem remains: you must wait some period of time before you are relatively certain that the miner isn't just unlucky.  I'm not sure how many, if any, pool operators have written this kind of analytics into their code.  It's a pretty simple bit of analysis: count shares submitted by miner vs number of block solutions.  If number of shares is some percentage over expectations, flag as potential block withholding.

That doesn't solve it, but merely alerts the pool operator something might be amiss.  Now the pool operator has to take action.  What action the operator takes is really the basis of your second reply.  Personally, I don't agree with Slush's decision to allow the miner to continue on his pool without any kind of repercussions.  "Sorry, my bad!" just doesn't cut it.  Intentional or not, if a miner is going to write his own custom firmware, that miner should be testing it on a simulated environment, not forcing the public to assume the risks of untested code.  I'm glad for the miners on the pool that the problem was found and addressed; however, if I were a miner on the pool, I'd be seriously considering going elsewhere if neither the offending miner, nor the pool operator were held accountable in some fashion.

I'd argue that the only thing similar between ckpool and ant is that both are attempting to solve blocks and that one incarnation of ant is PPLNS.

Everything else is indeed fundamentally different... and you even go on in the rest of your excellent explanation describing the huge fundamental differences between the two pools

As was explained earlier, you cannot simply ban somebody immediately.  You don't really know someone is performing a block withholding attack until a large number of hashes have been produced without a block solution.  Plenty of pools regularly suffer through long rounds - it is the nature of mining.  It goes to follow, then, that an individual miner also suffers the same.  Kano suggested 10 blocks earlier.  At that point, the chances of it being "luck" are exceptionally minimal.  Unfortunately, 250BTC have been lost to the miner.

You actually just mentioned another reason why I'm not using Bitmain's hardware any longer: their software.  They have used their own absolutely crap fork of cgminer for ages.  Rather than utilize the mainline cgminer code, they continue off on their own.  Their pool software is crap and they have the highest rate of empty blocks of any pool.  They SPV mine, and along with f2pool have previously caused a fork in the chain.  They claimed they supported p2pool, yet the work they did was utter crap and did not in any way support the concept at all.

By the way, I've got a couple PH rented.  Let's nail that block!

EDIT: of course as soon as I post that, my order is outbid

It's all random since mining is really nothing more than brute force attempts to find a hash that satisfies the requirements.  The poisson distribution model describes the expectations, which is what we all use to calculate things like expected earnings, time to find a block, etc.  However, as you saw with this pool's first block, and my pool's blocks, the models may indeed describe expected values, but the reality can be quite different.

The more hash rate a pool has, the closer to the model things become.  This is variance.

Believe me, I'd love to see our smaller pools become successful and attract more miners.  The more we have, the less the big, bad-for-bitcoin pools have.  I'm enormously happy for kano's pool.  The growth he's had is remarkable.  It would be very nice to see similar growth on my pool, here on this pool, on mmpool, bitminter, etc.

It's statistics.  You are correct that you'd see more per block here than on other pools.  However, you would see far fewer blocks here than on the other pools.  A pool with 20 PH/s expects to find 2.7916 blocks a day at current difficulty.  A pool with 1 PH/s expects to find a block every 7.1633 days. (these numbers are rounded off)

Let's say you have 100 TH/s of gear.  On pool 1, you represent 0.5% of the pool's total hashing power.  All things being equal, you would expect to make 0.125BTC per block.  On pool 2, you represent 10% of the pool's total hashing power.  You would expect to make 2.5BTC per block.

Pool 1 would solve 20 blocks for every 1 block solved by pool 2.

So, what does that mean?  Yup... you make more per block on the smaller pool; however, by the time you've found that block you've made the same amount of coin on the larger pool.

Now, when you factor in the nature of mining (luck swings, difficulty changes, orphans, etc) you are far more likely to be impacted on the smaller pool than on the larger one.

I've owned S1s, S2s, S3s, and S5s from Bitmain.  I opted out of the S7 for a couple of reasons.  As Phil mentioned in his post, Bitmain's customer service is basically non-existent.  When the S3 was initially announced, it was 504 GH/s.  That was reduced to 478 GH/s before the first orders were taken.  When I ordered my batch 1 units, Bitmain was still claiming 478 GH/s.  That quickly changed to what they launched with: 441 GH/s.  Those of us who were in batch 1 actually did receive some compensation (either a coupon or a straight up BTC payment).  Back then, Bitmain was active on the forum, responded to emails and wanted to do right by their customers.

That's long since passed.  Bitmain's hardware reliability has continued to go downhill.  Like the S3, the S7 was announced at a higher hash rate than the units actually produce.  As Phil and others have seen, some units don't even make the expected hashing rate.

There are a couple of other reasons I chose the Avalon6.  First is the power requirement.  I can run the Avalon on my EVGA 1300 G2 PSUs.  Not having to purchase another PSU was a big plus for me.  The second reason is the noise.  I run my miners in my home.  The S7 is atrociously loud.  I had a noisy miner before (the SP10) and won't do it again.

Congrats on your first block guys!

Holy lucky block, too.... 13 billion shares.  Nicely done.

Oh man... that's a good deal... I can't have any more at home, though.

Got my 2 new Avalon6 all setup and running!  Easy as plugging them in, logging into the UI and setting up the pool.  They are a little louder than I was expecting based on videos I'd watched (but that's because they are the rev2 miners).  Nowhere near as loud as my S5, thankfully.  Running about 3.5TH each on EVGA 1300 G2 PSUs at 12.0V and default settings.

I'll probably goof around and see if I can get them running on a Pi using standard cgminer - without the openwrt-based firmware that came with the Pi/SDCard combo I got with the miners.  I've got the spare Pi and it's got cgminer 4.9.2 compiled and built with the avalon4 support enabled (it currently runs my 5 U2 sticks).  All told I've got about 9TH now in house and all of it's pointed to my pool.

I've also got a bunch of S3s to sell now, too

LOL... like these two currently running? :

#976496   0.0060   9999.00   3309   7474.9785
#976507   0.0060   6000.00   2157   3026.4700

Yeah... I was just curious.  I might play around with it, since I've got a spare Pi that I use to run cgminer for my U2 sticks.  While the web GUI is nice, I really don't care about it.  I can get all the info I need just looking at the output from cgminer

OK... forgive me if this has been previously asked and answered...

What benefit (besides the web front end) does using the pre-built SD Card image offer?  I mean, if I've already got a Pi with cgminer that has enabled avalon support, couldn't I just plug the avalon into it and fire it up?