Author

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

newbie
Activity: 23
Merit: 0
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.
I think I see the confusion... the UI in your left screenshot is showing the time into their pool round, not the time into a network block. If you look at the table to the right of the 12 minutes in your screenshot, it shows Slush found a block 11 minutes before, which triggered a new round. Back when it was a much smaller pool, that round timer would show 2, 4, even 12 hours until a pool block was found (I use them as backup). So the timer doesn't have anything to do with the current network block listed below it. I can confirm that the last network block time on kano's website almost always matches up when I'm logged in there and happen to check against another site like btc or tradeblock... or my bitcoin node :-)
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
Logins to the web site are currently disabled due to someone sending a lot of fake login attempts (from lots of different IP addresses)
The logins don't really cause a problem, but better to disable them for a while, just in case someone has an easy password and the 'hacker' guesses it ...
newbie
Activity: 68
Merit: 0
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.
Ports don't matter unless you are having trouble with port 3333 due to your miners.
Sometimes internet providers block ports and can cause problems like that but I doubt they'd block 3333
However, some people find that only certain ports work and everything else is blocked, so you can use the other ports in that case, and usually 80 should be fine.

Anyway, your setup would depend on where you are, to decide which should be first.

Normally you'd use stratum+tcp://stratum.kano.is:3333 first if you are in the USA on the west coast of central USA
If you are on the east cost or north east canada, then you'd use stratum+tcp://nya.kano.is:3333

If you are in Europe you'd use either stratum+tcp://de.kano.is:3333 or stratum+tcp://nl.kano.is:3333

From the asia area you'd use either stratum+tcp://jp.kano.is:3333 or stratum+tcp://sg.kano.is:3333

Second would be the next nearest node, or if you use stratum+tcp://stratum.kano.is:3333 first then 2nd would be stratum+tcp://nya.kano.is:3333

For third, I'd suggest you use a PPS pool as I mentioned recently.
https://bitcointalksearch.org/topic/m.26349919

-------

Thank you very much for your detailed explanation mate. Glad to be part of your awesome pool and the level of support from you directly is exhilarating. Mine on!
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
Been having more problems again over the last hour with the Silicon Valley half of stratum.kano.is
Seems another low level DDoS of the providers servers.
As long as you have a backup node then it should have little effect on you since the rest of the nodes are all ok.
Most users will automatically switch to the LA half of stratum.kano.is and that's all OK, but that's random due to the DNS round-robin so some will still be trying to connect to the Silicon Valley half.
Still awaiting an "it's OK now" reply for the provider.
Well no more disconnects since before I made the above post, so it seems all OK again now.
No reply from the provider though Tongue
Maybe they don't like that I monitor and see the network problems before they even notice them ...
Anyway, all good, mine on.
member
Activity: 210
Merit: 15
And the Block goes on, and the Block goes on. Let's crack this Puppy. A Ham Sammich has now been offered unto the Block so that it may look down upon us and have mercy upon our purring miners and reward us with what we have so dutifully worked for. I hope its like Ham, cause that's all I got, after that we may have to go to Chicken Flavored Ramen Cup O Noodles. LOL

We have only just begun to mine!!

The only thing to fear is fear itself!!

The Block Stops here!!

Make This Block Great Again!!

Lock this Block Up!!

Mine On!!
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
Been having more problems again over the last hour with the Silicon Valley half of stratum.kano.is
Seems another low level DDoS of the providers servers.
As long as you have a backup node then it should have little effect on you since the rest of the nodes are all ok.
Most users will automatically switch to the LA half of stratum.kano.is and that's all OK, but that's random due to the DNS round-robin so some will still be trying to connect to the Silicon Valley half.
Still awaiting an "it's OK now" reply for the provider.
newbie
Activity: 53
Merit: 0
Ok...something like this worked about a year or so ago, so let me try again:

Hickory dickory dock
We really need a block
Two, not one, would be more fun
Hickory, dickory BLOCK!

Mine on!  Grin

+1!

Mine hard, mine on!
sr. member
Activity: 276
Merit: 250
Ok...something like this worked about a year or so ago, so let me try again:

Hickory dickory dock
We really need a block
Two, not one, would be more fun
Hickory, dickory BLOCK!

Mine on!  Grin
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
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.
Ports don't matter unless you are having trouble with port 3333 due to your miners.
Sometimes internet providers block ports and can cause problems like that but I doubt they'd block 3333
However, some people find that only certain ports work and everything else is blocked, so you can use the other ports in that case, and usually 80 should be fine.

Anyway, your setup would depend on where you are, to decide which should be first.

Normally you'd use stratum+tcp://stratum.kano.is:3333 first if you are in the USA on the west coast of central USA
If you are on the east cost or north east canada, then you'd use stratum+tcp://nya.kano.is:3333

If you are in Europe you'd use either stratum+tcp://de.kano.is:3333 or stratum+tcp://nl.kano.is:3333

From the asia area you'd use either stratum+tcp://jp.kano.is:3333 or stratum+tcp://sg.kano.is:3333

Second would be the next nearest node, or if you use stratum+tcp://stratum.kano.is:3333 first then 2nd would be stratum+tcp://nya.kano.is:3333

For third, I'd suggest you use a PPS pool as I mentioned recently.
https://bitcointalksearch.org/topic/m.26349919

-------

An aside that some may not know:

If you have a petahash or more on west USA, I can setup so you can access a node there that is white listed for large miners only Smiley

Of course anyone with more than a petahash always mining at the pool, I'll try setup a node near them if they want, of course that depends on where they are, but I don't mind setting up a white listed node for anyone with that or more hash rate.
These nodes only allow data from the pool, from me and of course the miners who are white listed, they completely ignore other data.
(Edit: oh they also of course have a bitcoin node running on them Tongue)

PM me if you want that and have more than a petahash that will stay on the pool.

-------

Edit: also another thing that few may know about, that I've had on the pool for years now, is that large miners can divide their payouts up to multiple addresses if they request it.
There's a different address management page that I can enable for an account, that allows you to enter multiple addresses (up to whatever limit I set) and you also specify the ratio of the reward that each address gets.

So e.g. you could send 10% to one address and 90% to another etc.

Again PM me if you need this Smiley

The cloud mining changes will allow more control over this, but I've left those changes incomplete for now since no one mining on the pool has enough hash rate for that, so completing those changes got down graded in the TODO list to: 'who knows when if ever'
The main part of that change was actually a change in account control that is live already.
Most will have noticed this with the 'Verify' option on your account - this is just one part of the account control I added where I can set various options on accounts (including saying they are cloud master and cloud accounts) and the web and KanoDB treat each differently with different web pages and different access control.
The part missing for cloud mining is mainly just the new web pages and a table to store the cloud settings.
member
Activity: 210
Merit: 15
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!!
xuy
member
Activity: 92
Merit: 10
Does anyone know how much BTC for each THs/Day?
newbie
Activity: 68
Merit: 0
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.
member
Activity: 658
Merit: 21
4 s9's 2 821's
Alright, enough's enough.  Time for a block.   Luck luck luck
full member
Activity: 341
Merit: 100
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.   Grin

full member
Activity: 341
Merit: 100
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. 

   
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
...
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)
full member
Activity: 341
Merit: 100
...
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.

 



legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
...
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"

full member
Activity: 341
Merit: 100
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 Tongue
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.   

 
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
How do I get verified? I looked through my email and don't see anything to reply too.
Account->Verify Smiley

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.
Jump to: