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

[smutboy420]

just a ? and maybe a sort of a heads up to kano in case it is an issue that you are not aware of..      

for the last 2 weeks I happened to notice that any time a block is found on the network and then the pool starts working on a new block. I have noticed the time it takes for the pool to start on the new work is some times as much as 5 mins behind.

for instance block number 499476 found by slushpool at 2017-12-15 13:31  and then they instantly started working on block 499477 and working on it for almost 5 mins before the time kano pool switched and started the new work on trying to work on block 499477

sometimes its only about 15-20 seconds difference that the pool takes to switch on to a new block and get to work and figured that was just normal time its taking for other pools to switch work after another pool finds a block..    But over 4 mins seems like a real long relay time.  

so incase that is longer then it should take I figured I would say something to let you know so if it is a problem you could see what the cause might be.   Tho if not then I guess its no biggie and you would know its not any thing that could cause any issue with the pool missing out on the big race to find a block before any other pool ever did.  

[Waztim]

just a ? and maybe a sort of a heads up to kano in case it is an issue that you are not aware of..      

for the last 2 weeks I happened to notice that any time a block is found on the network and then the pool starts working on a new block. I have noticed the time it takes for the pool to start on the new work is some times as much as 5 mins behind.

for instance block number 499476 found by slushpool at 2017-12-15 13:31  and then they instantly started working on block 499477 and working on it for almost 5 mins before the time kano pool switched and started the new work on trying to work on block 499477

sometimes its only about 15-20 seconds difference that the pool takes to switch on to a new block and get to work and figured that was just normal time its taking for other pools to switch work after another pool finds a block..    But over 4 mins seems like a real long relay time.  

so incase that is longer then it should take I figured I would say something to let you know so if it is a problem you could see what the cause might be.   Tho if not then I guess its no biggie and you would know its not any thing that could cause any issue with the pool missing out on the big race to find a block before any other pool ever did.  

I had noticed the same thing. Kano assured me that the Pool immediately goes to work on the new work for the new block. No delays. He would know since he has the tools to monitor the hash on each block. He explained to me that many Internet providers use proxies for websites and they are not always updated properly. I pushed the I believe button because he would know since he is monitoring the back end. Now with that said... timing in this game is everything. Ensure that you mine to the fastest ping Pool node for your location. In my case, it is the NYA with a 14ms ping.

MINE ON!!! KANO-SAN has got our back!!

[smutboy420]

just a ? and maybe a sort of a heads up to kano in case it is an issue that you are not aware of..      

for the last 2 weeks I happened to notice that any time a block is found on the network and then the pool starts working on a new block. I have noticed the time it takes for the pool to start on the new work is some times as much as 5 mins behind.

for instance block number 499476 found by slushpool at 2017-12-15 13:31  and then they instantly started working on block 499477 and working on it for almost 5 mins before the time kano pool switched and started the new work on trying to work on block 499477

sometimes its only about 15-20 seconds difference that the pool takes to switch on to a new block and get to work and figured that was just normal time its taking for other pools to switch work after another pool finds a block..    But over 4 mins seems like a real long relay time.  

so incase that is longer then it should take I figured I would say something to let you know so if it is a problem you could see what the cause might be.   Tho if not then I guess its no biggie and you would know its not any thing that could cause any issue with the pool missing out on the big race to find a block before any other pool ever did.  

I had noticed the same thing. Kano assured me that the Pool immediately goes to work on the new work for the new block. No delays. He would know since he has the tools to monitor the hash on each block. He explained to me that many Internet providers use proxies for websites and they are not always updated properly. I pushed the I believe button because he would know since he is monitoring the back end. Now with that said... timing in this game is everything. Ensure that you mine to the fastest ping Pool node for your location. In my case, it is the NYA with a 14ms ping.

MINE ON!!! KANO-SAN has got our back!!

True I know if there is anyone thats can be trusted to even know what he's talking about as far as how things work its Kano. and if something was anything that could cause problems with the pool or cause it to have worse luck hitting blocks it would be in his interest and every one mining to find and fix and bugs or issues that were found if there was a problem with anything.

and glad to know that delay in the time shown from the time new work started on block and new work is not a real problem. Tho now that I thing about it some more and knowing how the info pages are also on a different server than the actual pool its self I can see how it would have to lag behind a bit on what ever data that needs to go from one place to another to be displayed.

[fjtropepe]

