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

[AndyM456]

"Anyway, the Android app, I did just try install and fire it up on a tablet and it worked - the version that says '(Kano)' on the end.

So my only guess would be that whatever is causing the Discord problem may be causing the App problem?"

Tried an old Phone (Huawei P20 Pro) and the app still works fine, new one I have had for about 3 months (One Plus did work fine but now app crashes (in last 2 weeks) as soon as trying to open it so guess the app does not like something in the Oxygen OS.
Will use an old Android phone for now to run app :-)
Will try and join you on Discord some other time (not that I have ever needed help in the past as the KanoPool just works :-)
All the best

[1713490708]

1713490708

[1713490708]

1713490708

[1713490708]

1713490708

[VRobb]

Any ETA as to when the Solo option will be available?  My winter-time Artoo unit (R4 with only half brains!) is ready to burn some watts.

[kano]

KDB upgrade will be today for the rest of the solo code.

Most of it is already live but I ended up writing a testing program to simplify comparing shift data in the database against shift data in the share log files.
Previously I'd do manual checks and balances to make sure things were OK, but with this solo change I've made a lot of changes in the code involved in processing shifts (internally called the markersummary table), so for the final step (over the last week or so) I've written a completely separate program to do the full shift process of a range of log files to compare against the database.

This will of course also simplify future change tests, like the blocksummary code mentioned before, that is in the live code but never enabled, that is one of the next updates that I'll do.

Solo will be switched on soon after the update.

Edit: you can now switch a new account to solo.
See Help->Solo first.
You'll get an Accounts->Solo menu item when you login to a new account, if your account is within the time limit.

[NotFuzzyWarm]

Kano's Solo is now live and working perfectly. I've said 'you're fired!' to the -ck solo.

Main restriction is that you MUST either use OEM firmware or BoS (Braiins) and yes running Sidehacks miners with vh's firmware is fine. Aside from BoS (which is a clean re-write of cgminer), any miners using 3rd party firmware are automajikly disconnected because of cgminer GPL license violation. While there has yet to be any verifiable proof that BoS finds blocks, being allowed only on solo presents zero risk to the main pool. Adder to that - IF someone using BoS does find a solo block here then BoS will also be allowed on the main PPLNS pool.

For those wanting to use it:
1. Register to create new account & verify using the code that will be emailed to you - you cannot directly mine to just a BTC address
2. Use a new payout address
3. Select Solo
4. Only then using the new Solo worker name point the solo miners @ any of the normal pool addresses & fire them up.
For further info refer to https://kano.is/index.php?k=soloinfo

Key points are that it must be a new account and the payout address cannot have been used before with Kanopool. Very nice to finally have a solo that is ran by someone who knows how to correctly code and more importantly - thoroughly TESTS their code along with logging everything that goes on...

edit: I should also add that rentals are allowed on the Solo accounts. Reason of course is that the Renter bears all risks regarding how the rental hash performs and not the main pool.

[o_solo_miner]

Kano's Solo is now live and working perfectly. I've said 'you're fired!' to the -ck solo.
Main restriction is that you MUST either use OEM firmware or BoS (Braiins). Aside from BoS miners using all 3rd party firmware are automajikly disconnected because of GPL license violation. While there has yet to be any verifiable proof that BoS finds blocks, being allowed only on solo presents zero risk to the main pool. Adder to that - IF someone using Bos does find a solo block then BoS will also be allowed on the main PPLNS pool.

For those wanting to use it:
1. Register to create new account & verify - you cannot directly mine to just a BTC address
2. Use a new payout address
3. Select Solo
4. Only then point the solo miners @ the pool & fire them up

Key points are that it must be a new account and the payout address cannot have been used before with Kanopool. Very nice to finally have a solo that is ran by someone who knows how to correctly code and more importantly - TESTS their code along with logging everything that goes on...

Well, that is nice to hear, but until the Kano solo pool did not find the first block, I would not say "it is working perfect". I would wait for at minimum the first block is mined.

Anyway, I wish all good luck on mining.

[NotFuzzyWarm]

but until the Kano solo pool did not find the first block, I would not say "it is working perfect".

Very true. However the most important parts of it uses the main pools code. Solo is more of an accounting thing and following discussions the past few months on Discord we know that the code has been extensively tested, a few bugs found and squashed then tested more before it went live. Unlike code from a certain anesthesiologist and hobbyist coder, Kano is a professional programmer with degree in Computer Science who's only job is being a programmer/pool operator. That gives me far greater confidence in what he codes.

Another bonus is that with two full nodes which are not based in the US including one behind the GFW there is no need to use a pass-thru service if your country blocks access to US servers.

edit: I should add that it supports multisig and sub-accounts refer to https://kano.is/index.php?k=soloinfo

[philipma1957]

good luck i wonder whom hits the first solo block

[kano]

Kano's Solo is now live and working perfectly. I've said 'you're fired!' to the -ck solo.
...

Well, that is nice to hear, but until the Kano solo pool did not find the first block, I would not say "it is working perfect". I would wait for at minimum the first block is mined.

Anyway, I wish all good luck on mining.

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://bitcointalk.org/index.php?topic=790323.msg43911218#msg43911218
 ... and my follow up about some bugs in the code you are using:
https://bitcointalk.org/index.php?topic=790323.msg44101418#msg44101418
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?

[o_solo_miner]

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://bitcointalk.org/index.php?topic=790323.msg43911218#msg43911218

 ... and my follow up about some bugs in the code you are using:

https://bitcointalk.org/index.php?topic=790323.msg44101418#msg44101418

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?

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.

[kano]

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.

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?

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.
...

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

[o_solo_miner]

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

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

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

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.

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

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

[kano]

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

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

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.

[o_solo_miner]

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.

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

Code:

from passthrough (DECIX) to solo4.ckpool.org
64 bytes from solo4.ckpool.org (51.81.56.15): icmp_req=6 ttl=53 time=86.4 ms
from my Home to solo4.ckpool.org
64 bytes from solo4.ckpool.org (51.81.56.15): icmp_seq=6 ttl=53 time=127 ms
from Home to passthrough
64 bytes from v38928.1blu.de (178.254.35.104): icmp_seq=3 ttl=56 time=27.0 ms

so It depends on your specific internet connection.

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)

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:

Code:

home to kano.is
64 bytes from 45.77.7.149.vultr.com (45.77.7.149): icmp_seq=2 ttl=57 time=188 ms
home to decix
64 bytes from v38928.1blu.de (178.254.35.104): icmp_seq=3 ttl=56 time=27.0 ms
decix to kano.is
64 bytes from 45.77.7.149.vultr.com (45.77.7.149): icmp_req=1 ttl=57 time=148 ms

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)

[kano]

...
Edit:
I was a bit shocked that my home internet is that bad, so I tested kano.is as well:

Code:

home to kano.is
64 bytes from 45.77.7.149.vultr.com (45.77.7.149): icmp_seq=2 ttl=57 time=188 ms
home to decix
64 bytes from v38928.1blu.de (178.254.35.104): icmp_seq=3 ttl=56 time=27.0 ms
decix to kano.is
64 bytes from 45.77.7.149.vultr.com (45.77.7.149): icmp_req=1 ttl=57 time=148 ms

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)

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.

[o_solo_miner]

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.

done that:

Code:

nl.kano.is from home
at worst
64 bytes from 45.76.32.61.vultr.com (45.76.32.61): icmp_seq=17 ttl=56 time=95.7 ms
at best
64 bytes from 45.76.32.61.vultr.com (45.76.32.61): icmp_seq=25 ttl=56 time=35.4 ms

nl.kano.is from decix
64 bytes from 45.76.32.61.vultr.com (45.76.32.61): icmp_req=15 ttl=56 time=7.96 ms (only 7 hops! in total)

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.

[kano]

...
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.

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.

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.

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.

[o_solo_miner]

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

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.

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

Actually that's not the second, there have been more.

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

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.

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.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.

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.

[xuy]

Hello Mr Kano,

Are you still working on it? Thanks.

Kano will hold your BTC if you don't provide an address, like he did for others in the past. He said he would send out 'dust' and held BTC by the end of this year.
Once dust is not dust any more

One thing I don't get about people who want to go to Antpoo, if you get a daily payout, won't you also pay $10 or more in transaction fees to get your payout? I actually would prefer the opposite. I would want a pool to allow you to keep your balance as long as you want until you think it is worth $10 to get your payout. Or am I not understanding how BTC transaction fees work?

I am not sure if Antpool allows for this by simply not  supplying a wallet address.

Btw, what happens here at Kano if you do not have a wallet address added? I somehow doubt your balance will be held for you. Not sure though.

Yeah still working on it - that's basically what I'm spending almost all my coding time on at the moment - will be early next year.

Got sidetracked with the October bad luck, where I ended up adding full share hashing and verification to KanoDB for all shares submitted, and also added block submission to KanoDB for all blocks found.
All that new code is 100% original by me to ensure it's a complete independent verification of the pool results - and of course will pick up any bugs/memory corruption if that ever happens in the pool code.

I'm sure anyone who has been waiting for 6 months or more for their dust will be glad they didn't get it and spend it back then

[kano]

Hello Mr Kano,

Are you still working on it? Thanks.

...
I'm sure anyone who has been waiting for 6 months or more for their dust will be glad they didn't get it and spend it back then

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

[o_solo_miner]

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.