Topic: KanoPool kano.is lowest 0.9% fee 🐈 since 2014 - Worldwide - 2432 blocks - page 1040. (Read 5352445 times)

Is anyone else able to login in to the website? I keep getting a "Logins currently disabled" message

Phil, remember that back to back CDF of 99% is 1 in 10,000, but that is *only* when looking at the next 2 blocks.  If you mine 100 blocks at the pool, your back to back CDF of 99% has a 1 in 100 shot over the 100 block span.  That is still bad, but not as bad as 1 in 10,000.  If a pool hit 1 in 10,000 and they haven't mined 10,000 blocks, run!!!

You might have been saying the above, I just want people to remember that over time you are expected to hit some extremes and unfortunately they are normal.  But, that can work both ways.  This pool has a 17% CDF for all time, and that is amazing!

I don't remember the name, but I think its website had a brownish color scheme. This was more likely late 2011, back when the common pool payout method was proportional (a few had PPS) and pool hopping was a thing. At the tail end of the GPU era with the first BFL FPGAs trickling out.

A few months before, someone (Meni?) had posted proof that hopping was much more profitable and so we were torturing the pools with essentially a miner DDoS right after they found a block to try and get a few shares in any short blocks. It was one of the 8-12 pools I would hop. There were grumblings about how this specific pool never seemed to have really short blocks, and someone looked at the stats to see that indeed there seemed to be a cutoff.

People kept hopping it for a few months and eventually the pool got hacked with it's source leaked showing they would set the payout address to their own on a block change and update it to the pools after some percentage of difficulty had been hashed.

Now this was all years ago and things were changing so fast back then that I'm sure some of the few details I remember are mashed up with other things or out of order. I'm almost certain it was the pool with the brown color scheme, there was another questionable pool that was white with lots of text and charts that was also shady, but lasted much longer.

The Avalons 721s x 120; are mining here at Kano.

The S9s v1 x 108; are mining somewhere else.

Both farms are powered by hydroelectricity at Cryptoboreas Inc., Labrador-NFL, Canada.

I just run Avalon 1.5 days.
The invaid of Canaan too high. Just for the new block, the invalid if 2 A741 and 1 A721 in a chain is 1%. Invalid of R4 is 0%. How to fix the invalid and how invalid affect your luck pool or my hashing and sharing?

The invalid is stale share? Do I get paid for that? And how to avoid that?

Hi fellow miners   Once again I have not been on this thread for almost 2 weeks bc I've just been too busy doing other stuff. Loved how Feb performance went out with a bang, very nice! While I was reading the last 12 pages or so, we found a block! Woo hoo! Really cold in New Jersey today but nice & sunny so solar panels are starting to crank & should generate about 22kW today - yay!

@Citronic: Welcome back!

To those who have been asking how we like Kano's pool, I 'm just a very small hobby miner but I wouldn't point my gear anywhere else. Kano runs an honest, efficient pool with low fees and he's always on top of things. You can't do better anywhere else. Just keep in mind, you have to think long term and don't panic when luck goes bad for several days or more... It's just variance and in the long run it all evens out very nicely.

Mine on 

Yippee!!!!

Finally, BLOCK!

Now let's get some freakin' GREEN BLOCKS going!!!  

Let's do this!!!!

Do you remember which pool?

Wasn't accusing you specifically, was just commenting on another reason a pool might see horrible luck. I'd venture to guess many miners don't check every piece of hardware for block found counts, and a bmminer restart or hardware reboot will wipe those stats.

It was easier to get away with back when the found block notification would scroll off the screen when you weren't looking.

I'd also have to somehow stop the person who found the block from knowing they found it on their miner
Now that would be a tricky thing to do unless Bitmain put something into their bmminer to hide blocks ... ... ... ... ...

Low % blocks ... 3 in the last 100 are: 1.774% 1.175% 1.141% ...

OK, I'm leaving this block to the grave-yard shift.
Please knock this sucker out before I get up tomorrow.
(And a couple additional would be nice with coffee!  )
My 64TH will be hashing away all night.

Good night and good luck!!!
BLOCKSSSSSSSSSSSSSSSSSSSS!!!!!!!!!!!!!! 

No and we have not had bad luck since December.

