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

The net diff. is gona drop again by around -6.3 % and NH is at 0.0089 BTC/PH/day.
Willi is still looking for people who are joining the lotto:

https://bitcointalksearch.org/topic/m.54421011

good luck to every miner

This all looks familiar. ;P

Diff has now dropped if you guys want to crank up your rentals again

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.

@-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.

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

Without HTTPS, browsers cannot tell if the web server that they are talking to is the true solo.ckpool.org web server. HTTP offers no means of authentication whatsoever, and BGP cannot be relied upon to properly route internet traffic to the correct destinations.

Without HTTPS, browsers send and receive everything in plaintext. This includes requests for the path to the pool's records for specific Bitcoin addresses, and the web server's responses to those requests. Any entity sitting between the user and the web server—e.g., ISPs, network intruders, IP transit providers, OVHcloud, etc.—can see and log what Bitcoin addresses are of interest to the user that is making those requests, and what the pool says about those addresses. These eavesdroppers can therefore make reasonable assumptions regarding the user—e.g., that the user that they are spying on (a) mines bitcoin, (b) uses a certain Bitcoin address, (c) possesses a certain amount of hashpower, (d) mines at certain times or at all times, (e) has this or that amount of bitcoins associated with that Bitcoin address, (f) spends this or that amount of bitcoins at certain times, (g) sends this or that amount of bitcoins to certain addresses at certain times, and (h) is worth targeting to steal the user's private keys when the user mines a block. This list of assumptions is not exhaustive. Unencrypted HTTP and the completely transparent nature of the Bitcoin blockchain enable methods of surveillance far more comprehensive and sophisticated than I have time to list here.

Without HTTPS, you are open to the risk of a user, or a group of users, being pwned simply by visiting the pool's website. This is because unencrypted HTTP allows any network intruder to inject malicious code into the stream of traffic that passes between the user and the web server. Although modern web browsers and operating systems have made tremendous leaps forward in terms of security, zero-day vulnerabilities remain an ever-present significant risk, notwithstanding the risk of user error and/or ignorance. At the time of writing, the reward in US dollar terms for successfully mining a Bitcoin block is approximately $61,000. That's a lot of money, and it therefore paints a very large bullseye on the person who mined the block.

It is very hard to recommend in good conscience a service that does not seem to take into account its unique threat model and incorporate the most basic and foundational element of modern web security to help mitigate those risks. There is zero reason to ignore HTTPS. It offers reasonable security and privacy at almost no financial and technical costs. There may be a large gap between reasonable security and robust security, but there is an infinite gap between no security and reasonable security.

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?

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.

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.

Thanks, -ck.

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.

One downside to this approach is that visitors to the pool's website would have to manually add the https:// prefix to the pool's web address every time they enter it into their browser's address bar, because the pool's web server can't listen on the occupied port 80 to redirect them to port 443—unless the pool's website is (a) included in the HSTS preload list and/or (b) incorporates the EFF's HTTPS Everywhere rulesets to allow visitors using the HTTPS Everywhere browser extension to be automatically directed to port 443. The upside to this approach is that you do not need to configure the web server to forcibly redirect unencrypted HTTP requests to HTTPS URIs.

If you prefer to reserve port 80 for the pool's web server to use, then another simple solution would be to let the pool's stratum server listen on port 53 instead of port 443. This frees up both port 80 and port 443 for the web server to use. Port 53 is meant for unencrypted DNS traffic, and so outgoing connections to port 53 are also usually allowed by default in most firewalls. This approach requires you to configure the web server to forcibly redirect unencrypted HTTP requests to HTTPS URIs. Registering the pool's website on the HSTS preload list and incorporating HTTPS Everywhere rulesets remain highly recommended when using this approach.

A more complicated solution that doesn't involve setting up an additional network interface with additional IP addresses on the same machine, would be to terminate TLS connections at a HAProxy instance on a cheap VPS that in turn relays web traffic to and from the upstream web server (ideally encrypted, over a private network). Upsides to this approach include (a) allowing you to leave the pool's current setup on the dedicated server mostly untouched, and (b) freeing up the pool's dedicated server from not only having to manage TLS connections with web clients, but also from having to manage web traffic with clients at all. The downside to this approach is that it involves more effort and money to set up and maintain, because you would have to manage two servers instead of one.

And then there's setting up an additional virtual network interface with additional IPv4 and IPv6 addresses on the same machine, and binding the pool's stratum server to one virtual interface and the web server to another. This seems quite straightforward in concept, but I do not have any experience with this approach, and so I can't say much about it, nor can I recommend it with confidence. It does seem cheaper and simpler than setting up HAProxy as a reverse proxy on another VPS, though.

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.

Will let my rentals expire (just did actually) and not rent again until the diff change.
Thanks,

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.

Also, may I strongly recommend deploying HTTPS on the pool's web server, configured to support TLS 1.3 and HSTS? There's currently no way for any visitor to the pool's website to tell if (a) they landed at the true solo.ckpool.org web server, (b) that third parties are not eavesdropping on their communications with the web server, and (c) that their traffic to and from the web server has not been tampered with or injected with malicious code by third parties.

The performance overhead associated with HTTPS and TLS is less than negligible, especially with TLS 1.3. And since the pool's new dedicated server has at least a hundred times the computing and networking resources needed to run the pool efficiently, I see no plausible reason for leaving out a foundational element of modern web security in the current rebuild of the pool's infrastructure.

Mozilla has a very handy TLS configuration generator that does most of the heavy lifting for you when configuring TLS parameters. I highly recommend selecting Mozilla's Modern configuration instead of their Intermediate configuration. I see no reason to support legacy versions of web browsers; users of such browsers have far bigger problems than merely being unable to visit a website. Dropping support for TLS 1.2 also reduces the performance baggage that comes with it.

EFF's Certbot automatically obtains and renews TLS certificates from Let's Encrypt for you. Let's Encrypt's certificates are free, and they also offer wildcard certificates.

Looks great, but doesn't look like network difficulty has updated.

Any chance to add the current bitcoin price in the Bitcoin Network section?

Here is a screenshot from a comment i posted a year ago:



The average rx is 3.7kbps per miner, so safe to assume the pool needs 5bkps per mining instance/miner,  but that's only for the communication between the pool and the miner, the pool does a lot more than that, syncing with other nodes, downloading every block, mempool operations, those alone probably need more bandwidth than running a few EHs worth of miners.