Quote from: minefarmbuy on May 25, 2020, 09:32:57 AM

We are insured, plan to use funds from fee generation as proof of reserves in case of any errors in or out of our control to safety net our users work in lieu of insurance in the future.

At a pool fee of 0.3% it will take you 333 blocks to just cover the cost of a single lost block, with no income to pay for servers or anything else.

I did this on KanoPool due to the problems of -ck's poorly coded and tested code, and that was just before what lead up to him kicking me out of the ckpool and cgminer git.
My pool already has a few (current) blocks worth of pool fees that I've not paid to my wallet, to cover anything that might go drastically wrong.
But I have also removed specific problems from the ckpool code I use that are still there in the public git.
Aside: there is more code in the ckpool git by me than by -ck.

Quote from: minefarmbuy on Today at 12:04:27 AM

FIBRE is non essential for LP or solo ckpool, it's loss will be missed by the network but ck pools are unaffected. So beyond that our server is extremely well connected and block switching is extremely fast for both the pool -ck hosts and LP which he co-operates specifically the server side.

You can't just make a statement that is clearly wrong, without some proof of why you think the logical need of distributing your blocks quickly and getting blocks from the majority of pools quickly isn't necessary.
That makes no sense at all for anyone who has even the slightest understanding of how bitcoin works.

No matter what you say, it takes some number of milliseconds to process a block find.
But then that block needs to get to all the other pools, to stop them trying to find a competing block with the one you found, and move on to finding the next height block built off your block.
On top of that, there is the requirement to see the blocks of other pools as quickly as possible, so you aren't working on stale work, like what happened on the solo pool in the extreme when they recently lost a block.

Without the fibre network, your block will only get to other pools by relay from your bitcoind to those you are connected to.
Thus it will be a number of (slow) steps from wherever your bitcoind is to the pools in china ...

Quote

Of course like you state any pool which submits a "winning" share from two miners at the same will have conflict. Our whitepaper outlines well our take on networking, and reasoning for our single node setup. I'm not sure what you're trying to argue as larger pools are starting to either adopt something similar or develop more on stratum like V2 which is mostly to support better the inefficiencies of satellite/proxy nodes within the same pool.

It's no conflict, it's simply expected to happen no matter how many nodes you have, one or 1000.
Having only one node doesn't stop it from happening.
Each hash is random - it's not going to make any difference if two miners are talking to the same node or two different nodes.
If you think for some reason two miners pointing to the same node cannot find 2 blocks at the same time, then you don't understand bitcoin mining.

You mention "V2" but this is simply just slush trying to market themselves, since they are falling in size compared to the other larger pools.
V2 is GBT relabeled, that died out for many good reasons

Quote

Also we don't expect higher orphan chance, we expect less than competitors.

Your block distribution is worse than most pools, by your own design.
So you WILL expect more orphans.

Quote

Our UI now although very basic displays best share so I'm not sure how we're not transparent as you claim when other pools provide less insight in these metrics, but still have the need to attack our service. Our goal as well is to use our fee to build out the UI to our users needs which could include more metrics requested by consensus.

... interesting how your opinion of having a UI has changed ... to quote YOU in the past:

Quote from: minefarmbuy on February 11, 2019, 04:36:31 PM

...
Don't get me started on how shitty slushpool is. This "beta" shit is the same UI with features they should have built in years ago.

Quote

If anything we, including -ck are very open and transparent. Likely this is well known by anyone who has engaged with us before.

... and yet on the multiple occasions that his pools have lost blocks, no one knew except the miner who found the block, that then prompted him to explain why.
That's not transparent - that's hiding important information.

Quote

Everything you state in this thread is extremely assumptive

I've run a reliable pool for 6 years, and had to deal with the problem known as -ck for many of those years.
There's no assumptions in anything I've said.
I'll make it quite clear that I am an expert in bitcoin, networks, software development and server management.

Quote

As for the technical aspects you'd have to consult -ck but I know that relationship is tarnished, so good luck getting answers. I'll just say there is a reason we chose new high end equipment to host our server on, to not just benefit us as operators but to benefit our users and future optimizations and efficiencies without restraint.

If your definition of "high end" is that tiny server -ck uses for the solo pool, then you clearly have no idea what is required to run a pool.
Remember, he ran a pool on a piece of junk for years that only by luck didn't lose more blocks than it did (or did it and no one knew?)

As a lot of the people on my pool know, I use two types of servers just for the nodes, one equivalent of your so called "high end" and one with half the ram - duplicated in the major areas on two different providers.
The main server is MUCH more powerful.

Basically you are saying you are cutting corners, spending only $120 a month on a server to support millions of dollars of mining hardware,
instead of setting up a proper pool with distributed nodes to get the blocks out to the rest of the network.
One lost block due to poor network distribution is (currently) about $50,000 yet you're only willing to spend $120 a month to deal with network distribution Tongue

"Laruentia Pool - BAD risk for miners"
Using software developed by someone who has so far lost 4 blocks due to buggy code and negligence.
... and has white paper full of design flaws.