Author

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

legendary
Activity: 1736
Merit: 1032
Carl, aka Sonny :)

Waking up to a block in the tank and a couple of payouts! Cheesy

Now where is that coffee Grin
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
Look at that luck.
Last 50 Blocks   6.2wks   106.13%   116.09%
I hope you are sitting back grinning Kano Smiley

A bit older topic but I also noticed higher pool side rejects with the Avalons, though they hash higher than advertised in a good environment so doesn't really hurt my feelings.
But is there a way to get this number down perhaps?
Meanwhile pretty much all my Antminer gear after a few weeks loses 5-10% hashrate until a reboot, but almost no invalids (S7 and S9s) which is odd given I'd assume they have crappy everything compared to Avalon's setup.

Yeah I mentioned about that earlier, the Bitmain code throws away the stale shares rather than letting cgminer decide based on cgminer settings.
Yes bmminer is still cgminer, but that link shows the nightmare of code they do to a share returned from the miner before passing it back to the main cgminer code to deal with it.
 https://bitcointalksearch.org/topic/m.18083086
but specifically:
 https://github.com/bitmaintech/bmminer/blob/master/driver-btm-c5.c#L7887
So it's just hiding most of them.
hero member
Activity: 979
Merit: 510
Look at that luck.
Last 50 Blocks   6.2wks   106.13%   116.09%
I hope you are sitting back grinning Kano Smiley

A bit older topic but I also noticed higher pool side rejects with the Avalons, though they hash higher than advertised in a good environment so doesn't really hurt my feelings.
But is there a way to get this number down perhaps?
Meanwhile pretty much all my Antminer gear after a few weeks loses 5-10% hashrate until a reboot, but almost no invalids (S7 and S9s) which is odd given I'd assume they have crappy everything compared to Avalon's setup.


legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
Block! by cobramining Smiley
A7v1 Smiley
newbie
Activity: 2
Merit: 0
I was making a general statement about not getting payouts everyday - Meaning no one else in the pool is getting paid out either until a block is found

Anyways like i said im new LOL  Smiley

Ill go back to lurking in the shadows
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
Hello Everyone,

New Miner here! Just wanted to say hi!

I started at slush and ended up here - At first i missed the daily payouts until i read what Kano said "it has nothing to do with Bitcoin" I also started around the Mr 415% so i was feeling the "missed payments" but after reading alot in this forum i have decided to stay and keep trucking through  Smiley

Besides for the new people its not just YOU having bad luck.... its everyone else too. Kiss
What bad luck is that?
The last 50 blocks (6 weeks) miners have averaged 116% PPS.
The last 100 (almost 8 weeks) miners have averaged 106% PPS.

...
But what sucks if there is any way a person can just be a real unlucky fellow or gal thats just a jinx like Mr. 415% kill joy..
...
a 415% or longer is expected, on average, once every 63.4 blocks ...
newbie
Activity: 2
Merit: 0
Hello Everyone,

New Miner here! Just wanted to say hi!

I started at slush and ended up here - At first i missed the daily payouts until i read what Kano said "it has nothing to do with Bitcoin" I also started around the Mr 415% so i was feeling the "missed payments" but after reading alot in this forum i have decided to stay and keep trucking through  Smiley

Besides for the new people its not just YOU having bad luck.... its everyone else too. Kiss

legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
I was also thinking about the the 5Nd thing, whether this really is just a statistical smoothing function (moving average) or wether it gives "old" miners a 5Nd (currently about 100h, but possibly not constant(Huh)) lead over new miners due to network difficulty changes every 14 days? Are new miners disadvantaged by this in that when their hashes are paid out the 5th time they are worth less (if a diff change has since occurred)? Maybe this has been considered before, but some explanation would be nice.

Anyone willing to chime in on whether newbies starting out are disadvantaged compared to someone who has already "filled" the 5Nd window or not due to upcoming diff increases? Thanks.
What actually happens is that each share you submit (as the web page says) is rewarded in all blocks in the 5Nd after it.
So basically, it takes 5Nd to get rewarded.
It has nothing to do with a lower reward for your work.
When you have 5Nd worth of shares, then you always have a full set of shares to be rewarded.
It has no possible expected effect on your reward at all.
It's simply to do with reducing reward variance (by stretching out the reward time)

