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

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!

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.

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 

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.

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.

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.   

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

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.

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


MINE THE F ON WITH KANO-SAN!!!

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!

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



Good to know the root cause, thanks 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!

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

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

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.

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

BTCBTCBTCLLL000CCCKKK!!!

Thanks, MicroBalrog! 

BTCamm!!!

Congratz to MicroBalrog!!!
less than 100THash and found a block!
Welcome to the aclaim board.