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

Yea, excellent...

We need to get this to 1PH this week...

Kano, can you update the subject line to 450? that might help draw in some miners, as slow pools take forever to payout.

Pool is switched over to the new server and I've updated DNS also.

If you are having DNS issues, or it's taking a long time to get the dns update, you can mine to stratum2.kano.is which points to the new server.

Thanks for your patience

Edit: ... and we've just passed 450THs.
I'll give it a day before I'll update the thread title since the rate seems to move around quite a bit.

All good mate, I just turned off one of my miners anyway, QLD power prices.. I cant be bothered with it anymore lol

Just a quick note to everyone while I frantically work on this.
The oversized VPS I was running the pool on, effectively died about an hour ago.
The problem seems to be all the VPS limitiations when we tried to push it up to around 500THs with over 768 connections.

The new server is already up and running - I've been testing it for a day - but I've not put the pool on yet - bitcoin and the relay network have been running on it since yesterday OK.
The limitation we've hit, means it's best to move over to the new server ASAP.

I'm doing that now, and unfortunately, while I do this, there is no pool

The pool will be back up soon exactly where it left off - it's not a data issue in any way at all - all the pool stats and information are all being transferred to the new server.

Sorry about this, but it will be back up soon.

Somewhat related to my comment above:
https://bitcointalksearch.org/topic/m.9294896

Basically, if the block was found at N = 1diff (100% luck) and you and the pool had the current hash rate they are now, for the whole 100% time, then that would be your payout.

The actual payout could be lower if you later dropped your hash rate before the block was found, or the pool hash rate increase before the block was found, or even higher if you joined during the current round and kept mining at your rate until the block was found but the pool hash rate didn't increase.

What the number actually is, is based on your % of shares in the current pool block - which isn't the PPLNS calculation - so it's just an estimate.
All sorts of things can affect the PPLNS calculation vs that number.
The main issue is that the PPLNS calculation has a moving end point until a block is found, so to get the calc accurate I'd have to adjust everyone's share count every time a share is found since shares are discarded off the end and affect both the total and each users sub total as shares run off the end.
The other option would be to completely recalc it each time, which seems expensive also.

There's still more work for me to do ...
(and probably will be forever more)

Edit: actually, what the value is, is the Prop payout if we were using Proportional (instead of PPLNS) and the block was found now.
But of course Proportional is something which no pool in their right mind should use to actually make payouts.

So, what does "at 100%" mean, on the "Workers" page, at the bottom where it says:


Does this refer to the "Block %" column in the workers table above, on that same page?

If so, it doesn't look like I'll ever get that payout cuz mine are nowhere near 100%...

Color me confuzzled.

thanks,

-dave

Even weirder - the Help menu on the right works on the iPhone, just the menus on the left don't.
Guess I better google that

yeah i get the same issue here with my iPad4 and iPhone6+

Hmm, guess I better get a hold of my daughter's iPhone and see what's up.
I've run it on FireFox and Chrome (on Linux), FireFox and IE on WinXP, and on my android phone (Galaxy S3) and those all work ok.
Also note that the hitbox is the words, not the whole menu box.
I looked at making it the whole menu box when I wrote the code to do the menu but then decided to put that on a todo list

Yeah I put "You're lost!" as the default web page on any web server I setup.
kano.is points elsewhere, so it gets that.

dns updated - it now points to the same place for people without 'w' keys
(the dns refresh is 1hr but ttl is 1day)

The database itself has all the info needed except the actual transaction.
Also if you check git, I only recently (last week) added code to ckdb to talk to bitcoind directly.
Up until now, all the information came from ckpool.
It now does the block confirming (or marking them as an orphan) automatically and checks your BTC address added on the web page is valid with bitcoind directly.

Shortly I'll add a command so I can send it a transaction number and get it to populate the payments table with anything in the transaction that matches any users.
So, no it's not there yet, but will be soon - very high on the todo list.

Multiple/Regional front end servers already works.

Currently the back end is a single server and I'm not sure how long until I get to changing that.
Things keep popping up that need to be done for the pool (and of course irl )

