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

Ah! Of course, no problems then. 😊

from freenode#ckpool:

ie. https://blockchain.info/tx/d8b4c28e2ecbba639a14a280511ddf985445da2e9374363c9fcc66b22b54dfe9 needs to reach 100 confirmations before the coins are spendable/distributed.

QG

Hi Kano, when do you expect to do the payout for the last block? Have you already done it? (just checking I've got my account set up properly)

Yep next block now with 4 confirms and counting ...
The total was just under 100%
The orphan makes it only just over 100%
And the overall for the 2 blocks (including the orphan shares) is now 78.31%

Edit: and I'm of course referring to shares vs average expected for each block in case anyone was unsure
That's what the Blocks page shows.

now let's see my 3 U2 hit a block on the solo pool  ha ha ha ha.

Estimate another 3 days 18hrs at this rate to hit the next one.  I'm going with less.   Always the optimist.

Luck seems to be good here.

M

Did we just now?? Did we, Did we...... YEAH!!!

Yep, wanted to see it would stay there for a few hours and it has.

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.