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

[bit2255]

Thanks - I am waiting a little bit longer to buy more BTC from coinbase (a little more of a price drop). If I can take advantage of this or similar offer, I just might do it sooner.

Can't wait to see you PM

Thanks

[1714040682]

1714040682

[1714040682]

1714040682

[1714040682]

1714040682

[kano]

There will be a CKDB restart around 06:30 UTC
The exact time will be when the next shift completes - but should be close to 06:30

No mining will be affected.

The web site/API will be unavailable for 10 to 15 minutes.

However
This is a major update for my CKDB code so I've setup a way to quickly roll it all back in the event of problems running the new code live.
Hopefully that wont be necessary, since I've done pretty extensive testing of the new code, running 3 weeks of data (about 3 billion shares) through it a number of times ... until all shift, share, reward, payout and payout transaction generation produced the exact same results as the live running system.
A rollback will just mean another restart of CKDB - but again it's not expected, but setup to ensure minimal downtime in the event of a problem running live.
I've modified about 20% of the CKDB code, to deal with the key change of most of the main data.

... mine on

Restart completed OK and still running OK ... touch wood
Restart was from 06:39 UTC to 06:46 UTC - 7 minutes.

Some TL;DR; for anyone interested in what's changed and why.

In my original implementation of the pool, the code always assumed that a workinfoid was always increasing over time.
The workinfoid is the identifier for each work base used to generate work for all the miners, that gets updated every 30 seconds and every network block change.
This is the case when running one controlling pool instance, however to run more than one instance requires relaxing that assumption.

The first step in that process is to change the key of all the data, and all code accessing that data, to include the block height in front of the workinfoid.
That's part of what this code change has done in all ram tables, pgsql tables, and all functions/code that access anything using workinfoid.

The old code summarises shares as follows:
Each incoming share goes into a sharesummary - that summarises all shares per worker, for each workinfoid.
Then every ~50 minutes, all the sharesummaries are summarised into markersummaries, for the range of workinfoid that marks each shift, and stored in the permanent database.

The new code includes a new summarisation level called blocksummaries.
They fit between sharesummaries and markersummaries so the process will (later) become:
Each incoming share goes into a sharesummary - that summarises all shares per worker, for each workinfoid.
Each network block, all sharesummaries of the height of the old network block are summarised into blocksummaries.
Then the blocksummaries are summarised into markersummaries, for the range of blocks that marks each shift, and stored in the permanent database.

The result of this change will be that shifts always end on block boundaries.
This means that it is quite simple to synchronise two separate pools - since all pools will have the same blocksummary boundaries - network blocks.
The new blocksummary code is already written and in the CKDB code, but not yet activated, it requires me to specify a future block to activate it, which I'll do in the future once I've done more testing of the yet-to-be-activated blocksummary code.
My final code change yet to be done, for distributing the pool better (and reliably), will be to send the blocksummaries, from each of the pool nodes, to the main node that will summarise all the pool node blocksummaries into shifts - and of course manage all main functions of CKDB.

For now, the point was to get the biggest change done and up and running, to ensure key change code was all producing the same results as before.

--

I've been working on the switch over to support /NYA/ and that will be the next change on the pool in the next week.

After that will be the cloud mining enhancements, to the current 'simple cloud mining' code, that already exists.

Then should be the accounting changes to support weekly and monthly payouts for smaller miners.

[philipma1957]

There will be a CKDB restart around 06:30 UTC
The exact time will be when the next shift completes - but should be close to 06:30

No mining will be affected.

The web site/API will be unavailable for 10 to 15 minutes.

However
This is a major update for my CKDB code so I've setup a way to quickly roll it all back in the event of problems running the new code live.
Hopefully that wont be necessary, since I've done pretty extensive testing of the new code, running 3 weeks of data (about 3 billion shares) through it a number of times ... until all shift, share, reward, payout and payout transaction generation produced the exact same results as the live running system.
A rollback will just mean another restart of CKDB - but again it's not expected, but setup to ensure minimal downtime in the event of a problem running live.
I've modified about 20% of the CKDB code, to deal with the key change of most of the main data.