Thanks for chiming in!
For clarity: Is a share not worth less after a diff increase, as more shares are now required to find a block? Or are you saying that that share is weighed according to the diff at the time it was submitted and thus worth the same amount of relative pool hash power irrespective of a what the current diff is as compared to the diff at the time of submission? Am I expressing myself clearly?
Yes a share is worth less after a diff change.
If the 5ND after the share, crosses a diff change, that reduces the expected reward of a share, since there's no extra BTC lying around unclaimed.
The only way to apply more BTC to those old shares would be to take it away from the new shares i.e. no.

Thus yes the N in PPLNS does affect the reward of shares, if their reward cross a difficulty boundary - the same for all miners on the pool.
member
Activity: 81
Merit: 10
I was also thinking about the the 5Nd thing, whether this really is just a statistical smoothing function (moving average) or wether it gives "old" miners a 5Nd (currently about 100h, but possibly not constant(Huh)) lead over new miners due to network difficulty changes every 14 days? Are new miners disadvantaged by this in that when their hashes are paid out the 5th time they are worth less (if a diff change has since occurred)? Maybe this has been considered before, but some explanation would be nice.

Anyone willing to chime in on whether newbies starting out are disadvantaged compared to someone who has already "filled" the 5Nd window or not due to upcoming diff increases? Thanks.
What actually happens is that each share you submit (as the web page says) is rewarded in all blocks in the 5Nd after it.
So basically, it takes 5Nd to get rewarded.
It has nothing to do with a lower reward for your work.
When you have 5Nd worth of shares, then you always have a full set of shares to be rewarded.
It has no possible expected effect on your reward at all.
It's simply to do with reducing reward variance (by stretching out the reward time)

Thanks for chiming in!
For clarity: Is a share not worth less after a diff increase, as more shares are now required to find a block? Or are you saying that that share is weighed according to the diff at the time it was submitted and thus worth the same amount of relative pool hash power irrespective of a what the current diff is as compared to the diff at the time of submission? Am I expressing myself clearly?
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
I was also thinking about the the 5Nd thing, whether this really is just a statistical smoothing function (moving average) or wether it gives "old" miners a 5Nd (currently about 100h, but possibly not constant(Huh)) lead over new miners due to network difficulty changes every 14 days? Are new miners disadvantaged by this in that when their hashes are paid out the 5th time they are worth less (if a diff change has since occurred)? Maybe this has been considered before, but some explanation would be nice.

Anyone willing to chime in on whether newbies starting out are disadvantaged compared to someone who has already "filled" the 5Nd window or not due to upcoming diff increases? Thanks.
What actually happens is that each share you submit (as the web page says) is rewarded in all blocks in the 5Nd after it.
So basically, it takes 5Nd to get rewarded.
It has nothing to do with a lower reward for your work.
When you have 5Nd worth of shares, then you always have a full set of shares to be rewarded.
It has no possible expected effect on your reward at all.
It's simply to do with reducing reward variance (by stretching out the reward time)
legendary
Activity: 4354
Merit: 9201
'The right to privacy matters'
this pool is not going to attract newbies.

5n
block by block payouts
no auto withdrawal
no set limit payout.

all of the above simply won't work for a new guy that purchased a 1500 dollar s-9 and a 200 dollar psu.

they say I am down 1700 usd I want steady money back now.

thus f2poo it is for them

if they  make back some money and see btc is not going poof maybe then they will come here.
sr. member
Activity: 277
Merit: 250
I was also thinking about the the 5Nd thing, whether this really is just a statistical smoothing function (moving average) or wether it gives "old" miners a 5Nd (currently about 100h, but possibly not constant(Huh)) lead over new miners due to network difficulty changes every 14 days? Are new miners disadvantaged by this in that when their hashes are paid out the 5th time they are worth less (if a diff change has since occurred)? Maybe this has been considered before, but some explanation would be nice.

Anyone willing to chime in on whether newbies starting out are disadvantaged compared to someone who has already "filled" the 5Nd window or not due to upcoming diff increases? Thanks.
I think any perceived disadvantage of 5Nd is minimal. Right now the 5Nd is ~106 hours. It changes with hashrate +/- and difficulty. I don't think the current time span is all that much, unless difficulty is making a huge jump (>10%).