Just made is to Disney World for the weekend. On my way to a meeting with the 7 dwarfs. Going to get this mining issue resolved. Heard they know how to crack blocks.

[kano]

just a ? and maybe a sort of a heads up to kano in case it is an issue that you are not aware of..      

for the last 2 weeks I happened to notice that any time a block is found on the network and then the pool starts working on a new block. I have noticed the time it takes for the pool to start on the new work is some times as much as 5 mins behind.

for instance block number 499476 found by slushpool at 2017-12-15 13:31  and then they instantly started working on block 499477 and working on it for almost 5 mins before the time kano pool switched and started the new work on trying to work on block 499477

sometimes its only about 15-20 seconds difference that the pool takes to switch on to a new block and get to work and figured that was just normal time its taking for other pools to switch work after another pool finds a block..    But over 4 mins seems like a real long relay time.  

so incase that is longer then it should take I figured I would say something to let you know so if it is a problem you could see what the cause might be.   Tho if not then I guess its no biggie and you would know its not any thing that could cause any issue with the pool missing out on the big race to find a block before any other pool ever did.  

I had noticed the same thing. Kano assured me that the Pool immediately goes to work on the new work for the new block. No delays. He would know since he has the tools to monitor the hash on each block. He explained to me that many Internet providers use proxies for websites and they are not always updated properly. I pushed the I believe button because he would know since he is monitoring the back end. Now with that said... timing in this game is everything. Ensure that you mine to the fastest ping Pool node for your location. In my case, it is the NYA with a 14ms ping.

MINE ON!!! KANO-SAN has got our back!!

True I know if there is anyone thats can be trusted to even know what he's talking about as far as how things work its Kano. and if something was anything that could cause problems with the pool or cause it to have worse luck hitting blocks it would be in his interest and every one mining to find and fix and bugs or issues that were found if there was a problem with anything.

and glad to know that delay in the time shown from the time new work started on block and new work is not a real problem. Tho now that I thing about it some more and knowing how the info pages are also on a different server than the actual pool its self I can see how it would have to lag behind a bit on what ever data that needs to go from one place to another to be displayed.

So going through the logs for that specific block:

499476
000000000000000000a90fdd34d539c9a25a56355a245708ff855f9e3245e98b

Pool log:
[2017-12-15 18:31:22.912+00] Block hash changed to 000000000000000000a90fdd34d539c9a25a56355a245708ff855f9e3245e98b

Mining monitor - when it saw the block change.
It's in the USA and connects to every mining node (not in china) no some may take a fraction of a second longer,
The last one (pool 1) is in singapore and I guess the connection from the USA to there and back to the USA was a little slow for that one
But the times there show when the work change, sent from the main server, arrived at the monitor, after going via the node.
 [2017-12-15 18:31:22.953] Stratum from pool 10 detected new block at height 499476
 [2017-12-15 18:31:22.956] Stratum from pool 0 requested work restart
 [2017-12-15 18:31:22.960] Stratum from pool 11 requested work restart
 [2017-12-15 18:31:22.963] Stratum from pool 7 requested work restart
 [2017-12-15 18:31:23.004] Stratum from pool 4 requested work restart
 [2017-12-15 18:31:23.012] Stratum from pool 8 requested work restart
 [2017-12-15 18:31:23.012] Stratum from pool 6 requested work restart
 [2017-12-15 18:31:23.045] Stratum from pool 9 requested work restart
 [2017-12-15 18:31:23.220] Stratum from pool 2 requested work restart
 [2017-12-15 18:31:23.238] Stratum from pool 5 requested work restart
 [2017-12-15 18:31:23.376] Stratum from pool 3 requested work restart
 [2017-12-15 18:31:25.727] Stratum from pool 1 requested work restart

So basically it's all OK for that block, so I'm not sure what the cause was for you seeing it minutes later.
Also note that the web site shows the time in the bottom left and right in tiny letters - check what it says there also next time you see this.
The left is the web server UTC and the right is what your browser thinks the current time is.
i.e. you may be seeing a cached copy of the web site and it would show the server time in the past.

The web server itself doesn't use any caching or cloudflare or anything like that since firstly, cloudflare is a security risk (you have to give them your SSL certificate and thus trust every employee of every company that has access to their servers) and secondly, the code/server is configured to handle the load pretty well without the need for that.
i.e. the web server doesn't take minutes to send you the data, it's immediate, and the data it uses is immediate.
The timeouts that sometimes occur, might cause a delay since the web page is made up of 2 requests, the header and the content.
That would be extremely rare, since the timeout would have to occur right between the 2 requests.
But the web page content would be all wrong, so you'd know about that happening.
The timeout itself can mean everyone for up to about 30 seconds or so after it may show timeout messages with nothing else, but not pages with out of date information.

