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

[Nuttycoins]

Hey gang:

New here from E.   Do like how it is setup.

My question is why can't you seem to grow the pool more?

Is it the slow ramp up?  That would be my guess especially with the small pool size.

I am going to be adding about 7.5 more T this week, and other then the few big boys I will not be that far from top of the list.  I know it all balances out but sure would be nice if it was 4 or 5 times larger.  Capturing more of these S7ss like mine coming online sure would be nice.

[1714830491]

1714830491

[1714830491]

1714830491

[1714830491]

1714830491

[1714830491]

1714830491

[1714830491]

1714830491

[1714830491]

1714830491

[wizkid057]

See, the Eligius guys a lying and the reason they delete my posts is they don't want people to post the truth about them in their thread.


Post deleted by wizkid in the Eligius thread a few minutes ago:

Feel free to tell organofcoorti that he doesn't know what he is talking about regarding "Eligius orphan rates" and that your statistical analysis of orphan rates is correct and he is wrong.

http://organofcorti.blogspot.com.au/2015/11/november-8th-2015-mining-pool-statistics.html

Orphan rates at Eligius tend to be high anyway - about one percent the rate for other pools (2.3% over the last 52 weeks as opposed to the average of 1.3%).

Orphan rates (and lost blocks) are the only factors that have a controllable element that can affect pool luck.

Orphan rates are a direct result of 2 things:
1) Block distribution times
2) Block change times

Those 2 are very much related.

As mentioned in my post, if your next post wasn't an apology I was going to delete it.  No lying there.  It was too long to be an apology, so deleted without reading.

Anyway, since you're going to just troll Eligius regardless...

I'll write to organofcorti about it.  Based on my bitcoind data his information is simply not getting the whole picture or pools are not reporting all of their stales or something, and I'll happily share my data with him proving the network wide orphan rate is higher than 1.3%.

I love how you ignored every other point in my post, further proving my points.

I'll await deletion of this post, further proving your trolling.

There was no point trying to argue with anything else you posted.
My post includes facts from someone else that most people realise does know what he is talking about.
You seem to have a major difficulty understanding statistics.
My deleted post is the basis of showing a lot of your long ramble complaining about me is false.

You've deleted valid and true posts by me before, so there's no point expending effort on your post but a basic fact that shows your Eligius post is full of shit

Also, I've no idea why you want me to be your stalker. Sorry, I'm not interested in that.

I've been posting in most pool threads for 4 years pointing out the scammy things they do.
Feel free to post in my thread and point out all the millions of scammy things I do

One of the few reasons why I started a pool was coz there was so much crap and lies going on about pools and payouts.

lol.  Well, I have written organofcoorti regarding the network wide orhpan/stale rate.  Perhaps he'll comment, perhaps not.  The fact is that his stat is actually incorrect because the network wide stale block rate is much higher than he shows.  Feel free to verify on your own.

As for your scammy things you do, honestly, I don't care.  You can scam your miners for every satoshi, or not. Hopefully not, and I'm not implying anything.  Makes no difference to me.  I don't mine here, and people will vote with their miners.  All I know is that you do your best to troll me and Eligius.  I can't post anywhere on this forum without you following up with some smart ass comment that bashes me or my pool unnecessarily.  I mean in all seriousness, can we call a truce on this or something?  I think we'd all be better off spending our time on more important things.

If I had time to go around trolling like you, I'd go around making it a point to ram it down everyone's throats that CKpool is already scamming some miners with its vardiff implementation.  Admittedly, it's not much, but it's provably > 0.  I don't think you'll find any posts from me on the subject.  Why?  It's not really my problem.  Others have already pointed it out, so nothing worth adding on the topic.  Why waste my time?

And here we go with the twisting of words.  Please explain how you got:

Also, I've no idea why you want me to be your stalker. Sorry, I'm not interested in that.

from

You follow me around this forum like a stalker and there is very little I can do about it, unfortunately, and it's really f*ing old.

Is English your first language?  If not, I'll give you a pass.  If so, then I'll just go back to my point that you like to twist things to fit whatever your purpose is, regardless of the facts.

Anyway, I'll not derail your thread any further.

If we're going to be civil here, I am actually a little curious how you're able to be just behind Eligius in the block change timing benchmark with ckpool, though, given that ckpool has to wait for GBT to return before it sends updates.  Have you modified bitcoind in some way to make GBT return faster?  Raised your relay fee to something a bit above average to make bitcoind do less work?  Honestly, just curious.  I know from a technical standpoint, all things being equal, ckpool *should* get the new work out to miners faster than eloipool, assuming eloipool is not using the blank block speedup.  I just don't see that gap being so small without some modifications.  I'm actually using a custom made proxy between bitcoind and eloipool for my speedup.  Admittedly, the ckpools would probably move to the top with the same setup due to the whole C vs python thing.

[sloopy]

CKpool is already scamming some miners with its vardiff implementation.  Admittedly, it's not much, but it's provably > 0.

I pulled this from the post above from wizkid.

Please point me to the proof this is being done by ckpool.

[kano]

OK I'll ignore most of wizkids last post other than to point out that firstly, you've made your troll post about ckpool before,
and secondly, as I said last time, it's -ck you are trolling there not me.

Now regarding your ckpool trolling:
In stratum, difficulty isn't part of the work.

The only way to force a difficulty change to a miner is to make all it's current work stale, but after a difficulty change.
Yeah that's called ripping off the miner unless it's necessary.
Making work stale is only necessary on a block change, since of course any work they have for the previous block is stale and the new block change work (after the diff change) says that the old work is stale (clean_jobs)

But there's the (hidden) problem that doesn't really exist ... what work is valid with the new difficulty?
The stratum answer is: that all work sent, after the difficulty is sent, is valid on the new difficulty.
So the previous work is valid with the old difficulty until you no longer accept the previous work.

What does this solve:
If the miner is mining at 1000 Diff and gets a 1,000,000,000 diff share with the current work, it's still (correctly) only worth 1000 Diff.

If on the other hand, you allow a diff change to affect old work, then the miner could get a 1,000,000,000 diff share, then send the pool a request to change the difficulty up, and then get paid more for that share.
Yep that breaks the stratum rules.

.
.
.

However, most importantly, If your pool can't stop playing with the miner's difficulty then that's a problem with your code that deals with adjusting the miner's difficulty.
Get it right early on and then don't change it unless their hash rate changes drastically.
Edit: ckpool can take 2 or 3 quick diff changes early on to get a good diff value, then doesn't change it for days/weeks - it's the most stable vardiff implementation around

[wizkid057]

OK I'll ignore most of wizkids last post other than to point out that firstly, you've made your troll post about ckpool before,
and secondly, as I said last time, it's -ck you are trolling there not me.

Now regarding your ckpool trolling:
In stratum, difficulty isn't part of the work.

The only way to force a difficulty change to a miner is to make all it's current work stale, but after a difficulty change.
Yeah that's called ripping off the miner unless it's necessary.
Making work stale is only necessary on a block change, since of course any work they have for the previous block is stale and the new block change work (after the diff change) says that the old work is stale (clean_jobs)

But there's the (hidden) problem that doesn't really exist ... what work is valid with the new difficulty?
The stratum answer is: that all work sent, after the difficulty is sent, is valid on the new difficulty.
So the previous work is valid with the old difficulty until you no longer accept the previous work.

What does this solve:
If the miner is mining at 1000 Diff and gets a 1,000,000,000 diff share with the current work, it's still (correctly) only worth 1000 Diff.

If on the other hand, you allow a diff change to affect old work, then the miner could get a 1,000,000,000 diff share, then send the pool a request to change the difficulty up, and then get paid more for that share.
Yep that breaks the stratum rules.

.
.
.

However, most importantly, If your pool can't stop playing with the miner's difficulty then that's a problem with your code that deals with adjusting the miner's difficulty.
Get it right early on and then don't change it unless their hash rate changes drastically.

I don't believe I've posted on this particular issue with ckpool before.  Maybe I did, but I don't recall doing so here, only on IRC.  The issue I definitely mentioned previously on the forum is that ckpool doesn't create new work until GBT returns, which could be a problem with latency with a taxed bitcoind or whatever else would lag out GBT.

Anyway, your post appears mostly correct, except it doesn't tell the whole story.

While yes, if a miner is mining at difficulty 1,000 and finds a difficulty 1,000,000,000 share, they should be rewarded at difficulty 1,000.

With stratum, the pool sets the difficulty to 'X' and gives the miner some work.  We'll call this work 'A'.  The miner continues to work on that work at difficulty 'X' as long as it's valid.  Now lets say the miner slows down (variance, lost a worker, whatever... it happens) and the pool adjusts the difficulty downward to say, 'X/2'.  Soon after, potentially immediately, the pool sends a work update (NOT a restart, just an update).  We'll call this work 'B'.  The miner is still allowed to submit shares based on work 'A' for some time (as an example, Eligius allows this for 120 seconds).

Now the correct process is that work done and submitted based on work 'A' must meet or exceed difficulty 'X' and be rewarded to the miner at difficulty 'X' and work done and submitted based on work 'B' meet or exceed difficulty 'X/2' and be rewarded at difficulty 'X/2'.  With me so far?

Here's where ckpool appears to screw this up.  If the difficulty adjusts downward like in the above scenario, work from work 'A' is then rewarded at difficulty 'X/2' instead of 'X', even though the work meets or exceeds difficulty 'X' as defined for the work originally.  (If the difficulty adjusts upward, then ckpool appropriately accepts work done.)  So, for the short period miners are still working on work from work 'A' after the difficulty change and potentially before the pool even gives them work 'B', they're being shorted by the difference and this can last for as long as the miner continues to work on work 'A'.

Again, these are without work clears/full restarts/etc.  Also, again, admittedly it's probably not very much of a problem, and I expect eventually someone will fix it, but it is there.

@kano did you catch my question at the end of my last post?

Edit:

Edit: ckpool can take 2 or 3 quick diff changes early on to get a good diff value, then doesn't change it for days/weeks - it's the most stable vardiff implementation around

You're probably right.  Admittedly, eloipool's implementation works great as well when in arbitrary difficulty mode, but has some weak points when using only powers of two when it tries to pick a difficulty that is on the borderline.  I get around this by just bumping everyone's up one notch.

Edit 2: Typos, quotes for clarity

[kano]

Hey gang:

New here from E.   Do like how it is setup.

My question is why can't you seem to grow the pool more?

Is it the slow ramp up?  That would be my guess especially with the small pool size.

I am going to be adding about 7.5 more T this week, and other then the few big boys I will not be that far from top of the list.  I know it all balances out but sure would be nice if it was 4 or 5 times larger.  Capturing more of these S7ss like mine coming online sure would be nice.

Heh growing the pool, in my opinion, means getting sizeable miners, yeah like you are bringing in here
Attracting lots of small miners doesn't help grow the pool.
I don't enforce any policy of telling small miners to go away unless they are complaining about small payouts due to having small miners ... or dissing the pool coz they don't understand how PPLNS works

There's a few sizeable miners we have contact with, but I guess the standard issue is that most want a larger pool ... chicken and egg problem (or catch-22 if you prefer)
Simple fact, variance is higher on a smaller pool.

Also I don't lie about the pool's performance, or about what to expect, to attract miners.
The web site is all very cut and dry facts about how the pool is performing.
It has very good stats about that

Also of course there's quite a few people who I've pissed off in the BTC world ... and I'm not apologetic of that.
I see people doing shit to the BTC ideals, I respond ... usually in an unfriendly way ...

I'm not in a jet flying around the Bahamas sipping Martinis and telling everyone on facebook how things are OK even if the pool was getting shit orphan problems for days
I'm not telling the miners to faithfully believe that everything is all right even if all the stats show it really hasn't been OK for years ...
I'm not pushing out empty blocks of no new transactions into the BTC blockchain with the false argument that we must do that ...
I'm not SPV mining and using the excuse of the GFW connection to the rest of the world as my reason ... even though more than 50% of the pool peer 2 peer network is behind the GFW so that's to the advantage of any pool inside the GFW ...
I'm not blaming bitcoind for mining empty blocks when the pool code does it (yeah he changed that on his pool some time later quite a while ago) ...
I'm not running multiple high hash rate pools to try and hide how much of the BTC network I control ...
I'm not trying to get everyone in the world to buy my light bulbs and spend a little extra in their electricity bill and ... give it to me ...
I'm not trying to take over bitcoin core by force coz the democracy of bitcoin development doesn't allow me to do that ...

Hmm did I miss anyone in the bitcoin world?

--

Oh payout finally got confirmed:

Payout 385834 sent 4 hours ago
e5057eb4fd082727d9e28eee7ae7bb8a8be1bff40545aada1c88b24bc93bb181
and confirmed 10 minutes ago

[wizkid057]

I'm not in a jet flying around the Bahamas sipping Martinis and telling everyone on facebook how things are OK even if the pool was getting shit orphan problems for days

Wait, I know which ones are for me, but who is this one directed at?  Definitely not me... I don't use Facebook and have never been to the Bahamas.

We must be in the wrong business...

[kano]

I'm not in a jet flying around the Bahamas sipping Martinis and telling everyone on facebook how things are OK even if the pool was getting shit orphan problems for days

Wait, I know which ones are for me, but who is this one directed at?  Definitely not me... I don't use Facebook and have never been to the Bahamas.

We must be in the wrong business...

I'll not hide it if it's not obvious
Slush

[wizkid057]

I'm not in a jet flying around the Bahamas sipping Martinis and telling everyone on facebook how things are OK even if the pool was getting shit orphan problems for days

Wait, I know which ones are for me, but who is this one directed at?  Definitely not me... I don't use Facebook and have never been to the Bahamas.

We must be in the wrong business...

I'll not hide it if it's not obvious
Slush

Hmm... 40Ph @ 2% fee = ~$2k per day for him.  No wonder he's off in the Bahamas.

I'm definitely in the wrong business.

[AJRGale]

I'm not in a jet flying around the Bahamas sipping Martinis and telling everyone on facebook how things are OK even if the pool was getting shit orphan problems for days

Wait, I know which ones are for me, but who is this one directed at?  Definitely not me... I don't use Facebook and have never been to the Bahamas.

We must be in the wrong business...

I'll not hide it if it's not obvious
Slush

Hmm... 40Ph @ 2% fee = ~$2k per day for him.  No wonder he's off in the Bahamas.

I'm definitely in the wrong business.

Oh Damn! I cant even pull that in 2 months!

Right, where in Aus can I get decent net to run a pool?! Also need to advertise too.. and maintain the ... Bugger it, I'm happy where I am!

[kano]

...
Edit 2: Typos, quotes for clarity

Don't worry, I'm not gonna delete your post

The recent (rare) time I deleted someone's post in here was 5 trolling post about an obvious issue on all pools
... that I then posted that I deleted his posts and explained what happens when network difficulty changes ...

Anyway, just save wasting space repeating it.

...

So you're saying an up diff works correctly (is delayed to the next work so avoids gaming the diff as one would hope)
but the down diff occurs early ...

OK I'm surprised by that, since yeah the gaming issue came up not that long ago and no code changes were done since it was OK.
... though -ck isn't interested in responding to your post above since you directed your barrage at me before ... also at him ... and he doesn't "want to get dragged into this"
So that's prolly not gonna get answered by him.

I'll point out something that I guess you've completely missed.
CKPool is actually '2' parts (well it's more than '2' but there's only one demarcation line)
The mining code is almost all -ck's
The database and web is almost all mine.

Now just in case there's some misunderstanding about what the database is in ckdb, the backend of it is postgresql
However, that's only used for:
1) Storage of permanent data that cannot (or would be too slow to) be regenerated/reloaded at startup.
2) One tiny 'nextid' idcontrol table so that's always correct no matter what - and isn't very active
(and it doesn't matter if it skips values - it would only matter if it got duplicates)

The rest of ckdb is a memory resident redblack tree database ... I wrote from scratch ... 20 years ago and still working on it today
So yeah I don't really get all involved in lots of changes to ckpool, since I have this side of things to look after (and all the web site)
The ckpool side is not something I can't do, it's more something I avoid if possible.

So my point is that I'll add to my todo list in the distant future to look into it if that is the case and change the "if", if there is one, that does it.

However, the size of the effect of that will be tiny.
Firstly, a new work item will occur, on average, under 15s after the diff change.
Secondly, diff changes are rare if ever on ckpool - only during startup - or once in a blue moon later on.
So if it 'was' getting it wrong in half the diff changes, it's gonna have a tiny effect for not very long (the share diff will of course be the dificulty delta, not the absolute difficulty)

At this point I could bring up one or two things you do that are specifically by design, but I've already done that in your thread and you have said - bad luck that's how we do it.

However, in this case, as I said above:
1) it's piss worth of nothingness
2) I'll look into it some time in the next eon

[wizkid057]

...
Edit 2: Typos, quotes for clarity

Don't worry, I'm not gonna delete your post

The recent (rare) time I deleted someone's post in here was 5 trolling post about an obvious issue on all pools
... that I then posted that I deleted his posts and explained what happens when network difficulty changes ...

Anyway, just save wasting space repeating it.

...

So you're saying an up diff works correctly (is delayed to the next work so avoids gaming the diff as one would hope)
but the down diff occurs early ...

OK I'm surprised by that, since yeah the gaming issue came up not that long ago and no code changes were done since it was OK.
... though -ck isn't interested in responding to your post above since you directed your barrage at me before ... also at him ... and he doesn't "want to get dragged into this"
So that's prolly not gonna get answered by him.

I'll point out something that I guess you've completely missed.
CKPool is actually '2' parts (well it's more than '2' but there's only one demarcation line)
The mining code is almost all -ck's
The database and web is almost all mine.

Now just in case there's some misunderstanding about what the database is in ckdb, the backend of it is postgresql
However, that's only used for:
1) Storage of permanent data that cannot (or would be too slow to) be regenerated/reloaded at startup.
2) One tiny 'nextid' idcontrol table so that's always correct no matter what - and isn't very active
(and it doesn't matter if it skips values - it would only matter if it got duplicates)

The rest of ckdb is a memory resident redblack tree database ... I wrote from scratch ... 20 years ago and still working on it today
So yeah I don't really get all involved in lots of changes to ckpool, since I have this side of things to look after (and all the web site)
The ckpool side is not something I can't do, it's more something I avoid if possible.

So my point is that I'll add to my todo list in the distant future to look into it if that is the case and change the "if", if there is one, that does it.

However, the size of the effect of that will be tiny.
Firstly, a new work item will occur, on average, under 15s after the diff change.
Secondly, diff changes are rare if ever on ckpool - only during startup - or once in a blue moon later on.
So if it 'was' getting it wrong in half the diff changes, it's gonna have a tiny effect for not very long (the share diff will of course be the dificulty delta, not the absolute difficulty)

At this point I could bring up one or two things you do that are specifically by design, but I've already done that in your thread and you have said - bad luck that's how we do it.

However, in this case, as I said above:
1) it's piss worth of nothingness
2) I'll look into it some time in the next eon

Well, glad you'll check into it eventually at least.  I did mention that it is a small problem to begin with and that's why I haven't bothered pursuing it.  As for who wrote what in ckpool/db... *shrugs*

I'm curious what things I do by design that are a problem, though.  I'm all for fixing issues.  Block change times weren't really an issue for most before, and they definitely are not now.  The 1 tx block speedup is just something we're never going to agree on (although I think ckpool would be amazingly fast behind my new bitcoind proxy).  What's left?

Edit: I'm genuinely interested.  If you have some actual technical information that's not the equivalent in usefulness of "your pool sucks" or "you know luke-jr" or whatever else, I'm all ears.  Feel free to PM or post in my thread (assuming civility) so as not to derail this thread further if you prefer.

[kano]

Well the last one was keeping BTC for miners who make a mistake connecting, instead of not allowing them to mine or failing over to their backup pools, coz some of them did it on purpose ...

I had a miner do that yesterday.
They didn't create an account for their username, there was no username even slightly similar, it wasn't an address miner of course, and they kept connecting to the pool and being rejected.
I actually think it was trying to be annoying based on the username ...
In the end (having done all the checks possible about if it was someone/an IP I've seen before) I simply permanent banned their IP address from mining.
End of story.
If I had enabled them mining, I would have had to hope they would one day contact me and then I could give them access to the account ... ... ... or I block them (mining) up front and if they wanted to mine they'd contact me pretty quickly.

I've also seen times when you don't allow miners to failover to backup pools when their mining with you is on stale work, I guess in fear of them mining somewhere else? ... ... ... or no notifications waking you up at night if there's a problem with the pool? ... ... ... or assuming the miners at your pool are morons and don't have backup pools?
... yeah I even get a wakeup alert if the work doesn't change for 50 seconds or no one submits a valid share for 40 seconds (and many other more drastic issues) ... yeah those numbers are a very long time in terms of data ... but less than a minute and I get an alert

--

Anyway, on the btcd side, you'll notice that the solo pool is faster than your pool
(and has been, except for a few times in the last 2 days due to 0.12.x master failures)

My main btcd is very fast and has been for quite a while due to changes that use the internal prioritisation, no blacklisting and no questionable secret/or otherwise "spam" filters.
It's funny how people have said that GBT is slow due to my misconfiguration of it ... it's not slow itself, that's my fault ...
Yet those same people seem to think that they NEED to bypass it on block changes to get fast ('empty') work out and thus reducing the txn throughput limit of the BTC network by a few % is fine ...

[kano]

Nice block there by ... incognitomisquito
With 4THs

[yxt]

Over what timeframe is the Hash Rate (worker-worker page) calculated?

I searcjed the topic but could not find anything
Unfortunately, many information are scattered throughout the topic.
Would be good to collect them centrally

[winspiral]

Congratz

But it is frustrating because I do not undertand why sometimes (on my CMD window shares are accepted every few minutes ans sometimes only every 30 minutes...

and suddently is is so:

with shares accepted

[kano]

Because it says there that you are being given 1042 diff work.
If you don't stay connected to the pool, your work diff will be 1042 when you next connect.
Read up about difficulty. This was discussed here:
https://bitcointalk.org/index.php?topic=789369.msg13072502#msg13072502

Edit: yeah then the difficulty dropped after 3 shares ... down to 42.

[kano]

Over what timeframe is the Hash Rate (worker-worker page) calculated?

I searcjed the topic but could not find anything
Unfortunately, many information are scattered throughout the topic.
Would be good to collect them centrally

If the miner has been connected for less than an hour, it's the 5minute hash rate.
If the miner has been connected for an hour, it's the 1hr hash rate.
https://bitbucket.org/ckolivas/ckpool/src/0635c75560ee1823650d81008da2385f69843624/pool/page_workers.php?at=master&fileviewer=file-view-default#page_workers.php-57

[winspiral]

Because it says there that you are being given 1042 diff work.
If you don't stay connected to the pool, your work diff will be 1042 when you next connect.
Read up about difficulty. This was discussed here:
https://bitcointalk.org/index.php?topic=789369.msg13072502#msg13072502

Edit: yeah then the difficulty dropped after 3 shares ... down to 42.

so if I understand...i have certainly unknown broken connections...with the pool or with internet in general...

No easy to be a miner (and understand it)

Addition:
thanks kano...i understand better now.

[kano]

Because it says there that you are being given 1042 diff work.
If you don't stay connected to the pool, your work diff will be 1042 when you next connect.
Read up about difficulty. This was discussed here:
https://bitcointalk.org/index.php?topic=789369.msg13072502#msg13072502

Edit: yeah then the difficulty dropped after 3 shares ... down to 42.

so if I understand...i have certainly unknown broken connections...with the pool or with internet in general...

No easy to be a miner (and understand it)

You don't lose anything, you just have higher variance.
If you mine at 42 diff, you'll average (over time) one share every N seconds
If you mine at 4200 diff, you'll average (over time) one share every 100xN seconds

42/N = 4200/100N