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

[-ck]

Wow guys - that's some blocktastic green run you've got going on there, well done!

Do you think it's because of your modifications -ck mentioned earlier?:

Gimme gimme........

The modifications are custom and private, sorry Pools need to have some advantage.

I'm intrigued......

No

[p3yot33at3r]

Luck it is then......

[-ck]

Luck it is then......

Yes

[kano]

Wow guys - that's some blocktastic green run you've got going on there, well done!

Do you think it's because of your modifications -ck mentioned earlier?:

Gimme gimme........

The modifications are custom and private, sorry Pools need to have some advantage.

I'm intrigued......

Well ... actually ... it is valid to say it affects the % luck of the pool.

There is a problem in the bitcoin world of saying what the pool's luck is.

Although you would statistically expect that over a long period of time, the pool's accepted hashes would approach the expected: 100% luck, that isn't completely true.

There are factors that reduce the number of blocks found.
Specifically orphans.
Some pools have long term bad luck because they are slow at handling block changes and lose more blocks because of that.
Eligius is an example of this

There were also pools that counted stale shares for a short period of time after the block change had occurred.
While this makes the pool look better by lowering and lying about their reject statistics, it also has the long term effect of lowering the pool luck.
Not sure which pools do this.

One pool in particular doesn't count all the hashes used to produce it's blocks and thus reports luck higher than it really is.
P2Pool

The change does have a long term affect on our % luck, but it doesn't affect what is really 'Luck' - which isn't exactly what pools report

However, it is also true to simply say that running ckpool has a long term effect on the % luck since it handles block changes very fast.

[pekatete]

The change does have a long term affect on our % luck, but it doesn't affect what is really 'Luck' - which isn't exactly what pools report

However, it is also true to simply say that running ckpool has a long term effect on the % luck since it handles block changes very fast.

I've actually had the same thing on my mind since ck posted the message about the changes made (I believe that was during the "attack" on the network). I won't speculate as to what the changes may have been as it is to a large extent over my head, but suspected the changes would reduce the variance of the pool's luck (ultimately, as you say, seemingly improving the pool's luck, ie smooth it).

Now I know ck said those changes are being kept for the pool to have a better advantage over other solo pools, but wouldn't adding (some of) those features to a distributed proxy (which I believe distributed ck pool code has) go even further to improve / smooth the pool's luck to all our benefit?
(just a thought ...)

[kano]

Well ... we did an hour and a half ago

Payouts 365491 and 365509 sent
f9811d479993f1cdfc2030ac9bdc9a4a79aa91c2b60aae1d2aea84bb82c40940
8e37ec2c2cbc6ac1877153c4dd7aede4341535f8271c3065e30e6e191e734ccf
and both confirmed

[PPOC]

Well ... we did an hour and a half ago

Payouts 365491 and 365509 sent
f9811d479993f1cdfc2030ac9bdc9a4a79aa91c2b60aae1d2aea84bb82c40940
8e37ec2c2cbc6ac1877153c4dd7aede4341535f8271c3065e30e6e191e734ccf
and both confirmed

So whats the odds of keeping the luck at over 200% for the next 10 block with such a good luck streak over the last 10 block, or 25 and 50 for that matter.......

[LoneRangir]

Not sure the odds, but we found another one!

[WBF1]

Wow guys - that's some blocktastic green run you've got going on there, well done!

Do you think it's because of your modifications -ck mentioned earlier?:

Gimme gimme........

The modifications are custom and private, sorry Pools need to have some advantage.

I'm intrigued......

Well ... actually ... it is valid to say it affects the % luck of the pool.

There is a problem in the bitcoin world of saying what the pool's luck is.

Although you would statistically expect that over a long period of time, the pool's accepted hashes would approach the expected: 100% luck, that isn't completely true.

There are factors that reduce the number of blocks found.
Specifically orphans.
Some pools have long term bad luck because they are slow at handling block changes and lose more blocks because of that.
Eligius is an example of this

There were also pools that counted stale shares for a short period of time after the block change had occurred.
While this makes the pool look better by lowering and lying about their reject statistics, it also has the long term effect of lowering the pool luck.
Not sure which pools do this.

One pool in particular doesn't count all the hashes used to produce it's blocks and thus reports luck higher than it really is.
P2Pool

The change does have a long term affect on our % luck, but it doesn't affect what is really 'Luck' - which isn't exactly what pools report

However, it is also true to simply say that running ckpool has a long term effect on the % luck since it handles block changes very fast.

So it may lead to a better "luck" the metric but has no impact on "Luck" the abstract concept of things seeming to go your way.

[kano]

Well ... we did an hour and a half ago

Payouts 365491 and 365509 sent
f9811d479993f1cdfc2030ac9bdc9a4a79aa91c2b60aae1d2aea84bb82c40940
8e37ec2c2cbc6ac1877153c4dd7aede4341535f8271c3065e30e6e191e734ccf
and both confirmed

So whats the odds of keeping the luck at over 200% for the next 10 block with such a good luck streak over the last 10 block, or 25 and 50 for that matter.......

Well in the simplest terms ...
For the 5 block luck to stay the same or be better, the new block found must be the same or better than the current 5th block.
i.e. the 5 block range drops one off the end when it adds a new one on the front.

That's of course the same for each of the block ranges (except the "All" blocks one)
How much the range luck will change will depend on the luck of the new block found vs the one dropped off the end of the range.

[kano]

Payout 365602 sent
0469d434de8bfc6561e6eb9c440e8eb1885d5a38b3b779ff6b646e6e4615a5a1
and confirmed

Payout 365637 sent
39ac3b69b3b158a659f72cb061689da7844d6d6f80dd6150127a82e93e5ff6a3
and confirmed