[rifleman74]

Just made is to Disney World for the weekend. On my way to a meeting with the 7 dwarfs. Going to get this mining issue resolved. Heard they know how to crack blocks.

Multiple blocks preferable!

[fjtropepe]

Good news. They are going to talk to the block gods for us. Standby gents.

[rifleman74]

Good, because we're down 5PH now.   
It's not all canaan's miners moving off. 

[sevilnatas]

How do I get verified? I looked through my email and don't see anything to reply too.

[kano]

How do I get verified? I looked through my email and don't see anything to reply too.

Account->Verify

Edit: if you have already requested it to send the verification email then either:
1) Check your spam folder and make sure kano.is is white listed
or
2) Check you didn't get your email address wrong

Edit2: and if you send a 2nd key, coz the first one hadn't arrived yet, the first one will no longer be valid, you'll have to make sure it's the 2nd one that you use.
The email also says when you requested it to be sent, so you can match that up.

N.B. most of the time when I see the key validation messages on the console they are about 1 minute after the key was sent,
i.e. the server is quick to send out the message, so if you don't see the message for 10/15/30 minutes, it's your email provider that's slow.

[smutboy420]

just a ? and maybe a sort of a heads up to kano in case it is an issue that you are not aware of..      

for the last 2 weeks I happened to notice that any time a block is found on the network and then the pool starts working on a new block. I have noticed the time it takes for the pool to start on the new work is some times as much as 5 mins behind.

for instance block number 499476 found by slushpool at 2017-12-15 13:31  and then they instantly started working on block 499477 and working on it for almost 5 mins before the time kano pool switched and started the new work on trying to work on block 499477

sometimes its only about 15-20 seconds difference that the pool takes to switch on to a new block and get to work and figured that was just normal time its taking for other pools to switch work after another pool finds a block..    But over 4 mins seems like a real long relay time.  

so incase that is longer then it should take I figured I would say something to let you know so if it is a problem you could see what the cause might be.   Tho if not then I guess its no biggie and you would know its not any thing that could cause any issue with the pool missing out on the big race to find a block before any other pool ever did.  

I had noticed the same thing. Kano assured me that the Pool immediately goes to work on the new work for the new block. No delays. He would know since he has the tools to monitor the hash on each block. He explained to me that many Internet providers use proxies for websites and they are not always updated properly. I pushed the I believe button because he would know since he is monitoring the back end. Now with that said... timing in this game is everything. Ensure that you mine to the fastest ping Pool node for your location. In my case, it is the NYA with a 14ms ping.

MINE ON!!! KANO-SAN has got our back!!

True I know if there is anyone thats can be trusted to even know what he's talking about as far as how things work its Kano. and if something was anything that could cause problems with the pool or cause it to have worse luck hitting blocks it would be in his interest and every one mining to find and fix and bugs or issues that were found if there was a problem with anything.

and glad to know that delay in the time shown from the time new work started on block and new work is not a real problem. Tho now that I thing about it some more and knowing how the info pages are also on a different server than the actual pool its self I can see how it would have to lag behind a bit on what ever data that needs to go from one place to another to be displayed.

So going through the logs for that specific block:

499476
000000000000000000a90fdd34d539c9a25a56355a245708ff855f9e3245e98b

Pool log:
[2017-12-15 18:31:22.912+00] Block hash changed to 000000000000000000a90fdd34d539c9a25a56355a245708ff855f9e3245e98b

Mining monitor - when it saw the block change.
It's in the USA and connects to every mining node (not in china) no some may take a fraction of a second longer,
The last one (pool 1) is in singapore and I guess the connection from the USA to there and back to the USA was a little slow for that one
But the times there show when the work change, sent from the main server, arrived at the monitor, after going via the node.
 [2017-12-15 18:31:22.953] Stratum from pool 10 detected new block at height 499476
 [2017-12-15 18:31:22.956] Stratum from pool 0 requested work restart
 [2017-12-15 18:31:22.960] Stratum from pool 11 requested work restart
 [2017-12-15 18:31:22.963] Stratum from pool 7 requested work restart
 [2017-12-15 18:31:23.004] Stratum from pool 4 requested work restart
 [2017-12-15 18:31:23.012] Stratum from pool 8 requested work restart
 [2017-12-15 18:31:23.012] Stratum from pool 6 requested work restart
 [2017-12-15 18:31:23.045] Stratum from pool 9 requested work restart
 [2017-12-15 18:31:23.220] Stratum from pool 2 requested work restart
 [2017-12-15 18:31:23.238] Stratum from pool 5 requested work restart
 [2017-12-15 18:31:23.376] Stratum from pool 3 requested work restart
 [2017-12-15 18:31:25.727] Stratum from pool 1 requested work restart

So basically it's all OK for that block, so I'm not sure what the cause was for you seeing it minutes later.
Also note that the web site shows the time in the bottom left and right in tiny letters - check what it says there also next time you see this.
The left is the web server UTC and the right is what your browser thinks the current time is.
i.e. you may be seeing a cached copy of the web site and it would show the server time in the past.

The web server itself doesn't use any caching or cloudflare or anything like that since firstly, cloudflare is a security risk (you have to give them your SSL certificate and thus trust every employee of every company that has access to their servers) and secondly, the code/server is configured to handle the load pretty well without the need for that.
i.e. the web server doesn't take minutes to send you the data, it's immediate, and the data it uses is immediate.
The timeouts that sometimes occur, might cause a delay since the web page is made up of 2 requests, the header and the content.
That would be extremely rare, since the timeout would have to occur right between the 2 requests.
But the web page content would be all wrong, so you'd know about that happening.
The timeout itself can mean everyone for up to about 30 seconds or so after it may show timeout messages with nothing else, but not pages with out of date information.

Cool beans kano.  looking at the time pool 10 detected a new block  "[2017-12-15 18:31:22.953] Stratum from pool 10 detected new block at height 499476"   with the time that slush pool finised the block 499476 and got it relayed in was at 18:31:17  so its looking like it only tool a few millseconds less then 6 seconds for the pool to be geting cracking on new work. from the time slush got the block before that relayed in.   Thats seem pretty darn quick.      but if I happen to be looking at the right moments again and notice any big discrepancies in the time displayed on the top of the kanopool page I will try to take note of how much the time is off if I happen to notice again.   

 

[kano]

...
Cool beans kano.  looking at the time pool 10 detected a new block  "[2017-12-15 18:31:22.953] Stratum from pool 10 detected new block at height 499476"   with the time that slush pool finised the block 499476 and got it relayed in was at 18:31:17  so its looking like it only tool a few millseconds less then 6 seconds for the pool to be geting cracking on new work. from the time slush got the block before that relayed in.   Thats seem pretty darn quick.      but if I happen to be looking at the right moments again and notice any big discrepancies in the time displayed on the top of the kanopool page I will try to take note of how much the time is off if I happen to notice again.   

No, 6 seconds is WAY too slow.

But I suspect you are misreading that time.
The time in the block is not when it was found.
Block 499476 has a date stamp of "2017-12-15 18:31:17" which is the (somewhat random) time put in the block header, not the time the block was found, and certainly not the time that pool processed the block.

If it was, then that would mean that slush is slow to distribute their blocks.

All our node's bitcoinds processed the block during the second of "2017-12-15 18:31:22"

[smutboy420]

...
Cool beans kano.  looking at the time pool 10 detected a new block  "[2017-12-15 18:31:22.953] Stratum from pool 10 detected new block at height 499476"   with the time that slush pool finised the block 499476 and got it relayed in was at 18:31:17  so its looking like it only tool a few millseconds less then 6 seconds for the pool to be geting cracking on new work. from the time slush got the block before that relayed in.   Thats seem pretty darn quick.      but if I happen to be looking at the right moments again and notice any big discrepancies in the time displayed on the top of the kanopool page I will try to take note of how much the time is off if I happen to notice again.   

No, 6 seconds is WAY too slow.

But I suspect you are misreading that time.
The time in the block is not when it was found.
Block 499476 has a date stamp of "2017-12-15 18:31:17" which is the (somewhat random) time put in the block header, not the time the block was found, and certainly not the time that pool processed the block.

If it was, then that would mean that slush is slow to distribute their blocks.

All our node's bitcoinds processed the block during the second of "2017-12-15 18:31:22"

That very well could be that slush is slow. They have been going threw some sort of DDoS attack for about the last week or so more then even normal.  and there page some times wont refresh or will pop up with a Cloudflare notice quite a lot. 