We all went through it.

I think what really hurts is the lessened hash rate that adds to the variance. And I don't think we are all that newbie friendly. Though everyone here is helpful to the max, I think a lot of times we talk over their heads. They come here for a few days don't get the quickfix payouts they got at a larger pool.
member
Activity: 81
Merit: 10
I was also thinking about the the 5Nd thing, whether this really is just a statistical smoothing function (moving average) or wether it gives "old" miners a 5Nd (currently about 100h, but possibly not constant(Huh)) lead over new miners due to network difficulty changes every 14 days? Are new miners disadvantaged by this in that when their hashes are paid out the 5th time they are worth less (if a diff change has since occurred)? Maybe this has been considered before, but some explanation would be nice.

Anyone willing to chime in on whether newbies starting out are disadvantaged compared to someone who has already "filled" the 5Nd window or not due to upcoming diff increases? Thanks.
member
Activity: 81
Merit: 10
scraped from found blocks on webpage  Smiley



Random noise and statistics. There is no pattern no matter how much we would like to believe there is one  Shocked
member
Activity: 123
Merit: 17
scraped from found blocks on webpage  Smiley

sr. member
Activity: 261
Merit: 250
I really don't get the need for lots of daily payouts.  A payout ever day, even every few days or so is fine.  Do people really need 10 small payouts a day?  I would rather get 1 large payout a day than 10 small ones.  If nothing else, it makes less work for the accounting.  
Agreed. I do not see any point for it, other than extreme insecurity perhaps. If one does not trust the pool operator to reasonably protect/hold the rewards until adequately verified, one should probably mine elsewhere...methinks. Additionally, it puts the miners' accounting load on Kano, where it doesn't belong...again, methinks.

But then, I've been occasionally told I think too much...methinks.  Kiss

Sorry, but do you have multiple personality disorder today? Cheesy That first paragraph first agrees with larger payments, then the second part disagrees with larger payments, because larger consolidated payments mean the pool operator running a wallet that holds those payments until they are ready to payout.

So do you agree with one large consolidated payment a day or not? Smiley I think for this pool it works fine without, all you need to do is have a mining wallet and a cold, or spending wallet, the mining income goes into the mining wallet, and every week or so you send the coins from your mining wallet into your cold wallet, which consolidates the dust for you. Then when you want to trade or buy something with your coin you do so from the cold/spending wallet and, if you use a reasonable sized transaction fee, that spend will go through alot faster than if you sent it from your mining wallet.
Interesting. I said nothing about size of payments. It was about frequency. I also said nothing about consolidation. However, I do have an opinion on it...I don't like it. I do my accounting traceable to the block, and I'd like to keep it that way.

Really? If you normally 5 small payments per day, but consolidate them into one payment per day then thats going to be a single larger payment surely Smiley The frequency of payments in this example is directly correlated to the size of payment.

Thanks for clarifying your stance, I'm not having a go, just that you surprised me as your normal position is one of someone who likes the way things work here, but your first sentence is agreeing with the OP saying that they'd rather have one payout per day rather than lots of small payouts.

This is getting twisted...

I was responding to people complaining about the pool size and how they have to wait for the pool to find a block that confirms their pending payouts.  I was saying I like how the pool works, and I think waiting a day or two shouldn't really be an issue for people.  Yes, I know people are impatient, but mining takes time.  You buy equipment that will take 6 months ~ a year to just pay for itself, so waiting a couple of days for payouts shouldn't be an issue for people.  

I was not suggesting that Kano build something that pays out when people request the payments.  He doesn't want the responsibility of holding on to the coins and I 100% understand this.  I am sure for him the safest coins are ones he has already sent and he no longer controls.

As other people have mentioned, you can use something like Coinbase or Blockchain.info to consolidate your small payments and then withdrawal from there occasionally (rather than have Kano build this functionality).  I personally have not done this, but I don't think they charge fees to send coins with lots of inputs (last I checked at least they didn't).

Sorry for any confusion, at the time it was in response to people saying the pool is smaller than they want.  However, that chatter died off and it got changed into I was requesting a daily payout feature/consolidating payouts.  Sorry for any missing clarity on my part! Smiley
legendary
Activity: 952
Merit: 1003
OK...without the 27 quotes...