[kano]

...

So whats the odds of keeping the luck at over 200% for the next 10 block with such a good luck streak over the last 10 block, or 25 and 50 for that matter.......

To answer that in terms of a run of blocks, (which I didn't in the last answer ...)
Well, firstly, the previous 5, 10, 25 have no effect on the next 5, 10, 25.
But the CDF[Erl] of the block range gives you insight into the chances of getting the current value ... and of course the chance of repeating the same performance at the end of the next N blocks

[Dmc123dmc]

Hi Kano, since BTCGUILD closed down i have used a few pools but none that made me want to stick with them. I happened upon this thread and your attitude and honesty have won me over so i'm pointing my s3+'s at your pool and will keep them there. I see you have written some modifications for the s3 but i can't seem to find the all the information. Is there a thread that explains it fully? Are there any performance gains or is it mainly a graphical change? Thanks in advance!

[kano]

Hi Kano, since BTCGUILD closed down i have used a few pools but none that made me want to stick with them. I happened upon this thread and your attitude and honesty have won me over so i'm pointing my s3+'s at your pool and will keep them there. I see you have written some modifications for the s3 but i can't seem to find the all the information. Is there a thread that explains it fully? Are there any performance gains or is it mainly a graphical change? Thanks in advance!

Firstly the AntS3 README is here:
https://github.com/kanoi/cgminer-binaries/tree/master/AntS3
One big change I've added since I merged in the S3 changes into master git is to reduce CPU usage.
You'll find the Load Average spends most of it's time under 1.0 - and that change is advantageous, not harmful.
I basically removed a major CPU waste, doing something unnecessary.

There are a bunch of issues with the bitmain fork of cgminer, which are not in the master cgminer of course.
They are actually listed in the S2 README:
https://github.com/kanoi/cgminer-binaries/tree/master/AntS2
down at the initial release

Master cgminer doesn't have the Best Share of Diff setting problem either (they added that problem to some of their versions)
Also, of course, it's the latest cgminer 4.9.2 which means it has all the latest cgminer fixes

The update is not a flash change, just a few reasonably simple steps to extract an archive into the Ant
The archive file is simply a gzipped tar of the changes that are all effectively the source code except for the cgminer binary itself.

The web interface changes are listed in the AntS3 README, the most important one being you can see and modify the API allow settings to make it secure.

Since you have an S3+ make sure you check what your settings are in the Advanced Tab before you update and set/save them again after the update.
However it's easy to see what settings my version is running since I also display them at the bottom of the Miner Status web page

[Dmc123dmc]

Hi Kano, since BTCGUILD closed down i have used a few pools but none that made me want to stick with them. I happened upon this thread and your attitude and honesty have won me over so i'm pointing my s3+'s at your pool and will keep them there. I see you have written some modifications for the s3 but i can't seem to find the all the information. Is there a thread that explains it fully? Are there any performance gains or is it mainly a graphical change? Thanks in advance!

Firstly the AntS3 README is here:
https://github.com/kanoi/cgminer-binaries/tree/master/AntS3
One big change I've added since I merged in the S3 changes into master git is to reduce CPU usage.
You'll find the Load Average spends most of it's time under 1.0 - and that change is advantageous, not harmful.
I basically removed a major CPU waste, doing something unnecessary.

There are a bunch of issues with the bitmain fork of cgminer, which are not in the master cgminer of course.
They are actually listed in the S2 README:
https://github.com/kanoi/cgminer-binaries/tree/master/AntS2
down at the initial release

Master cgminer doesn't have the Best Share of Diff setting problem either (they added that problem to some of their versions)
Also, of course, it's the latest cgminer 4.9.2 which means it has all the latest cgminer fixes

The update is not a flash change, just a few reasonably simple steps to extract an archive into the Ant
The archive file is simply a gzipped tar of the changes that are all effectively the source code except for the cgminer binary itself.

Thanks for clarifying. Updated the first one and about to update the second with no issues.

The web interface changes are listed in the AntS3 README, the most important one being you can see and modify the API allow settings to make it secure.

Since you have an S3+ make sure you check what your settings are in the Advanced Tab before you update and set/save them again after the update.
However it's easy to see what settings my version is running since I also display them at the bottom of the Miner Status web page

Thanks for clarifying and pointing me to your github. First one done with no issues and about to do the second.

[elduderino]

Hi,

Just a quick question for anyone who's mining on the pool right now:

Is all your hashing showing up? Just double-checking if it's just a problem with my hosted miners or the pool.

Thanks!

[thedreamer]

Yeah  that's fine. Although ck broke the pool with his update. We haven't had a block solve since.
Can we start the hourly restarts? Lol

[elduderino]

Yeah  that's fine. Although ck broke the pool with his update. We haven't had a block solve since.
Can we start the hourly restarts? Lol

Lol, I'm all for it!

Thanks, bud.

[kano]

Well from the mining side you shouldn't be mining to an IP address
I'll look into seeing what they say about the rdns ...

[kano]

Well from the mining side you shouldn't be mining to an IP address
I'll look into seeing what they say about the rdns ...

I wasn't doing any mining, just troubleshooting slowdowns and 'website access denied' problems on a completely unrelated web sites. I've accidentally found that your has the same problem as the other ones. This could cause you (and your members) problems as the most common symptom was 'slowdown', not 'doesn't work anymore', depending on the firewall setup on the miner's end.

Yeah they'll be updated soon.
I'm not exactly sure if they did it on purpose or by mistake for the defaults - though I did ask them but they skipped that question among the rest.
I've sent them updates but they also initially just removed the '$' characters so that should be resolved now or some time in the next 24hrs or so.
I've not actually had anyone ask about slow web access.
The web site it very fast ... most of the time ... by design