... mine on

Restart completed OK and still running OK ... touch wood
Restart was from 06:39 UTC to 06:46 UTC - 7 minutes.

Some TL;DR; for anyone interested in what's changed and why.

In my original implementation of the pool, the code always assumed that a workinfoid was always increasing over time.
The workinfoid is the identifier for each work base used to generate work for all the miners, that gets updated every 30 seconds and every network block change.
This is the case when running one controlling pool instance, however to run more than one instance requires relaxing that assumption.

The first step in that process is to change the key of all the data, and all code accessing that data, to include the block height in front of the workinfoid.
That's part of what this code change has done in all ram tables, pgsql tables, and all functions/code that access anything using workinfoid.

The old code summarises shares as follows:
Each incoming share goes into a sharesummary - that summarises all shares per worker, for each workinfoid.
Then every ~50 minutes, all the sharesummaries are summarised into markersummaries, for the range of workinfoid that marks each shift, and stored in the permanent database.

The new code includes a new summarisation level called blocksummaries.
They fit between sharesummaries and markersummaries so the process will (later) become:
Each incoming share goes into a sharesummary - that summarises all shares per worker, for each workinfoid.
Each network block, all sharesummaries of the height of the old network block are summarised into blocksummaries.
Then the blocksummaries are summarised into markersummaries, for the range of blocks that marks each shift, and stored in the permanent database.

The result of this change will be that shifts always end on block boundaries.
This means that it is quite simple to synchronise two separate pools - since all pools will have the same blocksummary boundaries - network blocks.
The new blocksummary code is already written and in the CKDB code, but not yet activated, it requires me to specify a future block to activate it, which I'll do in the future once I've done more testing of the yet-to-be-activated blocksummary code.
My final code change yet to be done, for distributing the pool better (and reliably), will be to send the blocksummaries, from each of the pool nodes, to the main node that will summarise all the pool node blocksummaries into shifts - and of course manage all main functions of CKDB.

For now, the point was to get the biggest change done and up and running, to ensure key change code was all producing the same results as before.

--

I've been working on the switch over to support /NYA/ and that will be the next change on the pool in the next week.

After that will be the cloud mining enhancements, to the current 'simple cloud mining' code, that already exists.

Then should be the accounting changes to support weekly and monthly payouts for smaller miners.

This would be nice.   Even a 0.01 threshold  works for me.

[kano]

Block! by dsjif
14+ BTC (it was a 78 second network block)
and a payout

[usernamehere]

Philipma1957 - Concerning the bonus from coinbase you referenced, how did you hear about that, I was preparing to make a "buy" but have held off for a bit, but I am unaware of this "bonus".

How did you hear about it? Is it still in effect?

 I do not see it posted anywhere on my account page nor I have received any emails from them.

Thanks

I think it is over and I am not sure I am going to get it.

I will send a pm of the screen shot I took

Did you use a referral link to sign up to Coinbase? If you use a referral link and buy $100 worth of btc, then you and your referrer both get $10 of btc.

[bit2255]

I already have a previous $10 bonus on my account, so I could not use this for another one. I originally thought Coinbase had another offer to take advantage of, I was incorrect.

[tbonetony]

There will be a CKDB restart around 06:30 UTC
The exact time will be when the next shift completes - but should be close to 06:30

No mining will be affected.

The web site/API will be unavailable for 10 to 15 minutes.

However
This is a major update for my CKDB code so I've setup a way to quickly roll it all back in the event of problems running the new code live.
Hopefully that wont be necessary, since I've done pretty extensive testing of the new code, running 3 weeks of data (about 3 billion shares) through it a number of times ... until all shift, share, reward, payout and payout transaction generation produced the exact same results as the live running system.
A rollback will just mean another restart of CKDB - but again it's not expected, but setup to ensure minimal downtime in the event of a problem running live.
I've modified about 20% of the CKDB code, to deal with the key change of most of the main data.

... mine on

Restart completed OK and still running OK ... touch wood
Restart was from 06:39 UTC to 06:46 UTC - 7 minutes.

