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

On the login/register page (link at top right) use the "Password reset" at the bottom.

Enter your username and email address you registered with, and if you get them right it will send you an email to change your password.
If you have 2FA enabled, you must also get that correct.
Your username will be in your miner.

I don't (and the system doesn't) know your password, only a multiply hashed version of it with some random data.

Kano, How can I retrieve my login password?

That said, Here Blocky! Here Blocky!

Is it me or are we overdue for a block???

Master Server Upgrade

There will be a mining outage, 24 hours from now, for all miners, at UTC 04:59 07-Dec
for at least 10 minutes and for a maximum of 30 minutes.

The server will be upgraded.
The new server is a Dual: 2nd Gen Xeon Gold 6230R 26 Core (total 104 threads) 128GB
as many know, the current one is a Dual: Xeon Gold 5118 12 Core (total 48 threads) 96GB
Also, system/db/bitcoin disk going from 480G raid1 ssd to 1T roc raid1 nvme

While the upgrade isn't at all necessary for performance - KDB uses about 16GB RAM but about 1/3 the CPU of the pool code
The same provider has the new server for less than the old one - so definitely worth doing
This also simplifies upgrading software also: Linux, Bitcoin and the pool code that doesn't work with bitcoin 0.20

Come visit Discord if you have any questions.

Mine on!

-----------------

Edit: as mentioned in Discord - all went ok - all up and running.
Took a bit over 20 minutes.

how many has comissions pool?

Well when you make a post that includes incorrect statements and is generally being critical of things you don't fully understand, yep I'll delete it.

While there are those on the forum who 'think' they are bitcoin experts and thus make claims about how the experts are wrong, because someone on youtube told them something that must be right coz youtube said so - trying to tell me that I don't know what I'm doing will not get you anywhere in this thread.

Feel free to ask questions about things you don't know or don't understand, but critical arm chair experts are likely to have their posts deleted.

I do find this rather hypocritical of some people who post in this area of the forum and claim how they don't like my attitude and that I should bow down to them and say 'Yes sir what do you want?' after they attack what I'm doing or make ignorant arguments against what I do know.
Nope I don't do that. Money does not drive me to beg and grovel for it, unlike a lot of people.
There's no point telling an expert that you know better than they do and the expert should grovel for your approval.

Edit: and since your sig is just one very big advert for that pool and their firmware you like that charges miners to use it by pool swapping - I've removed the post. Your full post is quoted above in this one

After testing the ckpool passthrough in proxy mode, and 10 found blocks where
corectly tranfered to the main pool, I consider that as save.

Now I will test the ckpassthrough in node mode and I let you know the result.

Yeah still doing code changes - PPS for a few of the top miners.
After that I'll work on sending dust.

Hello Mr Kano,

Are you still working on it? Thanks.

I don't biasing any result. And I don't know why I should.
This was the result from home vs. beeing logged into the server on the decix and do the same test.
You can clearly see that the connection to your Amsterdam Node is ultra fast.
Amsterdam is directly peered with Frankfurt, you can see that using mtr.
It was not posted to make the passthrough look better, it was posted to show my situation from home.
My home provider do not use the shortest way possible, for price I guess, peering cost money.
I noticed that during the test.

I don't get what you want to say, that was the second block found by my miner during the test.

That's the point, I will test that and report the result I found.
If the  software fails, I won't use it as I don't want to put people on risk.

I ignore nothing, I simply did a passthrough in proxy mode with all disadvantage it brings with it.
And yes, setting it up as Node is much better and you point me to that, thank you.

I don't think you understand ping.
It's not a one off what random worst value did you get ... vs what is the best value you got from doing something else to make that seem better when it won't be.

Every packet you send goes out your network and has the issue of your home provider, no matter where it goes.
So if you have a crap provider at home, you can't avoid that without moving your miners somewhere else or using a closer block submitting node.
Networks also tend to give ping packets low priority, so they wont be absolute.
Anyway, this ping you are doing is a waste of time, you aren't even showing your results properly, and are biasing them to try and make your decix server, routing via somewhere else, sound like a good idea, which is isn't. It also has to be processed buy that server, i.e a stop in the middle of the network process, before it then sends the packets out though some of the network it has already traveled.

Don't bother posting any more pings, you're purposefully biasing the results.

Actually that's not the second, there have been more.
But anyway, it's not using the -N pasthru which is the whole point of using passthu so that your shares are validated and submitted as a block, which in your case you claim to be 27ms vs your current unreliable solo pool operator that's lost 5 or 6 blocks due to negligence, which you stated is 113ms - 127ms
(but I doubt those numbers are accurate either)
i.e. if you set it up as you should, and not ignore the major advantage of using a block submitting node, you'd be better off by amost 100ms ... if your ping values were correct.

