Yes of course I can. I was simply trying to see the logic in going to the effort for securing one detail, the mine-to address.

So in short, giving them the wrong mining address. There's pretty much nothing else on the site. Fair I guess?

All of this has been on my mind for a while, but explain what encrypting the pool web interface with SSL really offers? That they won't get told to mine to the wrong address? Is that a real problem?

There's a reason 443 is the backup port for mining, and that's because many firewalled internet countries allow port 443 connections because they just assume they're basic indecipherable https web traffic and nothing untoward. It allows mainland China miners to connect to the pool, and used to allow Iranian miners as well. As it turns out, coincidentally the new server IP location is blocked by Iran regardless which annoys me no end, so I'm not sure using port 443 for mining is helpful any more. Anyway I've managed to switch the https to port 444 which is very non-standard and unexpected, but it automatically redirects all unencrypted traffic to http://solo.ckpool.org/* to the new port for now. It's a cludge and I'm still not sure if I should stick to it or simply abandon port 443 mining and offer some other random innocuous port instead. Unfortunately there are a LOT of miners that never frequent this forum or communicate with me in any way whatsoever so I can't really get a quorum of opinions on what works best. Given the SSL for the web interface is kinda sorting working in case people want to use SSL, and there is absolutely ZERO secure information on the web interface (which is why I never bothered with SSL before you suggested it), I'll just leave it as is for now.

Pool and bitcoin daemon updates and restarts complete. Mine on!

Hashrate looks to be back to baseline so I'll be updating/restarting the pool and bitcoin daemon in approximately 2 hours. Downtime should be negligible.

Also if you're wondering about the web interface, I'm doing as frodocooper suggested and installing https support which is why it's currently unavailable, and of course port 443 is being used by the pool itself so it would need another IP address or irregular port >_<

Hi All. I'm planning to do a bitcoin daemon upgrade on the pool with some further performance optimisations both from the bitcoin daemon and the pool that speaks to it. As there appears to be a fair amount of hashrate on the pool at the moment I will hold off till I see the hashrate drop to a normal baseline level. On the other hand if this hashrate is the new baseline, I will simply perform the upgrade in 24 hours.

Additionally, whilst it may seem most unusual for me to say this, I would say that if you are considering renting hashrate to look for blocks now, it might be a good idea to wait for the next diff drop first, provided you can rent it at the same rate immediately after the diff drop.

Entirely dependent on the number of unique miners connected, so impossible to say.

Spot on, and yes I'm using the SSD NVMe Raid array since we don't need the extra storage, but speed is everything. Raid 1 gives us some redundancy in the event of SSD drive failure but not real backup which is serious overkill for a pool that has no state information that matters. No I don't mind it being posted as this is a community funded project so best to keep everything above board. Once the blockchain gets to over 800GB we'll outgrow it, but that doesn't look like it'll happen anytime soon, and we'll probably move to yet another new server with even more up to date hardware then, assuming this pool is still in action (which appears likely.)

Thanks guys.

I think the answer has been laid out for you. I did not ask for the pool's running fees, and I definitely did not ask for donations.I was planning to close the pool because I was making nothing from it, yet I was exposing myself to risk because I took it upon myself to be open about issues that I had with the pool. However the community wanted the solo pool to continue so I said I would keep it open as a not-for-profit community pool with a seriously trimmed down version of the existing hardware (and in one location only.) The community then said they wanted better hardware/location etc. and I said I couldn't afford that but they all offered to chip in and pay for it. The pool fee will amount to 2% of probably 1 maybe 2 blocks per year. I wouldn't want to maintain a pool with the time, effort, and heartache that provides, with it not even covering the cost of running but they all offered to pay for it because they wanted it. I don't mind maintaining a not-for-profit pool if I'm not paying out of my pocket for it, nor exposing myself to risk by running it. Not many pool operators would give a quote for how much their server costs to run and expose all their code for free to the public, in addition to running it for no profit. The 2% fee would be some recompense for my time - I even offered to remove the fee entirely but they all insisted I leave it and perhaps increase it. I've said before I don't need donations, and I still don't. The community support is the only reason I decided to keep the pool running. It IS fun to run a pool for the community.

So long story short, once upon a time the solo pool was partly run for fun, and partly for me to make profit, and it stopped making profit more than a couple of years ago. I decided to therefore close it down, but the community wanted the same pool to continue as effectively a community-funded project but with me running it so they all forked out to make it happen which made me happy to continue running it.

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.

Correct. Exactly the same configuration.

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.

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.

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

It should be 1 decimal place for the difficulty graph.

This is a fantastic effort and looks great. A couple of things - the pool difficulty seems to move in integer increments on the graph so jumped up by one moving from 114 to 115%. The default refresh time is set to 30 seconds, but the pool's own stats only update every 60 seconds so that's unnecessary. Other than that, great work!

It only resets if the block is confirmed. The stats are right, we still haven't found a successful block.  It's all up to interpretation, and that's how I see it.