Some TL;DR; for anyone interested in what's changed and why.

In my original implementation of the pool, the code always assumed that a workinfoid was always increasing over time.
The workinfoid is the identifier for each work base used to generate work for all the miners, that gets updated every 30 seconds and every network block change.
This is the case when running one controlling pool instance, however to run more than one instance requires relaxing that assumption.

The first step in that process is to change the key of all the data, and all code accessing that data, to include the block height in front of the workinfoid.
That's part of what this code change has done in all ram tables, pgsql tables, and all functions/code that access anything using workinfoid.

The old code summarises shares as follows:
Each incoming share goes into a sharesummary - that summarises all shares per worker, for each workinfoid.
Then every ~50 minutes, all the sharesummaries are summarised into markersummaries, for the range of workinfoid that marks each shift, and stored in the permanent database.

The new code includes a new summarisation level called blocksummaries.
They fit between sharesummaries and markersummaries so the process will (later) become:
Each incoming share goes into a sharesummary - that summarises all shares per worker, for each workinfoid.
Each network block, all sharesummaries of the height of the old network block are summarised into blocksummaries.
Then the blocksummaries are summarised into markersummaries, for the range of blocks that marks each shift, and stored in the permanent database.

The result of this change will be that shifts always end on block boundaries.
This means that it is quite simple to synchronise two separate pools - since all pools will have the same blocksummary boundaries - network blocks.
The new blocksummary code is already written and in the CKDB code, but not yet activated, it requires me to specify a future block to activate it, which I'll do in the future once I've done more testing of the yet-to-be-activated blocksummary code.
My final code change yet to be done, for distributing the pool better (and reliably), will be to send the blocksummaries, from each of the pool nodes, to the main node that will summarise all the pool node blocksummaries into shifts - and of course manage all main functions of CKDB.

For now, the point was to get the biggest change done and up and running, to ensure key change code was all producing the same results as before.

--

I've been working on the switch over to support /NYA/ and that will be the next change on the pool in the next week.

After that will be the cloud mining enhancements, to the current 'simple cloud mining' code, that already exists.

Then should be the accounting changes to support weekly and monthly payouts for smaller miners.

Kano,

I am excited for these upcoming changes.

Would you consider posting your roadmap up on kano.is for better visibility and maintainability?

[clgrissom3]

Block by blockmines!

[kano]

Block! by 16TS...

[clgrissom3]

Block! by 16TS...

Whohoo!  This is our 3rd of BLOCK SUNDAY!

[eddiephx]

Is it worth running a S9 on this pool? What's the average daily payout?

[cre8ive]

Is it worth running a S9 on this pool? What's the average daily payout?

I just started running a S9 13.5THs on this pool. I'm getting around 0.00234418 BTC/block.

In June there were 72 blocks found so 72 * 0.00234418 = 0.16878096 BTC/month

Obviously mileage will vary, and I'm too new to give any smart insight - but hopefully this helps.

Cheers,

Ben

[dzimmerm56]

Is it worth running a S9 on this pool? What's the average daily payout?

I did a months check when I was running one S9 and the daily payout averaged to about .0065 bitcoin a day.
This will vary depending on luck, but probably not by much.
Whether it is worth it or not depends on your electricity costs and the value of bitcoin at the time.
For me it is a positive amount unless the value of bitcoin drops very very low.

dzimmerm

[kano]

Is it worth running a S9 on this pool? What's the average daily payout?

I did a months check when I was running one S9 and the daily payout averaged to about .0065 bitcoin a day.
This will vary depending on luck, but probably not by much.
Whether it is worth it or not depends on your electricity costs and the value of bitcoin at the time.
For me it is a positive amount unless the value of bitcoin drops very very low.

dzimmerm

... and just a reminder for anyone who's not sure about PPS vs the PPLNS we run
It's not what you will get every day - some days more, some days less, few days a lot more, and a few days none.
It's an average - as dzimmerm56 said - since luck is a factor in all PPLNS payouts, that causes variance.

But comparing PPS to PPLNS, you will always 'expect' to 'average' more with PPLNS, since PPS must include a higher fee to reduce the risk of the pool going broke due to bad luck.
Here, no such luck risk exists, since each payout is covered by the blocks found.

The best of both worlds, higher 'expected' rewards, and lower risk
The pool size here also guarantees that the vast majority of your shares are not rewarded late, weeks down the track, when difficulty has risen and the share value has dropped significantly.

[kano]

...

Kano,

I am excited for these upcoming changes.

Would you consider posting your roadmap up on kano.is for better visibility and maintainability?

Probably not in the near future.

The main reason would be that the roadmap seems to hit regular bumps and I end up changing when things happen.
I do have a (very) large TODO list that I'd hate to actually post anywhere online since I'd probably find people clamouring for some of the changes, when I really do almost randomly decide when to do things

Since I run everything and do everything for the pool, things get randomly prioritised.

The high priority things 'usually' don't change order, but as an example, this week working on /NYA/ was never in the TODO list until after the NYA meeting occurred.
Though, it was in the TODO list under a different name, due now, ... dealing with 'segshit'

[eddiephx]

Okay great thanks guys for the responses. So would you say kano pays better than pools like antpool, slushpool, and f2pool on average with just one S9?

[kano]

Okay great thanks guys for the responses. So would you say kano pays better than pools like antpool, slushpool, and f2pool on average with just one S9?

... and just a comment from me also

Here the pool is 'expected' to pay better than EVERY other pool.
Here it's: lower fees than any pool that doesn't have the 'too small' size issue of losing share value, and no PPS fees needed to reduce the risk of the pool going broke.

The only thing that affects that is the pool luck ... i.e. the word 'expected' above.

If luck is the 'expected' value (100%) then the pool reward is 'expected' to be above every other pool.
If luck it higher than 'expected' then you'll do even better.
If luck is lower then 'expected' then you'll do worse than the 'expected' ... which is usually still above the PPS pools (e.g. Antpool and F2Pool)

What you probably don't realise is that PPS pools e.g. Antpool and F2Pool, charge their miners ridiculous high fees.
F2Pool is currently between 9 times and 12 times our fee (PPS -3% or PPS 0%)
Antpool is currently 6 times our fee (PPS 106.04%)

Edit: and slush is more than twice our fee

[kano]

Block! by jimmy
14.4 BTC
and a payout

[dzimmerm56]

Okay great thanks guys for the responses. So would you say kano pays better than pools like antpool, slushpool, and f2pool on average with just one S9?

Yes, two reasons.
Kano shares the transaction fees received when a block is mined as well as the 12.5 bitcoins . This results in blocks with values between 12.5 to 16.5 bitcoins.
Secondly Kano charges a smaller fee, .9%, on the miners earnings.
All of the large pools keep the transaction fees. Slush and Kano, both medium sized pools, share the transaction fees with their miners. Some smaller pools share transaction fees, some don't.

The only pseudo drawback to Kano is that it sometimes goes a day or almost two without hitting a block. That can be discouraging if you are a newbie. Kano also splits the payouts so they are about 20% of value earned divvied up over 5 payments. This is done to smooth out payments even if the input of blocks is very irregular. It means you will receive smaller more numerous payouts untill you have been mining for about 4 or 5 days. After that ramp up time you will receive numerous full payouts. My current payout with two S9s is a bit over .005 per payout. What varies is the number of these payouts I see per day. If averages hold that would mean I will receive .013 bitcoin or better per day for 2 S9s.
I added the second S9 less than a month ago so I can not give you hard figures yet.

Kano pool requires a bit more patience due to the 20% payout system and its some what irregular block find timing. I would strongly recommend committing to Kano pool for no less than 2 weeks and then you will see for yourself how much more you are receiving compared to other pools.

edited to correct error in transaction fee value. dzimmerm

[kano]

Just a minor adjustment
The fee here is 0.9% and always has been and always will be.
It's not a low short term fee that will go up some time soon, it's 0.9%
... and I don't expect tips or donations either.