I was REALLY unclear about what I was trying to say...so apologies, and a couple of you got me to look at it at least.

The thought that came to me at the time (and I was not really awake) was the complaining about so long between blocks, and of waiting for payout until the next post-confirmation block is found. That's all.

If the payouts came daily (but that won't always happen, will it?) but were detailed as to which block rewards it was paying, I'd be fine with that. Bottom line with me is that I DO trust the op, and like the way he runs things...I think a lot more than many folks here. If I didn't I wouldn't be here.

Teaches me to not try to post any cogent thought at 0600 local with no sleep in the past 20 hrs, and even coffee isn't enough then.

 Kiss
legendary
Activity: 3234
Merit: 1221
I really don't get the need for lots of daily payouts.  A payout ever day, even every few days or so is fine.  Do people really need 10 small payouts a day?  I would rather get 1 large payout a day than 10 small ones.  If nothing else, it makes less work for the accounting.  
Agreed. I do not see any point for it, other than extreme insecurity perhaps. If one does not trust the pool operator to reasonably protect/hold the rewards until adequately verified, one should probably mine elsewhere...methinks. Additionally, it puts the miners' accounting load on Kano, where it doesn't belong...again, methinks.

But then, I've been occasionally told I think too much...methinks.  Kiss

Sorry, but do you have multiple personality disorder today? Cheesy That first paragraph first agrees with larger payments, then the second part disagrees with larger payments, because larger consolidated payments mean the pool operator running a wallet that holds those payments until they are ready to payout.

So do you agree with one large consolidated payment a day or not? Smiley I think for this pool it works fine without, all you need to do is have a mining wallet and a cold, or spending wallet, the mining income goes into the mining wallet, and every week or so you send the coins from your mining wallet into your cold wallet, which consolidates the dust for you. Then when you want to trade or buy something with your coin you do so from the cold/spending wallet and, if you use a reasonable sized transaction fee, that spend will go through alot faster than if you sent it from your mining wallet.
Interesting. I said nothing about size of payments. It was about frequency. I also said nothing about consolidation. However, I do have an opinion on it...I don't like it. I do my accounting traceable to the block, and I'd like to keep it that way.

Really? If you normally 5 small payments per day, but consolidate them into one payment per day then thats going to be a single larger payment surely Smiley The frequency of payments in this example is directly correlated to the size of payment.

Thanks for clarifying your stance, I'm not having a go, just that you surprised me as your normal position is one of someone who likes the way things work here, but your first sentence is agreeing with the OP saying that they'd rather have one payout per day rather than lots of small payouts.
legendary
Activity: 3822
Merit: 2703
Evil beware: We have waffles!
Gotcha.
Didn't look/know who runs it and ja I fully understand given the History between you 2 Wink
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
I think there may be a problem with the pool's time zone, at least for the shift timing. The shift timing states that it is in UTC, but:

The latest shift - 825j5 yuno - just started a couple of minutes ago and it states that it started at Mar‑12 17:08:27 (UTC). The time now is 18:15 UTC. It seems that the Pool is in UTC-1h timezone instead in UTC?
Shifts appear, are created, ~13 minutes after they finish.
The start isn't the unknown factor, it's the finish point that it has to wait until all the workinfo is complete/confirmed then it works out the shift.

Edit: and you can see that the shifts are all OK by the fact they all have a Start and Length, so the start of any following shift will be Start+Length

The Server time doesn't affect the web display at all, it uses UTC for all displayed time since people all over the planet look at it.
Internally, CKDB treats everything as UTC and the code all deals with converting the Postgresql dates to and from UTC.

Each web page, at the bottom right in small letters, shows what your browser thinks is your local time, and at the bottom left, what the server thinks is UTC time.
That also effectively shows any discrepancy between your computer and the actual time, after you subtract the network and processing delay for the page request.

Not that it is very important - the pool obviously functions, but this still seems off: The bottom left time on the webpage (UTC time) is generally 1-2h ahead of the (last shift start time), which if a shift is 50min (lets say 1h to keep it simple), should be only 0-1h ahead.
Check your clocks Smiley
The lower left on the web page is always correct Smiley

Shifts show "Start Time", so the last shift "Start Time" will be between "Length"+13 and 2xMax+13 minutes behind the UTC time.
2xMax = ~100
Jump to: