Topic: KanoPool kano.is lowest 0.9% fee 🐈 since 2014 - Worldwide - 2432 blocks - page 902. (Read 5352420 times)
July 16, 2017, 06:22:30 PM
Block! by 16TS...
July 16, 2017, 03:49:55 PM
Block by blockmines! 
July 16, 2017, 03:40:55 PM
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 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 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?
July 16, 2017, 11:16:22 AM
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.
July 16, 2017, 09:06:49 AM
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
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.
July 16, 2017, 07:46:35 AM
Block! by dsjif
14+ BTC (it was a 78 second network block)
and a payout
14+ BTC (it was a 78 second network block)
and a payout
July 16, 2017, 04:36:30 AM
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 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 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.
July 16, 2017, 02:25:09 AM
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 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 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.
July 15, 2017, 02:19:25 PM
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
Can't wait to see you PM
Thanks
July 15, 2017, 02:15:20 PM
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
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
July 15, 2017, 01:57:14 PM
BLOCK
Block is by Jimmy - Thanks for breaking the weekend ice-block!
July 15, 2017, 01:55:45 PM
BLOCK
July 15, 2017, 12:15:26 PM
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
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
July 15, 2017, 12:09:02 PM
Spot is indeed interesting at the moment.
Hoping that August transformer upgrade is a big one...I'd like to add a couple of 741s then as well.
I had to leave Coinbase back in January when Hawaii made it impossible for them to operate here...been using CEX, and belong to one other as a backup. But then, as y'all know, I never keep coin in someone else's wallet unless it's for a specific transaction.
I also moved to 14 a while ago. I backup the wallet to two USB drives, one of which goes into my safe, and the other is on my keychain. Another backup goes to a secondary, removable HDD in the workstation. I think/hope I learned my lesson with Mt. Gox.
Hoping that August transformer upgrade is a big one...I'd like to add a couple of 741s then as well.
I had to leave Coinbase back in January when Hawaii made it impossible for them to operate here...been using CEX, and belong to one other as a backup. But then, as y'all know, I never keep coin in someone else's wallet unless it's for a specific transaction.
I also moved to 14 a while ago. I backup the wallet to two USB drives, one of which goes into my safe, and the other is on my keychain. Another backup goes to a secondary, removable HDD in the workstation. I think/hope I learned my lesson with Mt. Gox.
July 15, 2017, 11:31:31 AM
Is anyone thinking it's about time to start buying bitcoin since it has dropped? I'm thinking buy low and sell high. And right now is looking pretty low.
I sold 4 coins at 9550 that is 2387.50 a coin
I purchased .1 coin at 202 that is 2020 a coin
I will keep my eye on coin price and may buy more soon.
I also updated from 11.0 core to the 14 core.
I shifted some coin from coinbase to it.
Since this core is on a mac mini I am cloning the hdd for a backup.
Once the backup boots and works for the core I will do a second back up.
Once that boots and works I will put it in a safety deposit box.
I will then toss most of my coins into that core wallet.
Today coinbase had frozen the send function on btc. They allowed sale of btc to you bank but not sends.
They were giving a bonus if you purchased 100 in btc they were giving 110 as it was obvious too many were pulling coins out and putting coins in core wallets.
Coinbase must have got enough coins now as they are allowing sends of btc again.
So i pull .6 coins out of them along with buying 100 bucks for the 10 dollar bonus.
The next 30 days will see a lot of coin action be careful everyone.
As a complete aside I am suspending my escrow services as I do not want frozen coins to be an issue.
I may shift to more avalons in august and bump my hash here from 26th to 50th
July 15, 2017, 11:08:35 AM
Hi kano. 1 August with BIP 148, do we have anything to worry about? Us miners in kano? I'm a bit stressed. I've read alot of OPINIONS, and I would rather want to know what you have to say. Regards!
Ignore BIP148 - it's simply an attempt by a bunch of users to take control of Bitcoin away from miners - mining is the design of Bitcoin and it will stay that way.I'll sort it out within the next week.
I'll hopefully be able to put the new KDB code live tomorrow, so that will finally be out of the way.
Looks like I'll simply have to accept that Bitcoin mining majority is going to accept some form of SegWit - and make sure when it activates, the pool will work on any and all SegWits that happen to be blundering around ...
Pretty much every block now has the /NYA/ 'expression of interest' in it and NYA effectively means SegWit also.
Seems Core has managed to con/force everyone into accepting it, pretending it's a block size solution
Don't forget that if it activates, your 1xxx addresses will cost 4 times as much to use per byte than 3xxx addresses
(yeah they really like their dodgy P2SH addresses and are forcing everyone to risk all their BTC on those dodgy addresses)
Once I've got that all ready I'll post about the details and then switch over the main work generator to using whatever is necessary.
For those of us that run full nodes, is there a certain one you suggest?
July 14, 2017, 07:43:18 PM
Hello everyone. I would like to understand more on the UASF issues on 1August. My question is should we mine or should we stop till all are settle? Appreciate for any answers or comments.
https://bitcointalksearch.org/topic/m.20092412 July 14, 2017, 07:30:44 PM
Hello everyone. I would like to understand more on the UASF issues on 1August. My question is should we mine or should we stop till all are settle? Appreciate for any answers or comments.
July 14, 2017, 11:53:37 AM
Been busy...couldn't keep up.
Clgrissom (Sonny) said it best. I use Cryptoboreas in Labrador (hence the dog sled memes). They're smart, honest, reliable, and the least expensive. They do what I need done. There are at least four decent hosting services I know of in North America, two in Canada and two in the US Pacific NW. Take your pick!
CB is full up at the moment. The machines I'm sending are replacing two older ones that will remain "on the side" until more power is available. The change gives me a net 4TH increase on less watts.
Clgrissom (Sonny) said it best. I use Cryptoboreas in Labrador (hence the dog sled memes). They're smart, honest, reliable, and the least expensive. They do what I need done. There are at least four decent hosting services I know of in North America, two in Canada and two in the US Pacific NW. Take your pick!
CB is full up at the moment. The machines I'm sending are replacing two older ones that will remain "on the side" until more power is available. The change gives me a net 4TH increase on less watts.
Do you actually make a return on this? To host 3 S9's for 3 months it would be $647.09 US.
July 14, 2017, 11:45:30 AM
Been busy...couldn't keep up.
Clgrissom (Sonny) said it best. I use Cryptoboreas in Labrador (hence the dog sled memes). They're smart, honest, reliable, and the least expensive. They do what I need done. There are at least four decent hosting services I know of in North America, two in Canada and two in the US Pacific NW. Take your pick!
CB is full up at the moment. The machines I'm sending are replacing two older ones that will remain "on the side" until more power is available. The change gives me a net 4TH increase on less watts.
Clgrissom (Sonny) said it best. I use Cryptoboreas in Labrador (hence the dog sled memes). They're smart, honest, reliable, and the least expensive. They do what I need done. There are at least four decent hosting services I know of in North America, two in Canada and two in the US Pacific NW. Take your pick!
CB is full up at the moment. The machines I'm sending are replacing two older ones that will remain "on the side" until more power is available. The change gives me a net 4TH increase on less watts.
Do you actually make a return on this? To host 3 S9's for 3 months it would be $647.09 US.
at 7 cents a kwatt price is 650 or so for the 3 months. about 39th.
so in 90 days
using 650 as cost
using 0 as power as it is reflected above
using 39000 gh
using 4200 watts
using 4% hash rate growth
using 13 btc a block as kano pays this
using 2185 a coin
10-12 – 10-12 (90 days) 1017 G 21.88 21.44 1539
the 650 power was paid you net 1539 after power.
this does not count the cost of buying the gear. So it is a good deal if the gear does not break
Jump to: