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

I do indeed still include full validation. All of the changes are in bitcoind on the validation side but they are all non-portable changes, and things that I have no interest in getting past the committee that is bitcoin development, and ultimately I hate to say it but we're running businesses here. I still indeed do full validation but I noticed the current emphasis on benchmarketing block changes so I figured I'd do everything possible - this includes my own variation of blank blocks on blockchange from bitcoind (no, not the patch you are using). I am almost certainly not going to leave it this way but I had set out to try and beat every fully validating node out there My bitcoind patches now are rather large.. it's as good as a fork.

Well, I'm not 100% sure what your bitcoind changes have to do with SPV mining or mining blank blocks... seems like if your changes indeed make bitcoind return work/GBT faster than or as fast as the blank block speed up that this would be a positive thing that would deter such optimizations.  If I could get a full template as fast or faster than I can make a blank one then of course I'd use the full template.

As for spam calculations, all public code as mentioned previously.  I've nothing to hide there.  You don't agree with some of it, but, that's your prerogative.  Not suggesting you use the bitcoind branch I use.  Use whatever you want... even XT if that's your thing.


*shrugs*  I don't care what Luke (or anyone else) says or does or doesn't say or doesn't do with their code/patches.  I review the code I run, regardless of who wrote it, before I run it... especially in a production environment.


I agree that ckpool is extremely fast in general.  It is a C-based pool software, so, it's going to be fast unless the devs are incompetent (there's probably a joke there somewhere).  It should be fast at this, but it is always limited by GBT responsiveness regardless of how fast it is after it gets a response.  Without at least some settings tweaks bitcoind is not even close to fast with GBT, though.

ckpool *does* wait for GBT to return before sending any new work to miners.  It literally can't start sending work faster than bitcoind gets a template.  So, the speedup is in the GBT return time.  The difference between connection counts will have an impact on end user work change times, regardless of what the pool software is, just due to the fact that the actual connection to the internet from the servers is done in sequence, not multicast.  Packets are sent to every miner, so one miner will get their packet out first, and one will get theirs out last.  Granted, the size of the pipe can make this a minimal delta, but it does exist and it does increase with connection count.  Eligius has about 4 gigabit available under normal conditions nowadays, so, work gets out very quickly and the delta between miner 0 and miner N is very small for the initial work update now.

So if you put a properly configured ckpool against a stock settings bitcoind and a properly configured eloipool against the same bitcoind, the eloipool instance would get block changes out to miners faster than ckpool every time since it'll do so based on the P2P block announcement from bitcoind and not wait for GBT.  You and ck have apparently made changes to bitcoind to mitigate this issue to the point where your pool is almost as fast as Eligius at block changes and ck's solo pool is somehow faster.  The latter is pretty impressive without the blank block speed up because it means that not only is GBT time next to nothing, the time needed to actually validate the block is next to nothing.  So, not trivial changes.

Last I checked antpool was SPV/HO mining, but it's been a while.  They lost quite a few blocks in the SPV fork mining on top of F2Pool's invalid chain a ways back.  On the poolbench they're way behind, so, probably not the case anymore, but not sure where your data comes from.  They're definitely not faster than Eligius, kano.is, or ck's solo pool.

Anyway, I've spent enough time on this.  Have fun with your pool.  If you ever decided to release your bitcoind fork, let me know.

Wizkid, our enhancements to bitcoind are not public and no we wouldn't be giving them out (as has been stated in the solo pool thread)
One of the reasons is that I certainly am not interested in supporting pools that SPV mine and mine 'empty' blocks.
So yeah not gonna happen
Seriously, I think what you are doing is bad for BTC and I wont help you do it.
I'll also add that your 'public' changes fall under the heading of something I wouldn't do either (I've not even bothered to look at them)
Most spam calculations used are self preserving.
How is spam calculated? What side effect is there of that calculation? The side effect will be to classify more transactions as spam.

The history of your pool dealing with spam and blacklisting would mean I'd not ever even consider 'adding' in whatever it is you do.
Luke-Jr likes to play word games and pretend a isn't a, it's b - everyone knows it's a, but he'll call it b anyway - and he does that with his patches also.

--

As for the speed of the solo pool - no that's nothing to do with the amount of work to send out.
ckpool sends out work exceedingly fast due to the code.
oh and I guess you used to know, but the whole ckpool/ckdb code I run on the pool is here:
https://bitbucket.org/ckolivas/ckpool/src

The only change I make to ckpool is (of course) the payout addresses - they are, as anyone can see, 2 other addresses with a different ratio.

The time to send out work is not multiple seconds.
Solo is faster than kano.is due to -ck making more optimisations in the poorly written btcd-core code than I use.
His block changes are faster than mine on his low end server vs my ... much better ... server.
His worker counts aren't really all that much smaller than mine, not an order of magnitude smaller.

I've also tried mining with a USB miner to antpool to compare, yep it gets work really fast even to way over here in Aus ... to that very large pool with lotsa lotsa workers ... ... ...

It's a pretty bright green block!

Well, this stems way back to before I ran the pool.  eloipool never verified anything about usernames or passwords (it has modules to do so now, but didn't before), it just validated work and sent it to a database for parsing by whatever reward code you wanted.

Today, I leave this alone because it's been a long term well documented method of just donating to the pool.  Connect to Eligius with whatever username you want (people come up with some fun ones too, with today's favorite: "wizkid_keep_up_the_good_work") and the work gets donated (under the normal reward system rules as if I had simply mined myself).  So, I have no reason to change it.  Since Eligius has no accounts, per se, it makes things simpler.

Rarely I'll have someone contact me about it if they messed up and were mining with an invalid username.  If they mined a non-negligible amount I do some verification to make sure they're not trying to scam me and then manually pay them.  If they only messed up for a short period of time with a dust-like trivial amount of reward.... well, suck it up buttercup, you should have read the whole "use a valid bitcoin address as a username" thing.

Eligius's back end is designed in a way where even I can't move rewards from one miner to another, which is a great internal security feature.  So if a miner mines with an invalid/donation username, there literally is no way I can move those shares to another username... short of a complete rewrite of the reward system code that undermines the current secure methods.  

Anyway, we'll never agree on this point, but given that it's a documented behavior that many use for donating (some actually use it with *gminer's load balancing to donate a % continuously) I see no reason to change it.  Your way works fine, as does mine.


I don't need alerts.  Eligius hasn't had 1 second of unplanned downtime on the pool side in something like a year.  (And less than 2 minutes of planned down time in the same period)

Not sure how I can prevent miners from jumping to backup pools... sounds like a miner-side configuration thing to me.  Surely if they have backup pools configured and Eligius goes down they'll fail-over.  I don't care either way about that.  Their business, not mine.  If Eligius is accepting their shares I don't know why they would need to fail over... and if they're submitting loads of rejects, sounds again like a miner side issue.  Pretty sure I have little control over if they have backups configured or not.

In seriousness, I do have many alerts setup for all sorts of things.  There are even some remotely monitored security conditions that will remotely cut power to all of Eligius's servers in the event they're triggered (hasn't happened).  As for alerts for other issues, I do have quite a few alerts that happen when things go badly.  First is an email notification, then an SMS notification, then a VoIP phone call with the asterisk chick saying, "Something is terribly wrong!" over and over.  If those all fail somehow, a super annoying sound clip is played through a few devices, some pretty loud much to the displeasure of my wife.

But do keep in mind that bitcoin related things are not my full time job.  I have a real day job (granted it's mostly telecommute these days, but still), so I can't always be interrupted by something in bitcoin land.  Keep in mind that my pool is no-fees run by volunteer work (almost exclusively me these days) and donations.  Not that it actually is in reality, given the stability record, but I think my SLA is allowed to be a little more relaxed than say, a pool earning ~$400/week or more in fees.


Are the patches you run public?  I'd glady try them out.  If your bitcoind patches are sane and faster than mine I'm not against giving them a whirl.  Everything I'm running on the bitcoind side is actually completely public.  Nothing secret there.  "Questionable" is... questionable, but that's another debate.  But I'm not married to the branch I run.  If there is a better and faster one that doesn't cut any validation corners then that's what I'd run.

GBT is in fact pretty slow with all default bitcoind settings, that's for sure.  Even on a monster of a server with nothing running an all default setting bitcoind will take 10s of seconds to return GBT at times, especially at block changes.  You know the default dbcache setting for bitcoind is only 100MB?!

I think you might have me mixed up with someone else on the 1 tx block issue.  I don't think the 1 tx block speedup is *needed* to get work out quickly, but it is a valid speedup method that adheres 100% to all rules of the network.  We'll never agree on that for whatever reason, but the good thing is we don't actually have to.

And yes, I've noticed that the solo pool has been slightly faster than Eligius and kano.is.  I chalked up the difference to miner connection count differences (solo pool would have the lowest, followed by kano, followed by Eligius), but if there is a valid branch of bitcoind permitting the speedup while retaining full validation, I'm all for it.

Yeah that at least fixed the last 2 weeks (10 blocks) luck

  WOW the next Block!

The return of the Luck

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

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.

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

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://bitcointalksearch.org/topic/m.13072502

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

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

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

Nice block there by ... incognitomisquito
With 4THs

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

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.

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

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!

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

I'm definitely in the wrong business.

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