It appears that a customer can no longer buy a prepaid Mastercard or Visa virtual credit card from Coinsbee without first signing up for a Coinsbee account. Also, it appears that they have updated their privacy policy to give themselves more leeway in their use of collected user data and to change the name of the company that operates the Coinsbee service from "TSMH GmbH" to "Coinsbee GmbH."

I would very much welcome a Coinsbee v3 onion service, albeit one that does not leak secure cookies into insecure backend channels.

Etsy gift cards would also be a welcome addition to your catalog.

With Coinsbee currently unable to offer Mastercard and Visa prepaid cards for sale, are there other trustworthy Mastercard or Visa prepaid card providers that accept monero or bitcoin?

American Express, Mastercard, and Visa prepaid cards appear to have vanished from Coinsbee's catalog at the time of writing. Visiting their respective pages redirects the browser to Coinsbee's home page.

Would you consider accepting monero as payment?

Setting up a v3 onion service is a far better long-term solution against censorship. The pool may opt to set up a single onion service instead of a conventional one in order to reduce latency, but at the cost of reduced server-side location anonymity. A single onion service uses only three hops in the circuit instead of the usual six.

An onion service may be set up as a single onion service by adding the following two options to the onion service's torrc entry:


Here are the relevant entries for single onion services in the Tor manual:

Thank you very much, -ck, for deploying TLS on the web server.

The web server's TLS configuration looks decent. The SSL Server Test by Qualys SSL Labs has given an A grade to solo4.ckpool.org. There's room for improvement, but I suppose that the current TLS configuration is sufficient for now.

The SSL Server Test was unable to connect to the web server over IPv6 at the time of testing.

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.

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.

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.

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.

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:

Provider	OVH US LLC
Type	Dedicated server
Location	Vint Hill, Virginia, USA
Processor	Intel Xeon E-2274G Processor (8M Cache, 4.00 GHz)
Memory	32GB DDR4 ECC 2666MHz
Storage	3 x 4 TB HDD SATA Soft RAID or 2 x 960 GB SSD NVMe Soft RAID
Public bandwidth	1 Gbps unmetered (burst 2 Gbps)

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

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.

I deleted wwzsocki's posts because I have reason to believe that he made those posts merely for the sake of qualifying for ChipMixer's signature campaign. Note the timestamp of wwzsocki's application:


As far as I'm aware, wwzsocki had never posted on any of the Mining boards throughout my time as moderator. He started posting there only after being apparently advised by DarkStar_ to do so:


He has also referred to posting on this forum as "work":



Wwzsocki doesn't appear to be working for the Bitcoin Forum as a moderator or an administrator. Therefore, I believe that it is reasonable to infer from at least these words that he sees this forum as primarily, if not exclusively, a mere opportunity for financial gain through signature and bounty campaigns. His post history, especially with regards to his various endorsements of something called GOLD, his participation in its bounty campaign, and his recent application for at least one other signature campaign, bears witness to wwzsocki's motives for posting. DarkStar_ himself noticed this, as did asche and suchmoon:




Also, posts are just that: posts. What significance do they have in your life that you feel compelled to make such an earnest effort to vindicate the worth of your posts and your self-perceived literary and intellectual prowess? Is not life more important than posts on a forum that 99.99% of the world isn't even aware of? Unless, of course, this forum serves primarily or exclusively as a mere means to financial gain for you, because any action on the part of the forum's staff that is detrimental to that goal is then taken as a threat to your material self-interests.

Therefore, to be clear, I have zero tolerance for anyone whom I have reason to believe is posting exclusively or primarily for mere financial gain through signature or bounty campaigns. This forum is intended to facilitate reasonable discussions made in good faith according to its rules. (I'm of the opinion that signature campaigns are generally detrimental to this forum's usefulness.) Additionally, the Mining boards are for facilitating serious discussions of bitcoin mining-related topics according to the rules of that section and the standards of the Serious Discussion and Ivory Tower boards. Unless wwzsocki is deemed to exhibit a genuine interest in bitcoin mining and a genuine eagerness to contribute quality discourse without regard for financial gain through signature and bounty campaigns, then he is not welcome in the Mining section.

Hello. The following Newegg Gift Cards are up for sale.

Quantity	Value	Item	Price	Expiration Date
SOLD	$440.33	Newegg Store Credit Gift Card	$400.00	None
SOLD	$46.34	Newegg Store Credit Gift Card	$40.00	None
SOLD	$29.99	Newegg Customer Care Gift Card	$20.00	2020-04-09T23:21:01Z

All Newegg Gift Cards are subject to Newegg's Gift Card terms and conditions.

All list prices are denominated in US dollars.

I accept payment in monero (XMR) only, either directly or via any escrow service provider from this list that both accepts monero and is willing to escrow gift card transactions. If payment is made via escrow, then the buyer shall pay the escrow service provider's fees in full.

To purchase or to request for more information, please contact me via forum PM.

---

2020-01-17T02:00:00Z

All Newegg Gift Cards have been sold.

Hello. The following items are up for sale.

Quantity	Item	Unit Price	Condition	Dimensions	Mass
SOLD 1	MSI B450 TOMAHAWK MAX	$50.00	New	N/A	N/A
SOLD 3	Delta DX-62 fan	Pay what you want	Used	120 mm x 120 mm x 38 mm	N/A

All listed prices are denominated in US dollars. The buyer may denominate pay-what-you-want prices in monero (XMR) or US dollars. All prices exclude outbound shipping charges.

All items ship from a colocation datacenter in Canby, OR 97013, USA.

I accept payment in XMR only, via DarkStar's escrow service. DarkStar's escrow fee shall be equally divided between the buyer and myself. BitcoinAverage's published USD/XMR exchange rate at the time of the initiation of the escrow transaction shall be the reference exchange rate.

To purchase or to request for more information, please contact me via forum PM.

---

2020-01-08T03:00:00Z

The MSI B450 TOMAHAWK MAX and the Delta DX-62 fans have been sold.

If you would like to find out more information about those IP addresses before deciding whether to block them, then I suggest performing reverse lookups of the IP addresses to see what domain names they are mapped to, if any, and then performing WHOIS lookups of the returned domain names to see if those IP addresses belong to any entity that you know and trust.

If you are using a *nix OS — e.g., macOS or any Linux distribution — open a terminal window and enter the following:


(Replace [IP address] with the IP address that you are looking up. The IPv6 address 2606:4700:4700::1111 points to Cloudflare's public DNS resolver. You may change it to an IPv4 or IPv6 address of any other public resolver or simply leave out the @ field to query your local system's DNS resolver.) This should return the domain name that is mapped to the IP address, if any.

Then, perform a WHOIS lookup of the returned domain name by entering the following into your terminal:


(Replace [domain name] with the domain name that you are looking up. You may instead use a web-based WHOIS lookup client if you wish.)

If the returned results are suspicious or unknown to you, then I recommend blocking those IP addresses.

I beg to differ.

Canaan announced the A721 on 2016-11-07. Commit 04e6a4b, titled Add Avalon7 support, was committed by qinfengling on 2016-07-29 and published by Canaan in the avalon7-dev branch of their cgminer repository on 2016-11-05. In other words, Canaan published the source code for the A721's version of cgminer two days before they officially announced the miner.

Canaan announced the A821 on 2017-12-20 at the latest. Commit 6786bbd, titled Add Avalon8 support, was committed by qinfengling on 2017-09-11 and published by Canaan in the avalon8 branch of their cgminer repository on 2017-09-27. In other words, Canaan published the source code for the A821's version of cgminer roughly three months before they officially announced the miner.

Canaan announced the A921 on 2018-09-19 at the latest. Commit fbc869b, titled Add Avalon921 support, was committed by Johnson-Fan on 2018-09-10 and published by Canaan in the avalon9 branch of their cgminer repository on 2018-09-11. In other words, Canaan published the source code for the A921's version of cgminer roughly eight days before they officially announced the miner.

Canaan announced the A10 at 2019-03-28T15:21Z. It is now almost seven months since the official announcement and there is still no published source code for the A10 in any of their GitHub repositories at the time of writing. The only entry for the A10 to date is the avalon10-docs repository, which merely contains a manual for the A10's API.

It appears that Canaan has stopped publishing their source code in their GitHub repositories since the release of the A10 series. Given that the A10 (and presumably the A11) use cgminer — at least according to the only available documentation for the A10 — Canaan appears to have followed in the footsteps of the other manufacturers in violating cgminer's license.

If the A10 and A11 are using OpenWrt as the base OS, then Canaan is also violating OpenWrt's license by not publishing the source code for their fork of OpenWrt.

This is a regrettable development.

I didn't move it. As far as I'm concerned, your topic did not violate the Pools board's rules, as it focused on announcing and discussing the bitcoin side of the pool.