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

[Shazam!!!]

BTCamm!!!

[BSGMiner]

BTCBTCBTCLLL000CCCKKK!!!

Thanks, MicroBalrog! 

[firetreeactual]

BTCBTCBTCLLL000CCCKKK!!!

Thanks, MicroBalrog! 

Ditto...I can get used to this...

[minergain.com]

If you have a bunch of inputs from pool mining (doesn't have to be here), might as well merge them all together into one larger input with these fee rates, which are practically 0.   

To give you an idea, a couple months ago when activity was high, $100 for a dozen transactions sent within a few hours was commonplace.  If you had a single transaction, it would be 1/12th of that.  Right now you can send a dozen transactions for under a dollar most of the time.

[VRobb]

One (small) Block to rule them all! 
Cheers MicroBalrog!  Block Party Thursday is ON! 

[nazzer]

Hey, whaddya know we're back to 100% for the month. Now we just need to be 100% for the last 5 blocks

[kano]

Anyone interested in a run down of the KDB problem the other day ...

Note this is a TL;DR; for most

The cause was related to the pool size, not a bug in my KDB code 'as such'
The sequence number code allows tracking 2^20 (~1mill) sequence numbers for shares.
This tracking is needed for out of order data, but the code of course doesn't keep that data forever, it reuses the data when it needs more space.
This reuse means that it can only track ~1 million different share sequence numbers at any one time.
This is way more than needed for normal running, but during a reload there's a sizeable time difference between the start of the reload and the data coming in from the pool code.
The catch comes when the reload has completed, then it starts processing the queue of data from the pool that arrived while it was reloading.
This can't be more than ~1 million shares apart, which again is normally OK but can be a problem for a slow (long) reload done on the live server.

The extremely large log shows this is the cause of problem, but there was so much data in the log file that it wasn't obvious at first why it happened.

The fix is 2 fold:
1) if I ever need to roll back the database to correct or generate missing shift data, don't do it, use the backup server to generate it and copy it across like I did, except the first time during the problem.
2) I'll increase the share sequence tracking size by another 8x before I restart KDB again

Mine on!

[nazzer]

Anyone interested in a run down of the KDB problem the other day ...

Note this is a TL;DR; for most

This can't be more than ~1 million shares apart, which again is normally OK but can be a problem for a slow (long) reload done on the live server.

The extremely large log shows this is the cause of problem, but there was so much data in the log file that it wasn't obvious at first why it happened.

The fix is 2 fold:
1) if I ever need to roll back the database to correct or generate missing shift data, don't do it, use the backup server to generate it and copy it across like I did, except the first time during the problem.
2) I'll increase the share tracking size by another 8x before I restart KDB again

Mine on!

TL;DR - 1,000,000 shares ought to be enough for anyone



Good to know the root cause, thanks Kano

[rockmoney]

Kano Pool is on the move! Currently 147,489.77 TH/s and has been increasing. I don't know why anyone would mine elsewhere with this pools unheard of PPLNS 0.9% fee!

Everyone point there miners at ' stratum+tcp://stratum.kano.is:3333 ', and let's GET PAID!

[rifleman74]

Anyone interested in a run down of the KDB problem the other day ...

Note this is a TL;DR; for most

The cause was related to the pool size, not a bug in my KDB code 'as such'
The sequence number code allows tracking 2^20 (~1mill) sequence numbers for shares.
This tracking is needed for out of order data, but the code of course doesn't keep that data forever, it reuses the data when it needs more space.
This reuse means that it can only track ~1 million different share sequence numbers at any one time.
This is way more than needed for normal running, but during a reload there's a sizeable time difference between the start of the reload and the data coming in from the pool code.
The catch comes when the reload has completed, then it starts processing the queue of data from the pool that arrived while it was reloading.
This can't be more than ~1 million shares apart, which again is normally OK but can be a problem for a slow (long) reload done on the live server.

The extremely large log shows this is the cause of problem, but there was so much data in the log file that it wasn't obvious at first why it happened.

The fix is 2 fold:
1) if I ever need to roll back the database to correct or generate missing shift data, don't do it, use the backup server to generate it and copy it across like I did, except the first time during the problem.
2) I'll increase the share sequence tracking size by another 8x before I restart KDB again

Mine on!

Yep, that tracking size increase should solve that problem.  Thanks for the update KANO!


MINE THE F ON WITH KANO-SAN!!!

[sruyle]

Hempfrog:

You have been randomly chosen for 5 days of my S7.  Starting now.

Congratulations.

Yes, I decided to add to the pass the hash bonus and chose a random number 1-100 from the bottom of the stats page for the giveaway. You won.

[jhoren]

Doing the math here, I think I'll even be ok during summer pricing, which goes just over 12 cents/kWh.

Although, I have been wondering about the peak pricing option. Not worrying about it now, because I don't have enough machines yet, but if I had considerably more would it be beneficial to switch to the peak pricing and then shut down for five hours M - F. That's 25 hours of downtime out of 168 hours, skips 30+ cents/kWh and runs during off-peak for lower 7 cents/kWh.

If I ran straight through, the average would be about 12.05 cents/kWh. Less than the normal pricing by about .5 cents.

