Topic: [∞ YH] solo.ckpool.org 2% fee solo mining 256 blocks solved! - page 234. (Read 102489 times)

Yes! Fees maybe can handle it on this "pool" ,to run the server. But maybe "someone" likes to get his code and maintenance paid, (in $) !


Sure! But what is about you, you share your old Money/Coins with anyone else??? ... I doubt!


Maybe, but i think he still likes to manage it Yes! Use another "solo "pool" provider. Maybe he's legit maybe not? ... What about runing your own full node and a bitcoind and submit a block hash???


However, we all can decide by our own where whe point our hash, i think

Nobody HAD to.  They decided to pay for updated hardware.  Read back in the thread as the answer is quite clear.

curious - why would the miners have to pay to have the pool open?

is it because ck does not have the funds? that i doubt - pretty sure he has over 1k btc - if not more as he has been in the game since nearly the beginning

so is it more likely that ck no longer wants to manage a pool? if so, would it not be better then to join another pool that the pool manager wants to operate?

not an attack against ck by any means - just never saw where miners had to pay the costs for a pool manager to keep a pool open or where they needed to pay miners who lost blocks because of a pool error.

Ok, ashamed is maybe not the best word     ...   But i'm here since the pool's inception, started to mine with 4 S3+ at 300 MHZ (600 GH/s) occasionally a few days a week. (Yeah i had a very good Batch back then).

I really don't like to see this pool to go down anytime soon.

So, i'm more then willing to throw 100 bucks or so, to cover costs. But it in any case it will take a while to send coins to phil, but it's on my Mining/Bitcoin shedule 



Hey, yes looks like that all sendable ammounts     ...   but ATM i'm not able to send a single satoshi ... but will do soon.



By the way, new sever location looks good for me! 90-99 ms to solo.ckpool.org and solo4.ckpool.org (both end up at solo4.ckpool.org) . ipv6 looks bad from my location. around 120-180 ms, so i just use the other route.

okey,very thanks.i will try solo4 and solo6 and will report its result here.perhaps others can use.
dont you have any idea about the DIFF boxes that are blank in my miners status?

Edition:i tried solo4.ckpool and solo6.ckpool but my configs are dead yet!

I don't know, but there's probably a routing problem between where you are and the pool is. I've had one miner from Iran report the same thing to me elsewhere, so perhaps some places don't route properly to where the pool is.

If you're on linux you can check your routing with the following command:
mtr --report -w solo.ckpool.org

Additionally you might try solo4.ckpool.org or solo6.ckpool.org instead of solo.ckpool.org . Possibly it is trying to route through IPV6 and failing.

hello again,sorry dear c.k.,i did hard reset for both my antminers and my router.but unfortunately the problem is still immutable.i tested 3333 and 443 ports,changed the btc addresses and used all 3 of btc addresses like segwit and legacy and...but the miners status is showing "DEAD" yet.please any suggestion...i saw correctly my antminers status pages and noticed those DIFF boxes are blank!is this my problem?if yes so what should i do?

thank you

Correct. Exactly the same configuration.

so i dont need any changing in miner configuration,right?miner config is still "solo.ckpool.org:3333 or 443" and btc address as username?

The pool has moved to a new location and has new IP addresses as a result, and all the alternate locations (de, cn) have been shut down so you can only mine directly to the solo pool now. You may need to hard reboot your antminers if they still have the old IP addresses and aren't updating, or reboot your router if that's responsible for using the old address.

my antminers do not work after halving.sometimes those are connected but after a while miners status show DEAD!i read previous pages and noticed some changes in server and...but i did not understand what should i do?im on "solo.ckpool.org:3333"

please any help or advise


thank you

Thanks. I thought it was suspicious that both were effectively the same place. Nonetheless, for my routing from here to the solo pool is faster with IPV4 despite IPV6's potential advantages, so at least for miners from home I suggest they test before mining for themselves since there is no cloudflare in front of the pool.

In my opinion, anything under 200ms is fine.

Well done CK, sadly the server seems a bit too far from my location, ping results are bad, ran a longer ping -t and had a 1% packet loss.



here is the traceroute



Hop 10 to 11 (EU to US) is a long way  .

These numbers are not exactly bad with the general use of the internet, with mining that could be a lot, or is that ok?

The IPv4 subnet of 104.16.0.0/12, which includes NiceHash's IPv4 address of 104.17.254.46 and Mining Rig Rentals's IPv4 address of 104.26.0.61, belongs to Cloudflare. The IPv6 subnet of 2606:4700::/32, which includes NiceHash's IPv6 address of 2606:4700::6811:ff2e and Mining Rig Rentals's IPv6 address of 2606:4700:20::681a:3d, also belongs to Cloudflare. Therefore, the most plausible reason for why the measured latency from the pool to those hosts were so remarkably low isn't that NiceHash's and Mining Rig Rentals's servers are in the same datacenter as the pool, but that the ICMP echo request packets sent by the pool to those addresses were directed to Cloudflare's CDN instead of the upstream hosts. The latency measurements by -ck are therefore meaningless, as -ck measured the latency to Cloudflare's CDN, which most likely has a network of nodes in the same datacenter as the pool, instead of NiceHash's and Mining Rig Rental's upstream hosts.

If your network supports IPv6, then I recommend using IPv6 instead of IPv4. Routing and packet processing are more efficient with IPv6, which therefore theoretically results in better overall network performance. And since both NiceHash and Mining Rig Rentals also rely on Cloudflare's DNS infrastructure, you would do well to set Cloudflare's public DNS resolver as your network's DNS resolver. It may help to shave a few milliseconds when resolving NiceHash's and Mining Rig Rental's domain names. For the more adventurous folks, you may also want to consider running OpenWrt on your network routers and then running Stubby for OpenWrt with Cloudflare's public DNS resolver as its upstream resolver. If you do run Stubby for OpenWrt, then I recommend forcing its use of TLS 1.3 and disabling Stubby's round-robin scheduling of upstream resolvers. And while you're at it, you may also want to consider running luci-app-sqm to help mitigate bufferbloat, which in turn helps to improve network performance under load.

Very nice.  Added my address - very sleek design.

I think we need to hit a block or two, just to confirm that the new dashboard works properly.

Oh that's my fault then because it's rounded to 3 significant digits. Integer is fine sorry.

I probably still dont understand. What is the point of showing decimal places? "pool.status" endpoint seems to return just integer for attribute "diff". Today the value jumped directly from "114.0" to "115.0" with no decimal steps.

I was thinking about next steps. Grafana have really nice system for alerting/alarming. It would be fairly easy to setup some notification (Eg to telegram), when block is found (emited when diff changes to 0), if it makes sence to you.

It should be 1 decimal place for the difficulty graph.