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

[WBF1]

I'm not rooting for less hash power, I am rooting for more Luck. Luck is one of those things that everyone knows cannot be changed, yet everyone tries to change it. By wearing the same socks every time they play a game, or not shaving, carrying a rabbits foot, etc. The pools luck lately has been better with a lower hashrate. I know and so does everyone else that it makes more sense to have more hashrate, but I was just pointing out that when everyone was letting their beard grow we had good luck... 

Just coincidence, yes.  Personally, I would rather the luck/variance roll past quicker.  If bad luck must happen (and it must) I would rather get past it quickly than wait more than a week for a block.  Thus, I prefer a higher hash rate.

The only time I get nervous about high pool hash rate is when a lot of it is rented hash.  I'm going to qualify this by saying that I see no evidence of what I'm about to mention happening in the real world (our long term luck says that it isn't).  That said, rented hash does come with the possibility of reducing luck since the actual rig owner no longer has a stake in the pool payout (only the renter does).  Using the West/NiceHash as an example (only because I'm most familiar with them - not because of anything specific to them), the rig owner selling hash to West/Nice has no incentive to actually submit block solves since they are being paid PPS.  They could withhold block solving shares without penalty.  In fact, they have incentive to not submit solves since it helps keeps difficulty lower and indirectly their PPS rate higher!  The renter, who has the actual stake in the pool, has no way of knowing a block was withheld and pays for the broken hash.  It is a risk that has kept me away from renting hash every time I've considered it.

So, there is one real possible way that higher hash rate could be a bad thing, but as far as I know I've never seen it in action.

2. Bad luck lasts longer
Another reason that makes us mis-judge mining luck is that when we mine, we mostly experience bad luck. In fact if you go to the trouble of working it out, your hours of mining will be about one-quarter good luck and three quarters bad luck. Why? Bad luck takes longer, good luck rounds take much less time.

3. Assessing luck over time instead of blocks
Another mistake made by novice miners is to assume that the extremes of luck will be the same for all pool over any time frame. This is wrong for two related reasons:

    The more blocks are solved the closer luck approaches 100%
    Because the timeframe for luck to to approach 100% varies depending on number of blocks solved, comparing various pools' luck over the same time period is invalid. Instead we need to compare luck over similar number of blocks.

from: http://organofcorti.blogspot.com/2015/07/faq-bitcoin-mining-and-luck-statistic.html

[1715539182]

1715539182

[1715539182]

1715539182

[1715539182]

1715539182

[1715539182]

1715539182

[sorry2xs]

a power failure has caused all s3 with latest update to fail to restart???

[kano]

My best share reset a little bit ago.  The pool doesn't say it found a block.  Did the pool restart?

There's been a few restarts dealing with the block change times on that crappy slow getblocktemplate command that some phailure wrote that's in bitcoind ...

... but bestshare isn't an attribute of kano.is ...

It's on solo.ckpool.org and yes someone found a block there earlier.

[kano]

a power failure has caused all s3 with latest update to fail to restart???

Only thing I can think of is if the /overlay/ got corrupted due to the power failure and now there's a problem starting.
But my update makes no difference to that problem.

What do you mean by "fail to restart"
Does it boot and you can see the web but cgminer wont start?
Does it not boot at all?

I power off my S3s every day with the power switch on my PSU and then switch them on again the same way - never had one of them fail to start up when doing that.

[chentron]

it happens to me at least twice today.
miners appear with a hashrate like if the pool have a restart.

[kano]

it happens to me at least twice today.
miners appear with a hashrate like if the pool have a restart.

...
There's been a few restarts dealing with the block change times on that crappy slow getblocktemplate command that some phailure wrote that's in bitcoind ...
...

Last thing we want is an orphan, and this has been to do with keeping our block change time as low as possible.

[sorry2xs]

a power failure has caused all s3 with latest update to fail to restart???

Only thing I can think of is if the /overlay/ got corrupted due to the power failure and now there's a problem starting.
But my update makes no difference to that problem.

What do you mean by "fail to restart"
Does it boot and you can see the web but cgminer wont start?
Does it not boot at all?

I power off my S3s every day with the power switch on my PSU and then switch them on again the same way - never had one of them fail to start up when doing that.

S3s show web ui but will not mine at any b/u pool or primary had to do a system reset back to bitmain

[os2sam]

My best share reset a little bit ago.  The pool doesn't say it found a block.  Did the pool restart?

There's been a few restarts dealing with the block change times on that crappy slow getblocktemplate command that some phailure wrote that's in bitcoind ...

... but bestshare isn't an attribute of kano.is ...

It's on solo.ckpool.org and yes someone found a block there earlier.

