Heh funny about all that merit you got - even the mod who doesn't follow the forum rules unless he's told to
Firstly, you've been on ignore for a long time, so I never read your posts.
The only reason I read it was all the merit
Fun fact, all this information about my pool configuration is available in many posts I've made in the past in detail
That being: the pool has nodes all over the world, working on accepting shares and distributing blocks as quickly as possible.
The nodes themselves submit blocks to the bitcoin network as soon as a share, that is a block, arrives to them from the miner.
The share is of course also sent back to the master server where ckpool and KDB both process it (KDB accurately, unlike ckpool) and they both submit the block also.
ckpool also sends the share to every other node to do the same block submission.
This point also was completely confused in the Laurentia white paper - mfb clearly does not even understand ckpool.
His paper says he uses ckpool without this advantage, that some of the 137 BTC I gave -ck covered the cost of adding.
Of course the current ckpool git doesn't work with AB blocks but I fixed that in my copy when I first did all the AB testing before putting the AB changes live.
Secondly, you are, like phil did, simply trashing -ck with most of this comment.
As I've pointed out here:
https://bitcointalksearch.org/topic/m.54855598Now there's probably also some explanation necessary since I'd guess you don't understand what's meant by 'lost' blocks in all this discussion.
Your comments about not even caring if you find blocks or not, are alarming at the least, so I doubt you understand the various issues with finding blocks.
By 'lost' I specifically mean lost by negligence and code bugs.
In these cases, the miner may know it found a block, the pool will get the share that represents a block, but the block was not sent out to the network when it should have been or not sent out at all, due to a code fault or in the most recent cksolo one, server management negligence.
There are of course also stale and orphan blocks, caused by rare block find timing (orphans) slow pools (orphans/stales) remote miners not well connected to the pool (stales) or miners generally slow getting the block to the pool for whatever reason (stales)
But they don't fall under the heading of 'lost' - but all 'should' be displayed by all pools (though I doubt most of them do)
If instead a block is lost due to network issues like the share never being delivered to the pool, well then there's no way for the pool to handle that, since it never got the share - only the miner could know about that one, assuming cgminer actually reports it.
So related specifically to this item - my pool's worldwide node distribution is relevant to that - miners have nodes close to them - nodes that submit blocks to the bitcoin network immediately, not waiting until they are processed less than 100ms later by the master server.
(the ckpool master node latency report for each KanoPool node is under 70ms for all but the Singapore node which is 86ms)
But what this also leads to, by design, is that every node on the Worldwide KanoPool network submits the block to the area it is in.
The block submission does not require the full block to be sent to each node, only the tiny share data, thus it distributes the blocks around the world faster than any other pool - and there certainly can be no argument against this now that the Fibre Block relay is gone - though when the Fibre Block relay was working, the process of only sending a share via TCP rather than the full block via UDP was also probably faster than the Fibre Block relay, since the incoming block to the FIbre Block relay, and outgoing to the other pools on the network 'at the other end', was also TCP.
Also, of course, the KanoPool nodes are all interconnected with their bitcoinds as well.
As for blocks 'missing'
Well this is a rather curious suggestion that a pool could make blocks disappear but still get the BTC
To do this would require:
1) sending a miner different work to the rest of the pool, not identifying the block as Kano
2) the miner would then find a block and have to never notice that it found a block
Both of these things, any miner 'can' check, so I'd magically have to know which miners would never check this and hope I never get caught even once over the years.
While this has never happened on KanoPool, I guess I 'could' come up with some excuses like ckpool has over the years for losing blocks ... if it ever did happen
Lastly, as can been seen in the old git, but of course not my current private git, but has happened with every block found on the pool, KDB immediately displays the block found irrelevant of if it is valid/stale/orphan/rejected and I also do this in IRC and Discord.
... unlike all the ckpools ... including laurentia
--
Edit: While people may say that 'the big pools' must have more resources and a better network:
There are currently 11 KanoPool nodes around the world, 4 of which are bare metal hardware, the equivalent power of the server that's runs all of cksolo or laurentia (4Core/8Thread, SSD, 32GB RAM though one has 64GB), the other 7 are VPS, 16GB/4vCPU/SSD AWS/Vultr/RamNode/Aliyun.
Also the 3 main connections, Netherland, US-West and US-East, have two nodes each, one metal and one VPS i.e. with 2 providers to handle the case if there is an issue involving one or the other provider.
These are the servers I add as needed, or also for large miners to have a dedicated node, part of the KanoPool network.
The main (metal) server is a 'bit' more powerful ... 24Core/48Thread 96GB RAM, SSD ... though I'll probably upgrade that soon.
The web server is also a separate metal server the same as the nodes (4Core/8Thread/32GB/SSD)