|
If there's demand I could set up a relay in Germany with some of the funds given to me if that helps. However I'd have to point out that it is still better to mine directly to the pool.
|
|
|
|
I don't know what is the guilt of us who were born in Iran? Others rule. But we, the ordinary people of Iran, are deprived of the world.  I do not restrict access to the pool at all. It is out of my control. No political discussion here please. |
|
|
|
Hi
I check ping from the pool address. This is no problems and has no timeout.
But when I config and set pool addresses in ASIC Miner. The pool is dead.
Please help me what should I do?
I'm sorry for english, I'm using Google Translator.
Is your username a bitcoin address? Yes, the username is Bitcoin address. I also tested the BC1xxxx.... address, as well tested the 3xxxx.... and the 1xxxx.... address for username. with . dot worker name, and without worker name. stratum+tcp://solo.ckpool.org With all the port's. I even checked the addresses of solo4.ckpool.org and solo6.ckpool.org for the pool. In all cases, the pool is dead. I am from Iran. Could it be because of sanctions? However, I have no problem with other pools and the device works well. Iran blocks connections to the server. There is nothing you can do about it. |
|
|
|
Hi
I check ping from the pool address. This is no problems and has no timeout.
But when I config and set pool addresses in ASIC Miner. The pool is dead.
Please help me what should I do?
I'm sorry for english, I'm using Google Translator.
Is your username a bitcoin address? |
|
|
|
Will the pools proxy support work for 2PH worth of USB miners?
Yes Thank you. Did you mean the "tube/prisma" proxy? That wasn't designed for USB sticks in mind. I thought you meant running a local proxy yourself which would make far more sense. |
|
|
|
Will the pools proxy support work for 2PH worth of USB miners?
Yes |
|
|
|
Diff has now dropped if you guys want to crank up your rentals again  |
|
|
|
@-ck: Sorry if I'm sounding naive, but is it possible for you to lease a second IP address from OVH? I think that could solve the problem of unavailable ports since you counld point the web server to listen on port 443 of the second IP address. It looks like you can get one for dedicated servers. I can't think of a way of running both a mining pool and a web server on the same port as one of them is going to hold the connection exclusively. 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?
|
|
|
|
Merely using port 443 to evade censorship is no longer effective, if it ever was to begin with.
Since the stratum protocol is unencrypted, it is trivial for censors to deploy filters that block the protocol if they want to block bitcoin mining. It is also trivial for them to deploy DNS filtering to prevent miners' networks from resolving the domain names of known mining pools, and if miners decide to use unencrypted public DNS resolvers, to hijack their DNS requests to either prevent them from resolving pools' domain names, or feed them fraudulent IP addresses to connect to. And then there are other more sophisticated forms of internet censorship that are not only in use by state-level censors, but also by enterprise networks—e.g., deep packet inspection, etc.
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? |
|
|
|
The simplest solution to the port problem that I can think of is to let the pool's stratum server listen on port 80 instead of port 443. This frees up port 443 for the web server to use for HTTPS traffic. This makes a bit more sense anyway, since port 80 is intended for unencrypted HTTP traffic, and the stratum protocol is itself unencrypted. Outgoing connections to port 80 are also usually allowed by default in most firewalls. 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.
|
|
|
|
These specs can probably handle 5 more pools lol, but we do need them, after all the chance of hitting a block is already too slim to be risked, i support his decision for migrating to a server which is capable of doing more that what we need it to do rather than trying to save a few bucks for a server that could fail us, no room for errors here, let's see when do we hit a block on the new server.
Given that the new server hosting the mining pool has a 1 gigabit line, I'm curious to know how much network bandwidth a pool would need to operate reliably. There's a similar question in this thread but it was never answered. Entirely dependent on the number of unique miners connected, so impossible to say. |
|
|
|
To those who are curious as to what the donations bought for this pool, and also to the geeks among us who are naturally curious about such things—if I'm not mistaken, and hopefully with his permission to post this, -ck used the money to migrate the pool to this beast of a machine. Here are its specs: -ck wasn't kidding when he said that the new server is " massively overqualified for the task now." I think that that's a colossal understatement, and even more so if he went with the NVMe SSD variant. 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.
|
|
|
|
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...
thank you
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. |
|
|
|
|
Show Posts
