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

It's all in the public code in git (just thought I'd mention that in case anyone was wondering) but how remote nodes work (and why):

The main pool - in Vegas - generates all work sent to all miners. Always.

Without a node, it does the obvious - sends you new work after a block change or 30 seconds, and when you send shares, it decides if they are stale based on the work vs the current network block (and also a time limit in minutes)
If it's a block, ckpool sends it to a local bitcoind.

Nodes: they run sorta like a proxy with local block submit, but have a trust level, so no one but me can point them at the pool.
What happens is the miner's work from Vegas is sent to the node then forwarded to the miner - just like a passthru proxy.
Thus the work change time, vs directly connecting to Vegas, will depend on the trip time from Vegas to the node then from the node to you - vs your direct trip time to Vegas.
If you are a lot 'closer' to the node, or on the 'other side' of the node, then that's no real loss i.e. no real difference - so that's good.
If your path to Vegas is unreliable or slow, then the nodes path to Vegas may also improve the overall path noticeably.

However, the gain to be had with nodes:
The time you submit your share to the node, is the time Vegas uses to decide if the share is stale or not.
Why? Because the node submits blocks directly to it's local bitcoind (and to the fibre network)
So if your share is a block, it will be submitted immediately, not waiting until it gets back to Vegas.
Thus nodes reduce the stales on submitted shares, if you are closer to the node than to Vegas.

i.e. there's 2 effects. The work change and the share submit.
They can work together to make it better for your mining if you aren't closer to Vegas.
But if you are between Vegas and the node, it can slow down your work change, but speed up your share submit - depending on your ping and internet routing.

What version of bitcoind that is running on the node, has no real effect on why you'd use a node, since nodes don't generate work.

In principle, agreed...but unfortunately that has not been the historical record... 

Or, one could just accept that the manufacture might know a little more about what the right speeds are...

Care to show us how?

Why not just hack the cgi and unlock your fan setting?

Everything is running the same code. It is just another node to connect to. For those further from the main server in Nevada it helps reduce stales.

So what is Las Vegas Running as opposed to New York.  I live closer to Las Vegas so that would seem like the obvious choice and my latency is 48ms  while my latency is 63ms to NewYork.  If New York is running more up to date code 13.1, would it make sense to point my miners that direction despite the slight increase in latency?

Just a quick thank you, Kano, for NYA node. Switched over 2 days ago and am seeing better ping times and reduced error rates. Encourage those on or near US east coast to test the node. Thanks again!

Well yeah but also - he was implying there was something wrong with the block itself.
That's clearly false - blockchain.info accepted the block and even saw it before the other.
He's just making up crap that doesn't even match facts - I think I'll just delete his post - it's bullshit anyway.

The fuck up in my segwit code was purely on my part with the solo code which is different to the publicly released ckpool code. Additionally the solo code fuck up didn't even generate blocks so there's no way they can even become orphans which are otherwise valid blocks.  Kano doesn't have access to the solo ckpool code and the kano.is pool has not changed its ckpool code in many months; it currently does not have any support for segwit, and as most people on this thread are well aware, Kano himself is against segwit so would only adopt newer code if segwit actually activated. Your fears are unfounded.

It looks like one of the S5 I have in a remote DC died.
Lost 1 board 3 days ago (half hash rate) and lost connection to it yesterday...

So 1 S5 and 1 S7 remain pointed to Kano until I can get it restarted by someone or have a look at it...

BTClock! by btccro with 227.19THs! First Block Today!

And another one that bought a Lamborghini Countach and wants to turn it into a VW Beetle 

wow that's insane, all the BTC invested in those s9's, glad I did not get any

Well after checking options with the. 2 and 1/3 s9 old firm ware gear.

Upgrade to auto tune will make them too loud.

We moved them all from the solar loft and put them in buysolars basement for heating.

So we have to run fans at 50 % and set freq at 525.

Thus auto tune won't be viable for about 120 days.

It is pretty clear to me the old firm ware sucks at block finding.

Kane's stats show it.

And the guy that spent 325 btc solo mining  on nice hash with far better luck at .01 or 10 th settings.

(No s9s at that setting). Really indicate the old s9 firm ware sucks.

Soooooooo we will point the 27th at f2pool.

And keep the avalons pointed here.  13th

If your setup forces you to lower fans and not use auto tune I guess f2 pool should suffer. For it not kano