Distributing the back end is high on the todo list though.

Well, not sure if this answers your question exactly, but ...

Your accepted shares (A:) in cgminer should match the accepted shares at the pool.
The rejected shares (R:) in cgminer represents the invalid % on the pool.
Of course you'd have to have restarted cgminer when we found a block to get an exact match, but the delta-numbers should of course match.

Any other share counts in cgminer (Stale, HW:) are not sent to the pool so they wont count in the pool total.


Though, there is a secondary issue of course.
The issue of if the pool is reporting all users correctly.
e.g. I could set my hash rate (or the hash rate of a user I created that no one knows it's me) to be double what it is so that I get paid twice as much.
The only way to know if this might be the case would be if long term the pool block count vs. the pool total hash rate was low.
Though, if there was block withholding that would show up the same.
Unfortunately with a small pool (where this would have the biggest effect) the block count is pretty low so it would take quite a while to be able to tell.


Also note that I show the 5 minute hash rate in the top left and the pool stats, so it varies a bit more.
The worker stats shows the 5 minute stat until you've been connected for an hour then it switches to the 1 hour stat.


And of course, anyone curious about how it all works, the source code is in git.
I run the exact C code in there with only one change to stratifier.c and ckpool.c, the 0.9% fee and where it's paid.
The web is slightly changed to show the different payout info vs what git says - otherwise it's all the same.

I think you will find that is the expected performance increase associated with the CKPool software 

Is there a way to tell if a pool is skimming?  I'm just curious, because I've noticed a 5-8% increase in pool side hashing with this pool compared to where I was earlier. It's probably within anticipated variance, but still curious.

Oh and since you asked, (and while I'm whining about web-side bugs):


I can login to the website on my phone (repeatedly, compulsively, all day long, on the bus, in line at the mini mart, and oblivious to speeding vehicles while crossing the street), but clicking on menus does not work, the clicks are totally ignored.  Tried using the iPhone's built in Mobile Safari browser as well as Chrome for IOS [emoticon face=frowney] Same problem with both browsers on the iPad Mini too [double frownie-face].

Oh, and one other thing!  (This is more of a feature request than a bug report, but...)

Instead of telling me "You're lost!" when I type kano.is into my browser, could you correct that to say:


You might even add:


{insert wry, winking smiley here}

thanks, in advance...

-dave

Wow

    => Pool Hashrate: 226.86THs <=

Shaa... Weet.

Hey Kano, how come my payout isn't shown on the Account / Payments page?  You gonna make me start keeping my own records?  The IRS won't take "Kano never implemented that" for an answer, ya know.  Especially when the price goes TTM Real Soon Now!

thanks,

-dave, now all in, and pretty much constantly leaning on the refresh button all day at work while I should be ...er, working :-)

I've got a server on the west coast I can put this on ... as long as it's mostly pnp.

M

Do you have an ETA in which the software would allow regional servers to allow a more global system, even if not shared with other pool operators?

--->>>  We just past 200Th...  Lets get this up to 1Ph...

Heh - that's the same "quick and dirty" I use on the workers page
That of course is only correct if you have been mining at the same rate as the current block rate for one whole N in PPLNS when we find a block
(that's actually what that cryptic comment on the bottom of the workers page means )

I'll look into it for the address pages.

Been chasing around server suppliers ... now waiting on the new server to be configured up.

That "concept" is in the design - not implemented yet.
Basically as mentioned in the ckpool code thread, have a concept of pool siblings.
This will tie in to the multi backend code ... whenever I get to doing that.

In reality, in mining, there's no real "sharing" of work as such.
In this case it would just be the sharing of the block payout based on the amount of work done - so sharing the information about how much work is done, to share the block reward.
But that also requires trust.
Of course each pool will validate the work done by the other pool, so that will be one of the differences between absolute trust (multiple backends) and the sibling concept.
Basically, one pool would present it's hashes to another pool as a single user (for verification) and the other pool would payout that proportion of the hashes.
.. and the reverse for both.

This, of course, is simply a way of reducing variance.

Looks like we're past 180TH now