Sounds good.  Thanks for the development.

The minimal stat's via my Bitcoin address show the bestshare just like on solo.ckpool.

{"hashrate1m": "814G", "hashrate5m": "744G", "hashrate1hr": "778G", "hashrate1d": "122G", "lastupdate": 1436549256, "bestshare": 3623383.4471292584}

Thanks,
Sam

[CapnBDL]

No problems at all /w the latest s3 update. My little workhorse s3+ is purrin' like a kitten. Thank you kano!!

[kano]

My best share reset a little bit ago.  The pool doesn't say it found a block.  Did the pool restart?

There's been a few restarts dealing with the block change times on that crappy slow getblocktemplate command that some phailure wrote that's in bitcoind ...

... but bestshare isn't an attribute of kano.is ...

It's on solo.ckpool.org and yes someone found a block there earlier.

Sounds good.  Thanks for the development.

The minimal stat's via my Bitcoin address show the bestshare just like on solo.ckpool.

{"hashrate1m": "814G", "hashrate5m": "744G", "hashrate1hr": "778G", "hashrate1d": "122G", "lastupdate": 1436549256, "bestshare": 3623383.4471292584}

Thanks,
Sam

Oh right - yeah I forgot about that - indeed that data is the same as solo since it's ckpool that generates it, not ckdb
(To make that work originally I just added a script to pass it back for address miners)
Oops
I guess ckpool resets it on a restart but I've never noticed since I don't display it anywhere on the web site for account users.

[kano]

a power failure has caused all s3 with latest update to fail to restart???

Only thing I can think of is if the /overlay/ got corrupted due to the power failure and now there's a problem starting.
But my update makes no difference to that problem.

What do you mean by "fail to restart"
Does it boot and you can see the web but cgminer wont start?
Does it not boot at all?

I power off my S3s every day with the power switch on my PSU and then switch them on again the same way - never had one of them fail to start up when doing that.

S3s show web ui but will not mine at any b/u pool or primary had to do a system reset back to bitmain

Then I guess the /overlay/ got corrupted by the power failure?
It stores anything that changes including your settings and info like the system settings.
If you've factory reset it then that will wipe /overlay/ and reinitialise it also so that would certainly have fixed it.

The 3 changed files that affect the mining working are the replacement /usr/bin/cgminer  /etc/init.d/cgminer and the matching changed settings /etc/config/cgminer
(the other changes wont stop it mining - they affect the display and changing the /etc/config/cgminer file)
Those three files have to 'match'
If one is reset and they don't match, then just redo the update process to fix the file(s) in /overlay/ that was/were effectively deleted by the corruption
(including running the cgset command)
i.e. just run the full update process again.

Again, I switch my 2 off at the power each day and haven't had any /overlay/ corruption, but it's not completely impossible, since it is a live running system with a write enabled folder that can of course, like any computer, be corrupted by switching it off at the wall - though since /overlay/ isn't written to very often, it's not likely to happen.

[-ck]

Just to let miners know, Kano and I worked on minimising the latency of bitcoind under the current flood of transactions and I'm happy to say that we've been able to deploy some of my custom modifications to this and solo ckpool which still guarantee maximum transaction processing (i.e. never a zero transaction block) while minimising the risk of stale work / orphans. Plus we are NOT using a transaction blacklist; all transactions are prioritised on their own merit as per bitcoind rules.

[p3yot33at3r]

Just to let miners know, Kano and I worked on minimising the latency of bitcoind under the current flood of transactions and I'm happy to say that we've been able to deploy some of my custom modifications to this and solo ckpool which still guarantee maximum transaction processing (i.e. never a zero transaction block) while minimising the risk of stale work / orphans.

Gimme gimme........

[-ck]

Gimme gimme........

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

[CapnBDL]

Gimme gimme........

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

And just a word or two...This pool rocks because of the work you and kano do!!       

[LoneRangir]

Looks like we just found a block

[kano]

Looks like we just found a block

Yep and very much thanks to the higher pool hash rate of the list of top miners, and canaan most of course, the pain of a slow block was indeed much shorter than it has been lately

But the txn fees have been good for the last 5 blocks also: approximately 2% 1% 1% 2% 1%

[LoneRangir]

And another! Woot!

[WBF1]

@kano is there any reason payments to a P2SH address (aka "3 series") wouldn't work for payouts from your pool? I thought I'd check for sure. I believe some pools and services have issues sending to anything other than addresses starting with "1".

[kano]

@kano is there any reason payments to a P2SH address (aka "3 series") wouldn't work for payouts from your pool? I thought I'd check for sure. I believe some pools and services have issues sending to anything other than addresses starting with "1".

Our first payout included one ...
Yes it works.