But for what is worth they hit another block about 20 mins ago and I happened to notice it when they were about 12 mins in to the next block and kanopool info was showing it being 2 mins in to the next block and so I put the 2 pages next to each other and hit refresh on kano and then I took a screen shot for you so you can see what I mean.   and got it just in the nick of time because only a few seconds later someone some were found that block and then it was on to the next one when I refreshed the kano page again.

 

[kano]

...
Cool beans kano.  looking at the time pool 10 detected a new block  "[2017-12-15 18:31:22.953] Stratum from pool 10 detected new block at height 499476"   with the time that slush pool finised the block 499476 and got it relayed in was at 18:31:17  so its looking like it only tool a few millseconds less then 6 seconds for the pool to be geting cracking on new work. from the time slush got the block before that relayed in.   Thats seem pretty darn quick.      but if I happen to be looking at the right moments again and notice any big discrepancies in the time displayed on the top of the kanopool page I will try to take note of how much the time is off if I happen to notice again.    

No, 6 seconds is WAY too slow.

But I suspect you are misreading that time.
The time in the block is not when it was found.
Block 499476 has a date stamp of "2017-12-15 18:31:17" which is the (somewhat random) time put in the block header, not the time the block was found, and certainly not the time that pool processed the block.

If it was, then that would mean that slush is slow to distribute their blocks.

All our node's bitcoinds processed the block during the second of "2017-12-15 18:31:22"

That very well could be that slush is slow. They have been going threw some sort of DDoS attack for about the last week or so more then even normal.  and there page some times wont refresh or will pop up with a Cloudflare notice quite a lot.  

But for what is worth they hit another block about 20 mins ago and I happened to notice it when they were about 12 mins in to the next block and kanopool info was showing it being 2 mins in to the next block and so I put the 2 pages next to each other and hit refresh on kano and then I took a screen shot for you so you can see what I mean.   and got it just in the nick of time because only a few seconds later someone some were found that block and then it was on to the next one when I refreshed the kano page again.

http://i65.tinypic.com/2lwt834.jpg

Well I don't know what is causing that for you - but again you'd need to check the UTC time in the bottom left and make sure your ISP or connection isn't caching old data.

We found 498508 at 2017‑12‑10 03:39:29
Add 143hrs and 14m gives 2017‑12‑16 02:53:29 - so the time you got that page would be around 02:53:29 give or take a minute due to the "143hrs and 14m" rounding.

That's 3 mins and 20 seconds after block 409532 plus or minus a minute.
Network there says 2:51 since last block which fits into 3:20 + or - a minute.

So your web page matches what you would expect to see at about 2017‑12‑16 02:53:29 (plus or minus a minute)

[smutboy420]

UTC time in the bottom left seems all good when I refresh kano page. and then click up my clock your time shown is only about 1-2 seconds from the time on my clock in windows which is about how long it takes me to bring my clock back up to see my clock.

But whatever the difference is.  That was causeing slush to show it was 12:16 in to block 449532  and kanopool showing 2m 51s in to 449532   was what seemed pretty far off with it only takeing a few seconds to hit the screen capture button to take the screen shot.


 Tho you know all the under the hood and in and out or all this pool stuff so if its all good from your view thats good enough for me.  esp being I know you actually looked and didn't just do what some pool ops would do if they didn't even understand they even had a problem if anyone was pointing out something that was actually wrong.  or take days or even to weeks to reply back to a support ticket.  You are a true Johny on the spot when it comes to support or ?s on the forum. 

   

[smutboy420]

ha ha now just seen another block was started on by slush and this time the times are nuts on almost to the second

With you showing  Network: 4m 40s (499538)  when I hit refresh and slush was showing they were 4m 41s in to block 499538   and being it takes about .5 to 1 second or so to refresh the full page that would be pretty close to exact same time sync.   

[rifleman74]

Alright, enough's enough.  Time for a block.   Luck luck luck

[1manshow]

Can someone let me know how do I set different location pool information in secondary and tertiary pool information on Antminer S9? All I can find on main page of Kano website is stratum+tcp://stratum.kano.is:3333 and port variations. Or you people set any other pool information in those second and third pool info? Sorry for my bad English.

[xuy]

Does anyone know how much BTC for each THs/Day?

[Waztim]

Does anyone know how much BTC for each THs/Day?

Go here, http://tradebtc.net/bitcalc.php

Edit: To reach these expected payouts, you must reach 5ND. Hope this helps and welcome to the Best Bitcoin Pool, KANO POOL!!