The 65 days in 2017 are about average.

Your problem is you are thinking short term and your  definition of bad luck is not very good.

The last two blocks were not back to back 99%. Which is my definition of bad luck for short term

So our bad block is caused by some bad gears? What make our miners be bad gears?

March has certainly begun with a definite suck-itude as far as our pool blocks, my home computer hardware (including miner problems), and server/ work station problems at work.
Curses and the pending Ides of March BEGONE!!!!

Let's crack these freaking BLOCKSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS!!!!!!!!!!!!

And get some GREEN BLOCKSSSSSSSSSSSSSSSSSSSSSSSSSS FLOWING!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

That falls under bad code , but could be teased out of that slot .

maybe

 bad code and or bad pool op.

or two separate spots.

I had a pool with 6 of 10 over 90%  and 2 of then 90's were 99 back to back.

I stopped mining there a few years back.

Or the pool owner decided to snag a block reward for themselves. I hazily recall a pool getting caught out for the statistical improbability of their never finding extremely lucky blocks back around 2012. Turned out the owners were taking all the blocks the pool found below a certain share threshold.

no and yes.

it all depends on how well coded the pool is.


If a pool is created code and equipment and internet close to flawless  luck should run better then 99% 

An example
in the long run a clean perfect coin toss should be 50-50.

So if a guy tossing a coin is doing 60-40  for a hundred tosses  you start to think  the coin is not perfect.


So  if kano's pool is :
 good code
 good server
 good internet

with good mining gear it should run  very close to 99%   luck  which is around 60% cdf


So  luck and cdf are not the same term.

When a pool tosses a 99% cdf  it should be 1 of every 100 blocks

if they toss back to back that is  1 in 10000 chance   my guess is the pool has

bad code
bad server
bad internet
or bad gear mining on it.

So the CDF is really important to the pool luck in future? Or it is the history of luck?
If any pool always get some bad block, that pool will be close?

Well the problem seems to be the recent calculations of what fees need to be sent.
If everyone is saying higher fees need to be sent then that will simply cause an escalation into higher fees.
It's a feedback loop created by ... who knows who.

One of the 'old' solutions was to pay a low fee and consolidate your rewards every so often, and I think that might still work ok.
I tend to manually generate lower fee transactions if I send BTC (lately) and they do get confirmed as long as they aren't too low.

The problem with an "accelerator" is that if too many people use it, it causes the problem that I was discussing in here before.
I was saying that putting our payout transactions into the block is not a big deal coz it will push out low fee transactions.
However, if we are putting a lot of "accelerated" low fee transactions into the block - and while we aren't big enough to find multiple blocks a day - that will produce a noticeable fall in the block txn fees.

If I ever did an "accelerator" - which I doubt I would - it would also be limited to consolidating only pool rewards and nothing else.
This would simply be a "do it once a month" or some such for people with smaller rewards.

The real problem is the feedback loop I mentioned above.
Even with payouts of 10's to 100's of dollars each block, it still costs a lot to use them.
The problem is (as you've implied) bitcoin at the moment.
Though, I like to think of it as a reminder that you should expect long term for a rise in the value of bitcoin and hold onto your coins

I do have a plan to deal with it, but it relates to something I've stated many times I don't want to do
The problem with using non-block payouts is that I effectively become a bank holding funds for people ... and that ends up being a large amount of $
My solution will probably be to allow an account to flag a request to accept payouts less often.
Accounts below some amount will also be force flagged.
Then I guess I'd do a weekly or monthly payout to cover most of the accounts with the flag, or accounts earning below some limit, and maybe once in a blue moon also clean up, and pay out, some of the tiny dust only accounts that are idle, and close those ones.
i.e. I don't want to be an actual bank where people leave their BTC to withdraw at some later date, or never.
I want to get the BTC out of the pool wallet, it's not mine, I don't want it ...

The current changes (already into a few thousand lines of code), to deal with changing the main key everywhere in the ckdb code, and the side effects of that everywhere, are getting close to testing the first stage of that.
Once the first stage is complete, the rest of the changes are much simpler, so wont take anywhere near as long.
Once that's all complete, so that distribution of the pool will work more reliably, then "accounting" should be the next major change I'll work on.