KanoPool since 2014 🐈 - PPLNS and Solo 0.5% fee - Worldwide - 2437 blocks

[o_solo_miner]

  WOW the next Block!

The return of the Luck

[kano]

Yeah that at least fixed the last 2 weeks (10 blocks) luck

[wizkid057]

Well the last one was keeping BTC for miners who make a mistake connecting, instead of not allowing them to mine or failing over to their backup pools, coz some of them did it on purpose ...

I had a miner do that yesterday.
They didn't create an account for their username, there was no username even slightly similar, it wasn't an address miner of course, and they kept connecting to the pool and being rejected.
I actually think it was trying to be annoying based on the username ...
In the end (having done all the checks possible about if it was someone/an IP I've seen before) I simply permanent banned their IP address from mining.
End of story.
If I had enabled them mining, I would have had to hope they would one day contact me and then I could give them access to the account ... ... ... or I block them (mining) up front and if they wanted to mine they'd contact me pretty quickly.

Well, this stems way back to before I ran the pool.  eloipool never verified anything about usernames or passwords (it has modules to do so now, but didn't before), it just validated work and sent it to a database for parsing by whatever reward code you wanted.

Today, I leave this alone because it's been a long term well documented method of just donating to the pool.  Connect to Eligius with whatever username you want (people come up with some fun ones too, with today's favorite: "wizkid_keep_up_the_good_work") and the work gets donated (under the normal reward system rules as if I had simply mined myself).  So, I have no reason to change it.  Since Eligius has no accounts, per se, it makes things simpler.

Rarely I'll have someone contact me about it if they messed up and were mining with an invalid username.  If they mined a non-negligible amount I do some verification to make sure they're not trying to scam me and then manually pay them.  If they only messed up for a short period of time with a dust-like trivial amount of reward.... well, suck it up buttercup, you should have read the whole "use a valid bitcoin address as a username" thing.

Eligius's back end is designed in a way where even I can't move rewards from one miner to another, which is a great internal security feature.  So if a miner mines with an invalid/donation username, there literally is no way I can move those shares to another username... short of a complete rewrite of the reward system code that undermines the current secure methods.  

Anyway, we'll never agree on this point, but given that it's a documented behavior that many use for donating (some actually use it with *gminer's load balancing to donate a % continuously) I see no reason to change it.  Your way works fine, as does mine.

I've also seen times when you don't allow miners to failover to backup pools when their mining with you is on stale work, I guess in fear of them mining somewhere else? ... ... ... or no notifications waking you up at night if there's a problem with the pool? ... ... ... or assuming the miners at your pool are morons and don't have backup pools?
... yeah I even get a wakeup alert if the work doesn't change for 50 seconds or no one submits a valid share for 40 seconds (and many other more drastic issues) ... yeah those numbers are a very long time in terms of data ... but less than a minute and I get an alert

I don't need alerts.  Eligius hasn't had 1 second of unplanned downtime on the pool side in something like a year.  (And less than 2 minutes of planned down time in the same period)

Not sure how I can prevent miners from jumping to backup pools... sounds like a miner-side configuration thing to me.  Surely if they have backup pools configured and Eligius goes down they'll fail-over.  I don't care either way about that.  Their business, not mine.  If Eligius is accepting their shares I don't know why they would need to fail over... and if they're submitting loads of rejects, sounds again like a miner side issue.  Pretty sure I have little control over if they have backups configured or not.

In seriousness, I do have many alerts setup for all sorts of things.  There are even some remotely monitored security conditions that will remotely cut power to all of Eligius's servers in the event they're triggered (hasn't happened).  As for alerts for other issues, I do have quite a few alerts that happen when things go badly.  First is an email notification, then an SMS notification, then a VoIP phone call with the asterisk chick saying, "Something is terribly wrong!" over and over.  If those all fail somehow, a super annoying sound clip is played through a few devices, some pretty loud much to the displeasure of my wife.

But do keep in mind that bitcoin related things are not my full time job.  I have a real day job (granted it's mostly telecommute these days, but still), so I can't always be interrupted by something in bitcoin land.  Keep in mind that my pool is no-fees run by volunteer work (almost exclusively me these days) and donations.  Not that it actually is in reality, given the stability record, but I think my SLA is allowed to be a little more relaxed than say, a pool earning ~$400/week or more in fees.

Anyway, on the btcd side, you'll notice that the solo pool is faster than your pool
(and has been, except for a few times in the last 2 days due to 0.12.x master failures)

My main btcd is very fast and has been for quite a while due to changes that use the internal prioritisation, no blacklisting and no questionable secret/or otherwise "spam" filters.
It's funny how people have said that GBT is slow due to my misconfiguration of it ... it's not slow itself, that's my fault ...
Yet those same people seem to think that they NEED to bypass it on block changes to get fast ('empty') work out and thus reducing the txn throughput limit of the BTC network by a few % is fine ...

Are the patches you run public?  I'd glady try them out.  If your bitcoind patches are sane and faster than mine I'm not against giving them a whirl.  Everything I'm running on the bitcoind side is actually completely public.  Nothing secret there.  "Questionable" is... questionable, but that's another debate.  But I'm not married to the branch I run.  If there is a better and faster one that doesn't cut any validation corners then that's what I'd run.

GBT is in fact pretty slow with all default bitcoind settings, that's for sure.  Even on a monster of a server with nothing running an all default setting bitcoind will take 10s of seconds to return GBT at times, especially at block changes.  You know the default dbcache setting for bitcoind is only 100MB?!

I think you might have me mixed up with someone else on the 1 tx block issue.  I don't think the 1 tx block speedup is *needed* to get work out quickly, but it is a valid speedup method that adheres 100% to all rules of the network.  We'll never agree on that for whatever reason, but the good thing is we don't actually have to.

And yes, I've noticed that the solo pool has been slightly faster than Eligius and kano.is.  I chalked up the difference to miner connection count differences (solo pool would have the lowest, followed by kano, followed by Eligius), but if there is a valid branch of bitcoind permitting the speedup while retaining full validation, I'm all for it.

[clgrissom3]

It's a pretty bright green block!

[kano]

Wizkid, our enhancements to bitcoind are not public and no we wouldn't be giving them out (as has been stated in the solo pool thread)
One of the reasons is that I certainly am not interested in supporting pools that SPV mine and mine 'empty' blocks.
So yeah not gonna happen
Seriously, I think what you are doing is bad for BTC and I wont help you do it.
I'll also add that your 'public' changes fall under the heading of something I wouldn't do either (I've not even bothered to look at them)
Most spam calculations used are self preserving.
How is spam calculated? What side effect is there of that calculation? The side effect will be to classify more transactions as spam.

The history of your pool dealing with spam and blacklisting would mean I'd not ever even consider 'adding' in whatever it is you do.
Luke-Jr likes to play word games and pretend a isn't a, it's b - everyone knows it's a, but he'll call it b anyway - and he does that with his patches also.

--

As for the speed of the solo pool - no that's nothing to do with the amount of work to send out.
ckpool sends out work exceedingly fast due to the code.
oh and I guess you used to know, but the whole ckpool/ckdb code I run on the pool is here:
https://bitbucket.org/ckolivas/ckpool/src

The only change I make to ckpool is (of course) the payout addresses - they are, as anyone can see, 2 other addresses with a different ratio.

The time to send out work is not multiple seconds.
Solo is faster than kano.is due to -ck making more optimisations in the poorly written btcd-core code than I use.
His block changes are faster than mine on his low end server vs my ... much better ... server.
His worker counts aren't really all that much smaller than mine, not an order of magnitude smaller.

I've also tried mining with a USB miner to antpool to compare, yep it gets work really fast even to way over here in Aus ... to that very large pool with lotsa lotsa workers ... ... ...

[wizkid057]

Wizkid, our enhancements to bitcoind are not public and no we wouldn't be giving them out (as has been stated in the solo pool thread)
One of the reasons is that I certainly am not interested in supporting pools that SPV mine and mine 'empty' blocks.
So yeah not gonna happen
Seriously, I think what you are doing is bad for BTC and I wont help you do it.
I'll also add that your 'public' changes fall under the heading of something I wouldn't do either (I've not even bothered to look at them)
Most spam calculations used are self preserving.
How is spam calculated? What side effect is there of that calculation? The side effect will be to classify more transactions as spam.

The history of your pool dealing with spam and blacklisting would mean I'd not ever even consider 'adding' in whatever it is you do.

Well, I'm not 100% sure what your bitcoind changes have to do with SPV mining or mining blank blocks... seems like if your changes indeed make bitcoind return work/GBT faster than or as fast as the blank block speed up that this would be a positive thing that would deter such optimizations.  If I could get a full template as fast or faster than I can make a blank one then of course I'd use the full template.

As for spam calculations, all public code as mentioned previously.  I've nothing to hide there.  You don't agree with some of it, but, that's your prerogative.  Not suggesting you use the bitcoind branch I use.  Use whatever you want... even XT if that's your thing.

Luke-Jr likes to play word games and pretend a isn't a, it's b - everyone knows it's a, but he'll call it b anyway - and he does that with his patches also.

*shrugs*  I don't care what Luke (or anyone else) says or does or doesn't say or doesn't do with their code/patches.  I review the code I run, regardless of who wrote it, before I run it... especially in a production environment.

As for the speed of the solo pool - no that's nothing to do with the amount of work to send out.
ckpool sends out work exceedingly fast due to the code.
oh and I guess you used to know, but the whole ckpool/ckdb code I run on the pool is here:
https://bitbucket.org/ckolivas/ckpool/src

The only change I make to ckpool is (of course) the payout addresses - they are, as anyone can see, 2 other addresses with a different ratio.

The time to send out work is not multiple seconds.
Solo is faster than kano.is due to -ck making more optimisations in the poorly written btcd-core code than I use.
His block changes are faster than mine on his low end server vs my ... much better ... server.
His worker counts aren't really all that much smaller than mine, not an order of magnitude smaller.

I've also tried mining with a USB miner to antpool to compare, yep it gets work really fast even to way over here in Aus ... to that very large pool with lotsa lotsa workers ... ... ...

I agree that ckpool is extremely fast in general.  It is a C-based pool software, so, it's going to be fast unless the devs are incompetent (there's probably a joke there somewhere).  It should be fast at this, but it is always limited by GBT responsiveness regardless of how fast it is after it gets a response.  Without at least some settings tweaks bitcoind is not even close to fast with GBT, though.

ckpool *does* wait for GBT to return before sending any new work to miners.  It literally can't start sending work faster than bitcoind gets a template.  So, the speedup is in the GBT return time.  The difference between connection counts will have an impact on end user work change times, regardless of what the pool software is, just due to the fact that the actual connection to the internet from the servers is done in sequence, not multicast.  Packets are sent to every miner, so one miner will get their packet out first, and one will get theirs out last.  Granted, the size of the pipe can make this a minimal delta, but it does exist and it does increase with connection count.  Eligius has about 4 gigabit available under normal conditions nowadays, so, work gets out very quickly and the delta between miner 0 and miner N is very small for the initial work update now.

So if you put a properly configured ckpool against a stock settings bitcoind and a properly configured eloipool against the same bitcoind, the eloipool instance would get block changes out to miners faster than ckpool every time since it'll do so based on the P2P block announcement from bitcoind and not wait for GBT.  You and ck have apparently made changes to bitcoind to mitigate this issue to the point where your pool is almost as fast as Eligius at block changes and ck's solo pool is somehow faster.  The latter is pretty impressive without the blank block speed up because it means that not only is GBT time next to nothing, the time needed to actually validate the block is next to nothing.  So, not trivial changes.

Last I checked antpool was SPV/HO mining, but it's been a while.  They lost quite a few blocks in the SPV fork mining on top of F2Pool's invalid chain a ways back.  On the poolbench they're way behind, so, probably not the case anymore, but not sure where your data comes from.  They're definitely not faster than Eligius, kano.is, or ck's solo pool.

Anyway, I've spent enough time on this.  Have fun with your pool.  If you ever decided to release your bitcoind fork, let me know.

[-ck]

You and ck have apparently made changes to bitcoind to mitigate this issue to the point where your pool is almost as fast as Eligius at block changes and ck's solo pool is somehow faster.  The latter is pretty impressive without the blank block speed up because it means that not only is GBT time next to nothing, the time needed to actually validate the block is next to nothing.  So, not trivial changes.

I do indeed still include full validation. All of the changes are in bitcoind on the validation side but they are all non-portable changes, and things that I have no interest in getting past the committee that is bitcoin development, and ultimately I hate to say it but we're running businesses here. I still indeed do full validation but I noticed the current emphasis on benchmarketing block changes so I figured I'd do everything possible - this includes my own variation of blank blocks on blockchange from bitcoind (no, not the patch you are using). I am almost certainly not going to leave it this way but I had set out to try and beat every fully validating node out there My bitcoind patches now are rather large.. it's as good as a fork.

[wizkid057]

You and ck have apparently made changes to bitcoind to mitigate this issue to the point where your pool is almost as fast as Eligius at block changes and ck's solo pool is somehow faster.  The latter is pretty impressive without the blank block speed up because it means that not only is GBT time next to nothing, the time needed to actually validate the block is next to nothing.  So, not trivial changes.

I do indeed still include full validation. All of the changes are in bitcoind on the validation side but they are all non-portable changes, and things that I have no interest in getting past the committee that is bitcoin development, and ultimately I hate to say it but we're running businesses here. I still indeed do full validation but I noticed the current emphasis on benchmarketing block changes so I figured I'd do everything possible - this includes my own variation of blank blocks on blockchange from bitcoind (no, not the patch you are using). I am almost certainly not going to leave it this way but I had set out to try and beat every fully validating node out there

Aha!  Blank blocks! *points* *points*  I knew it!   Kano!  Kano!  CK is mining blank blocks!  *tattles*

lol

@ck - On a serious note, very nice.  Guess I'll have to work on one-upping you later on to get Eligius back to the top of that list while still doing full validation

[kano]

I've no idea exactly what all his changes are he's been trialling ... I only use specific ones I've seen and then in a reduced version
But in my case there are never any blank blocks.

[wizkid057]

I just noticed something weird on your pool stats page.  Your "unworthy" blocks make the luck/CDF stats for the actual block found afterwards completely wrong, don't they?

For example, you have an "unworthy" 378389 block with 129,706,365,253 shares since 377920 was found.  But the next block actually found, 378548, shows only 37,753,537,093 shares and an incorrectly low CDF based on shares since 377920, where in fact it took 167,459,902,346 shares to find 378548, which would be a pretty high CDF (bad luck).  Makes 378548 look lucky, when in fact it wasn't.  Looks the same for all blocks after an "unworthy" block.  Not sure on orphans, and I'll assume your aggregated stats at the top of the page don't have this issue, but I could be wrong.

[kano]

I just noticed something weird on your pool stats page.  Your "unworthy" blocks make the luck/CDF stats for the actual block found afterwards completely wrong, don't they?

For example, you have an "unworthy" 378389 block with 129,706,365,253 shares since 377920 was found.  But the next block actually found, 378548, shows only 37,753,537,093 shares and an incorrectly low CDF based on shares since 377920, where in fact it took 167,459,902,346 shares to find 378548, which would be a pretty high CDF (bad luck).  Makes 378548 look lucky, when in fact it wasn't.  Looks the same for all blocks after an "unworthy" block.  Not sure on orphans, and I'll assume your aggregated stats at the top of the page don't have this issue, but I could be wrong.

Did you read the bottom line of the page? ...
There's a * on each Unworthy and Orphan
The single line stats are on the single line.
- and yeah Unworthy isn't a block, it's just a "very close to being a block" share - but not good enough to be a block.
The awesome stats at the top, take the numbers into consideration correctly as per the comment at the bottom.
https://bitbucket.org/ckolivas/ckpool/src/0635c75560ee1823650d81008da2385f69843624/src/ckdb_data.c?at=master&fileviewer=file-view-default#ckdb_data.c-3035

Edit: I would add re my last comment, I consider blank blocks the cause of SPV, and one really no different to the other in their bad effect on BTC, except that SPV is a faster way to do it.
SPV can be done with enough validation to avoid anything like the last forks.
The only real down side of proper SPV vs blank blocks is some time in the far distant future someone may make one block that causes problems with SPV - they'd need to be very lucky or have lots of hash rate

[wizkid057]

I just noticed something weird on your pool stats page.  Your "unworthy" blocks make the luck/CDF stats for the actual block found afterwards completely wrong, don't they?

For example, you have an "unworthy" 378389 block with 129,706,365,253 shares since 377920 was found.  But the next block actually found, 378548, shows only 37,753,537,093 shares and an incorrectly low CDF based on shares since 377920, where in fact it took 167,459,902,346 shares to find 378548, which would be a pretty high CDF (bad luck).  Makes 378548 look lucky, when in fact it wasn't.  Looks the same for all blocks after an "unworthy" block.  Not sure on orphans, and I'll assume your aggregated stats at the top of the page don't have this issue, but I could be wrong.

Did you read the bottom line of the page? ...
There's a * on each Unworthy and Orphan
The single line stats are on the single line.
(and yeah Unworthy isn't a block, it's just a "very close to being a block" share - but not good enough to be a block.
The awesome stats at the top, take the numbers into consideration correctly as per the comment at the bottom.
https://bitbucket.org/ckolivas/ckpool/src/0635c75560ee1823650d81008da2385f69843624/src/ckdb_data.c?at=master&fileviewer=file-view-default#ckdb_data.c-3035

Edit: I would add re my last comment, I consider blank blocks the cause of SPV, and one really no different to the other in their bad effect on BTC, except that SPV is a faster way to do it.
SPV can be done with enough validation to avoid anything like the last forks.
The only real down side of proper SPV vs blank blocks is some time in the far distant future someone may make one block that causes problems with SPV - they'd need to be very lucky or have lots of hash rate

I read the * note and the ? note.  Doesn't make block 378548 a lucky block, but it's shown as one.  Seems weird to try and display it based on only the shares since the "unworthy" block...

Just like 368390... it wasn't lucky at all, but the stats have it shown in green...

[-ck]

@ck - On a serious note, very nice.  Guess I'll have to work on one-upping you later on to get Eligius back to the top of that list while still doing full validation

Don't worry, when I remove the 0txn blockchange templates shortly you can move ahead in marketing once more - but if you're still behind then, especially considering my entire pool and bitcoind run on a 4 vcpu 4Gb ram vps...

[wizkid057]

@ck - On a serious note, very nice.  Guess I'll have to work on one-upping you later on to get Eligius back to the top of that list while still doing full validation

Don't worry, when I remove the 0txn blockchange templates shortly you can move ahead in marketing once more - but if you're still behind then, especially considering my entire pool and bitcoind run on a 4 vcpu 4Gb ram vps...

Nah, it'll be fine.  Presumably you'd be back at work change speeds at least about where kano is now, which is behind me on average.  I still have a hundred ms or so of speedup possible with my proxy, too, that I haven't had time to code.

As long as my changes are on par with the top full-validating pools, I don't really care much.  I'm not into marketing.

[kano]

...
I read the * note and the ? note.  Doesn't make block 378548 a lucky block, but it's shown as one.  Seems weird to try and display it based on only the shares since the "unworthy" block...

Just like 368390... it wasn't lucky at all, but the stats have it shown in green...

Yep, as I already said

...
The single line stats are on the single line.
...

On the right they show the same number so yes for those 4 blocks you'd have to add the 2 numbers together
... like the code link does for the top.

[wizkid057]

...
I read the * note and the ? note.  Doesn't make block 378548 a lucky block, but it's shown as one.  Seems weird to try and display it based on only the shares since the "unworthy" block...

Just like 368390... it wasn't lucky at all, but the stats have it shown in green...

Yep, as I already said

...
The single line stats are on the single line.
...

On the right they show the same number so yes for those 4 blocks you'd have to add the 2 numbers together
... like the code link does for the top.

I understand your explanation.  And for orphan blocks it would make sense to display things like this.  Throwing these completely fake "unworthy" blocks in the mix just screws things up and makes real blocks look luckier than they really are.  That's all.

[-ck]

@ck - On a serious note, very nice.  Guess I'll have to work on one-upping you later on to get Eligius back to the top of that list while still doing full validation

Don't worry, when I remove the 0txn blockchange templates shortly you can move ahead in marketing once more - but if you're still behind then, especially considering my entire pool and bitcoind run on a 4 vcpu 4Gb ram vps...

Nah, it'll be fine.  Presumably you'd be back at work change speeds at least about where kano is now, which is behind me on average.  I still have a hundred ms or so of speedup possible with my proxy, too, that I haven't had time to code.

As long as my changes are on par with the top full-validating pools, I don't really care much.  I'm not into marketing.

Solo is back to creating full sized blocks on blockchanges (up to 1MB). Kano doesn't have half the code I used on solo but he has MUCH more horsepower at his disposal.

[wizkid057]

@ck - On a serious note, very nice.  Guess I'll have to work on one-upping you later on to get Eligius back to the top of that list while still doing full validation

Don't worry, when I remove the 0txn blockchange templates shortly you can move ahead in marketing once more - but if you're still behind then, especially considering my entire pool and bitcoind run on a 4 vcpu 4Gb ram vps...

Nah, it'll be fine.  Presumably you'd be back at work change speeds at least about where kano is now, which is behind me on average.  I still have a hundred ms or so of speedup possible with my proxy, too, that I haven't had time to code.

As long as my changes are on par with the top full-validating pools, I don't really care much.  I'm not into marketing.

Solo is back to creating full sized blocks on blockchanges (up to 1MB). Kano doesn't have half the code I used on solo but he has MUCH more horsepower at his disposal.

*best Tim the Tool Man impression* Har har har.  More horsepower! 

[kano]

...
I read the * note and the ? note.  Doesn't make block 378548 a lucky block, but it's shown as one.  Seems weird to try and display it based on only the shares since the "unworthy" block...

Just like 368390... it wasn't lucky at all, but the stats have it shown in green...

Yep, as I already said

...
The single line stats are on the single line.
...

On the right they show the same number so yes for those 4 blocks you'd have to add the 2 numbers together
... like the code link does for the top.

I understand your explanation.  And for orphan blocks it would make sense to display things like this.  Throwing these completely fake "unworthy" blocks in the mix just screws things up and makes real blocks look luckier than they really are.  That's all.

Looking at a single block to gauge the luck of the pool is pretty pointless.

The table at the top shows the pool luck ... pretty well with no confusion
... there's even a pretty good graph of the luck and all sorts of other information you can't see without an account

... and yep my usual answer to the question about ... "did you do it correctly" ... is ... "of course".
https://bitbucket.org/ckolivas/ckpool/src/0635c75560ee1823650d81008da2385f69843624/pool/page_luck.php?at=master&fileviewer=file-view-default#page_luck.php-91
I'd suggest a quite reasonable assumption with my code is that I did do it correctly.
If you find a mistake somewhere, I'll fix it, but asking if I did it correctly is pretty pointless unless you've found a bug somewhere.
All code has bugs ... but yeah unless you actually find one ... there's not much point asking if I did something correctly

However, with the blocks page itself, if I start doubling up data on the page, like you are suggesting, then I can see that causing problems for anyone trying to do anything with the data ... and I'm certainly not going to hide anything.

Yes I gather that you assume it's impossible for your code to get a different difficulty calculation than bitcoind ... even though your code is python and bitcoind is C++ - however we don't assume that to be the case and have a small margin of error to ensure we can't throw a block away.
The result is: yes so far twice, 2 "Unworthy" shares on the blocks page.
That information in itself is interesting - so much so that I also have my ckdb console report any shares that are within 5% of being a block (or are a block or better) and also stale/invalid shares that are within 5% of being a block ... or even stale but 'block worthy'
Yep a stale block would suck, and may or may not make it onto the blocks page depending on if it was stale vs bitcoind - in both cases it will show there as an orphan

Now lastly related to that ... regarding this:

...
Orphan rates have been on par and normal despite kano's trolling.
...

You checked that yet?

But this one ...

Kano's own pool has been running about a year, roughly 25% of the time that the current version of Eligius has been online and has mined 368 blocks as of this writing, a whopping 3% of the blocks Eligius has mined and has data on.  I don't know about you, but I'm reasonably certain Eligius has much more valid long term statistical data.  So while kano's young pool may have about 0.5% stale rate over 368 blocks, let's check back in about 30 years when that total block count catches up to what Eligius's today and see where things actually stand.  Kano saying Eligius's orphan rate is high is like a guy at the roulette table who is up a few % after a few hours going around telling people that this roulette table must be better. lol.  Pretty sure I'll stick with legitimate long term stats on the topic when discussing it.

lulz worthy ...

If you want to actually play with numbers, you need to check what your numbers actually mean.
The statistical term that matters is 'confidence interval' and it's not linear
https://en.wikipedia.org/wiki/Confidence_interval

[wizkid057]

...
I read the * note and the ? note.  Doesn't make block 378548 a lucky block, but it's shown as one.  Seems weird to try and display it based on only the shares since the "unworthy" block...

Just like 368390... it wasn't lucky at all, but the stats have it shown in green...

Yep, as I already said

...
The single line stats are on the single line.
...

On the right they show the same number so yes for those 4 blocks you'd have to add the 2 numbers together
... like the code link does for the top.

I understand your explanation.  And for orphan blocks it would make sense to display things like this.  Throwing these completely fake "unworthy" blocks in the mix just screws things up and makes real blocks look luckier than they really are.  That's all.

Looking at a single block to gauge the luck of the pool is pretty pointless.

The table at the top shows the pool luck ... pretty well with no confusion
... there's even a pretty good graph of the luck and all sorts of other information you can't see without an account

... and yep my usual answer to the question about ... "did you do it correctly" ... is ... "of course".
https://bitbucket.org/ckolivas/ckpool/src/0635c75560ee1823650d81008da2385f69843624/pool/page_luck.php?at=master&fileviewer=file-view-default#page_luck.php-91
I'd suggest a quite reasonable assumption with my code is that I did do it correctly.
If you find a mistake somewhere, I'll fix it, but asking if I did it correctly is pretty pointless unless you've found a bug somewhere.
All code has bugs ... but yeah unless you actually find one ... there's not much point asking if I did something correctly

However, with the blocks page itself, if I start doubling up data on the page, like you are suggesting, then I can see that causing problems for anyone trying to do anything with the data ... and I'm certainly not going to hide anything.

Yes I gather that you assume it's impossible for your code to get a different difficulty calculation than bitcoind ... even though your code is python and bitcoind is C++ - however we don't assume that to be the case and have a small margin of error to ensure we can't throw a block away.
The result is: yes so far twice, 2 "Unworthy" shares on the blocks page.
That information in itself is interesting - so much so that I also have my ckdb console report any shares that are within 5% of being a block (or are a block or better) and also stale/invalid shares that are within 5% of being a block ... or even stale but 'block worthy'
Yep a stale block would suck, and may or may not make it onto the blocks page depending on if it was stale vs bitcoind - in both cases it will show there as an orphan

Now lastly related to that ... regarding this:

...
Orphan rates have been on par and normal despite kano's trolling.
...

You checked that yet?

But this one ...

Kano's own pool has been running about a year, roughly 25% of the time that the current version of Eligius has been online and has mined 368 blocks as of this writing, a whopping 3% of the blocks Eligius has mined and has data on.  I don't know about you, but I'm reasonably certain Eligius has much more valid long term statistical data.  So while kano's young pool may have about 0.5% stale rate over 368 blocks, let's check back in about 30 years when that total block count catches up to what Eligius's today and see where things actually stand.  Kano saying Eligius's orphan rate is high is like a guy at the roulette table who is up a few % after a few hours going around telling people that this roulette table must be better. lol.  Pretty sure I'll stick with legitimate long term stats on the topic when discussing it.

lulz worthy ...

If you want to actually play with numbers, you need to check what your numbers actually mean.
The statistical term that matters is 'confidence interval' and it's not linear
https://en.wikipedia.org/wiki/Confidence_interval

Lots to reply to here...

First, yes, looking at a single block to gauge luck is pointless.  But looking at a single block to see how lucky that particular round was is actually important.  You incorrectly report that.

As for the unworthy stuff... while you've posted two blocks that didn't make the cut... I'd be more curious as to if you had any blocks that the pool thought wouldn't make the cut that bitcoind (and the bitcoin network) actually accepted.  Probably not.  Why?  Because math is math.  Just because bitcoind is in C++ and ckpool is in C and eloipool is in python doesn't change the comparison of two numbers.  It's either a block or it isn't.  This whole "unworthy" thing is just nonsense.

As for the rest of your post once again bring up orphan related things out of the blue again... I've been chatting with organofcorti about it.  He said that his data is 1.37% orphans based on data self-reported by pools representing only a fraction of the total network and that it's entirely possible he doesn't have enough data to calculate the actual network wide orphan rate.  More to come on that soon as I gather up the data I have and get it over to him for independent analysis.