done that:

from home 35.4 ms - 95.7 ms
over decix 27 ms + 7,69 ms = 34,69ms
not to bad from home, but more reliable and constant over the decix.

And a second block was found: 1891851 Version 0x20800000
https://tbtc.bitaps.com/1891851

When 10 blocks are reached I try the -N passthrough, but with my 3 TH it will take a while.

There's no point pinging the web server in silicon valley.
It doesn't accept mining.

You ping the node closest to you - there's a bunch of them listed on the home page: https://kano.is
From your post I'd guess it would be nl.kano.is
It's two servers with two different providers, so you may get slightly different results each time you try.
And yes it submits blocks directly to the bitcoin network from there when your share gets to the node.

Yes, it may add an extra delay, but that passthrough is intend to enable people to
connect to the pool that otherwise would not be able to connect due to the restriction
of the american provider.

For example if I use my home internet connection it is faster to connect over the passthrough.
Ping time from home to pool 127 ms
Ping time from home via passthrough 86,4 ms + 27 ms = 113,4 ms
so It depends on your specific internet connection.

when I finished testing the -P passthrough, I will also test the -N and report the result, as this would be the better choice if that works ok.


Edit:
I was a bit shocked that my home internet is that bad, so I tested kano.is as well:
total via decix:27 ms + 148ms = 175ms
direct 188 ms
the result is the same, over the decix it is faster.
(using mtr displays the cause, my home provider routes using more hops)

Hmm - then that defeats the purpose of using a passthru though.
Your passthru is also adding latency to any blocks found - which can be noticeable if the passthru is far from the pool.

When you use -N it submits the block to the bitcoin network locally, at the passthru node, as soon as the share gets to the node.
(though the code has the mask wrong)

In your case (not -N) you have to include the extra wait for the share to get passed by your passthru back to wherever in the world the pool is.

No, I used the -P switch, there is a bitcoind present but I did not try -N


that was in 2018, I am not the person who can answer you that question.
But you are right by pushing me to test it, if I offer that service, and I take that very seriously.


Well, yes, my fault, I was just reporting after it found the block without checking the version.

That's not an AB block - it's block version is 0x20000000

The passthru also is supposed to submit blocks itself, is that how you have it setup?

Well as he stated in the ckpool thread - he doesn't test it ... so how does he know it works?

Thank you for dipping my nose on it.
I was not aware of that, 2018 I was not looking after the passthrough function of ckpool.
I use the latest version from cks repository and we talked about using it on irc, I had no trouble with it
so far, and I did not get a negative response from eigther ck or the user.

To not putting someone on risk, I will now remove the passthrough and test with my S9 and a local testnet.
As soon as I know what the results are, I let you know.

So again thanks for your warning.

EDIT:
My test run a couple of hours now, and it found the first block using the latest source of ckpool from bitbucket.
The miner (S9 with AB) is connected over a second instance of ckpool in passthrough mode.
Proof:  https://tbtc.bitaps.com/1891742

I will let that run for a few days, and if that runs flowlessly I would consider that safe to go back online.
I keep you informed.

First and foremost: it's not a separate pool. The pool front end hasn't changed for this.
It's the same pool everyone mines on, that's so far found 2432 blocks.
KDB also submits the blocks with the correct exact check, and has been doing that for a couple of years, rather than the approximate check the pool code does.

The solo changes are how KDB accounts for shares and rewards miners.

Also, I have 'mined' over 250 low difficulty blocks of both PPLNS and Solo through the new KDB code on my test server
Tested reasonably well from beginning to end.
That's of course, not a full block validation test, but block validation hasn't changed at all, it has nothing to do with the solo update.

HOWEVER I'm not sure why -ck hasn't told you to shut down your solo passthru you run on his pool.
The code isn't supported (I've had to fix bugs in it) and it DOESN'T handle AB blocks properly.
You don't have to believe me, read what he said here:
https://bitcointalksearch.org/topic/m.43911218
 ... and my follow up about some bugs in the code you are using:
https://bitcointalksearch.org/topic/m.44101418
He's never put an AB block test through the passthru code, otherwise he'd see it doesn't work.
That's how I found the bug, back when I was testing it properly, BEFORE I implemented AB on KanoPool.
You posted a lot in that thread also. Any special reason why you ignored my post and are getting people to mine through that buggy code you are running?