Sounds like more math.  Let me take a swing at it using a 13.5TH 1452 (at the wall) Watts as a basis.  Of course, everything would scale linearly with that.  Lets calc on a week.

168 hours at $0.1205 = $20.24 for power and yields 13.5TH * 168 hours = 8.1648 EHashes = $2.4789/EHash
143 hours at $0.07 = $10.01 for power and yields 13.5Th * 143 hours = 6.9498 Hashes = $1.44/EHash

That is the cost side.  You need to figure your profit side, subtract the cost, and see which is better.

Thank you ccgllc. I think my main question might be how ramp down/up with five hours of off time might affect it. I don't think it would be noticeable but I wonder how I might be able to calculate that.

[wavelengthsf]

Thank you ccgllc. I think my main question might be how ramp down/up with five hours of off time might affect it. I don't think it would be noticeable but I wonder how I might be able to calculate that.

If you turned your miners off for 5 hours every day, they'd be mining 19 hours. That's roughly 20% less hash rate. You can take your hash rate and subtract 20% from that and run your calculations. The ramp up and ramp down won't really matter.

[rifleman74]

If you have a bunch of inputs from pool mining (doesn't have to be here), might as well merge them all together into one larger input with these fee rates, which are practically 0.  

To give you an idea, a couple months ago when activity was high, $100 for a dozen transactions sent within a few hours was commonplace.  If you had a single transaction, it would be 1/12th of that.  Right now you can send a dozen transactions for under a dollar most of the time.

It's much less than a dollar, this was at least 20 inputs from March, plus whatever we had in April.   Really really cheap, date of the previous consolidation was on 2/27/18.   

35 cents for combine all of that.   

[jhoren]

Thank you ccgllc. I think my main question might be how ramp down/up with five hours of off time might affect it. I don't think it would be noticeable but I wonder how I might be able to calculate that.

If you turned your miners off for 5 hours every day, they'd be mining 19 hours. That's roughly 20% less hash rate. You can take your hash rate and subtract 20% from that and run your calculations. The ramp up and ramp down won't really matter.

Thank you. I ran my calculations basing it on the total hash rate of the pool for the week and then of my % of that.

With a single machine there's about a $2.25 difference per week at the current BTC-USD rate. Maybe worth it if I get more machines running.

I ran it also if I ran it during the very expensive portion of the peak time and I would lose $.25 per week there. So, I could probably talk myself into giving the pool that hash and not stop it. But I'd still be saving using the peak/off-peak instead of just the straight cost.

[ricknamer]

For anyone looking to order from Bitmain.  Especially us Kano guys!

I just placed an order now.

They are now accepting BCH, BTC and LTC as payment.

First I have seen this.

[perfectplus174]

For anyone looking to order from Bitmain.  Especially us Kano guys!

I just placed an order now.

They are now accepting BCH, BTC and LTC as payment.

First I have seen this.

Yeah, I ordered one with BCH and one with BTC.

Will be buying more when the rest of my BCH is available. Luckily I stocked up when everything was down so it's like an extra coupon 

[kano]

Thank you ccgllc. I think my main question might be how ramp down/up with five hours of off time might affect it. I don't think it would be noticeable but I wonder how I might be able to calculate that.

If you turned your miners off for 5 hours every day, they'd be mining 19 hours. That's roughly 20% less hash rate. You can take your hash rate and subtract 20% from that and run your calculations. The ramp up and ramp down won't really matter.

Thank you. I ran my calculations basing it on the total hash rate of the pool for the week and then of my % of that.

With a single machine there's about a $2.25 difference per week at the current BTC-USD rate. Maybe worth it if I get more machines running.

I ran it also if I ran it during the very expensive portion of the peak time and I would lose $.25 per week there. So, I could probably talk myself into giving the pool that hash and not stop it. But I'd still be saving using the peak/off-peak instead of just the straight cost.

Also to work out what to expect to lose from mining 80% of the time, as stated above that's 20% less expected reward.

How the ramp down and up works is that instead of losing 20% on the next block, and of course the luck of single block finding has very high variance, you instead lose it over 5Nd - i.e. you expect that 20% loss spread out over 5Nd after the outage - or 4% each 100% expected block
If it's a daily thing, then you should see the rewards settle close to the expected 80% each block reward as the daily 4%s overlap.

[dzimmerm56]

For anyone looking to order from Bitmain.  Especially us Kano guys!

I just placed an order now.

They are now accepting BCH, BTC and LTC as payment.

First I have seen this.

Interesting. With the almost over USA tax season and The great underground empire taking bitcoin for miners again, I expect the price of bitcoin to start upward. Lets watch and see,    ...

Mine On!

[ricknamer]

For anyone looking to order from Bitmain.  Especially us Kano guys!

I just placed an order now.

They are now accepting BCH, BTC and LTC as payment.

First I have seen this.

Interesting. With the almost over USA tax season and The great underground empire taking bitcoin for miners again, I expect the price of bitcoin to start upward. Lets watch and see,    ...

Mine On!

The only thing I can think of is they see a bottom.  Low crypto prices = more crypto required for a purchase.  If they are expecting a spike they'd do anything to get more crypto in the wallets before that happens - ride the upside.