Bitcoin Forum
March 19, 2024, 10:35:04 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 [23] 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 ... 216 »
  Print  
Author Topic: [∞ YH] solo.ckpool.org 2% fee solo mining 280 blocks solved!  (Read 85208 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic. (19 posts by 4+ users deleted.)
vickersja
Member
**
Offline Offline

Activity: 210
Merit: 34

To be the man, you gotta beat the man...... WOOOOO


View Profile
May 18, 2020, 01:54:45 AM
 #441

Dashboards have been moved to server with higher RAM. 600M on free GCloud micro instance was not enough. There was about 20 minute downtime between 15:00 and 15:20 UTC, new address is http://35.192.6.83:3000/

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

Earn Bitcoin with Lolli:  https://lolli.com/share/FbdPrN6jTu
Link credit card for in-store shopping or use browser extension for online shopping
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
frodocooper
Sr. Member
****
Offline Offline

Activity: 351
Merit: 410


View Profile
May 18, 2020, 05:37:00 AM
Merited by DarkStar_ (5), -ck (1), NotATether (1)
 #442

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.
-ck (OP)
Legendary
*
Offline Offline

Activity: 4046
Merit: 1622


Ruu \o/


View Profile WWW
May 18, 2020, 07:41:26 AM
Merited by DarkStar_ (5)
 #443

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.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
-ck (OP)
Legendary
*
Offline Offline

Activity: 4046
Merit: 1622


Ruu \o/


View Profile WWW
May 18, 2020, 07:52:30 AM
Last edit: May 18, 2020, 08:54:04 AM by -ck
Merited by frodocooper (10)
 #444

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

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
jimjam123
Member
**
Offline Offline

Activity: 438
Merit: 15


View Profile
May 18, 2020, 10:22:36 AM
 #445

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.

Will let my rentals expire (just did actually) and not rent again until the diff change.
Thanks,
-ck (OP)
Legendary
*
Offline Offline

Activity: 4046
Merit: 1622


Ruu \o/


View Profile WWW
May 18, 2020, 10:40:10 PM
 #446

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.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
-ck (OP)
Legendary
*
Offline Offline

Activity: 4046
Merit: 1622


Ruu \o/


View Profile WWW
May 19, 2020, 01:14:03 AM
Merited by frodocooper (3)
 #447

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

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
frodocooper
Sr. Member
****
Offline Offline

Activity: 351
Merit: 410


View Profile
May 19, 2020, 03:29:00 AM
Merited by o_e_l_e_o (2), EFS (1), ABCbits (1)
 #448

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

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.
-ck (OP)
Legendary
*
Offline Offline

Activity: 4046
Merit: 1622


Ruu \o/


View Profile WWW
May 19, 2020, 03:35:12 AM
 #449

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.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
frodocooper
Sr. Member
****
Offline Offline

Activity: 351
Merit: 410


View Profile
May 19, 2020, 03:56:46 AM
 #450

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.
-ck (OP)
Legendary
*
Offline Offline

Activity: 4046
Merit: 1622


Ruu \o/


View Profile WWW
May 19, 2020, 04:12:07 AM
 #451

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?

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
frodocooper
Sr. Member
****
Offline Offline

Activity: 351
Merit: 410


View Profile
May 20, 2020, 01:04:00 AM
Merited by o_solo_miner (1)
 #452

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.
-ck (OP)
Legendary
*
Offline Offline

Activity: 4046
Merit: 1622


Ruu \o/


View Profile WWW
May 20, 2020, 01:11:02 AM
 #453

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

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
NotATether
Legendary
*
Online Online

Activity: 1540
Merit: 6496


bitcoincleanup.com / bitmixlist.org


View Profile WWW
May 20, 2020, 02:41:43 AM
 #454

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

  BTC
.
BTC
.
 BTC
.
BTC
..JAMBLER.io..
██
██
██
██
██
██
██

██

██

██

██
YOUR OPPORTUNITY TO
HAVE BITCOIN BUSINESS

██
██
██
██
██
██
██

██

██

██

██
.
  BTC
. BTC
.
.
 
BTC
  BTC
-ck (OP)
Legendary
*
Offline Offline

Activity: 4046
Merit: 1622


Ruu \o/


View Profile WWW
May 20, 2020, 03:10:09 AM
 #455

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

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
-ck (OP)
Legendary
*
Offline Offline

Activity: 4046
Merit: 1622


Ruu \o/


View Profile WWW
May 20, 2020, 04:38:37 AM
 #456

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

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
minefarmbuy
Full Member
***
Offline Offline

Activity: 1022
Merit: 221


We are not retail.


View Profile WWW
May 20, 2020, 01:30:58 PM
 #457

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:

ProviderOVH US LLC
TypeDedicated server
LocationVint Hill, Virginia, USA
ProcessorIntel Xeon E-2274G Processor (8M Cache, 4.00 GHz)
Memory32GB DDR4 ECC 2666MHz
Storage3 x 4 TB HDD SATA Soft RAID or 2 x 960 GB SSD NVMe Soft RAID
Public bandwidth1 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.

This all looks familiar. ;P

Premier asic sourcing minefarmbuy.com #mineon
Twitter:@minefarmbuy -LN Tips-
Email: info@minefarmbuy.com PGP:1A1C A4D4 CE04 F57E 1C0C 5240 592A 09BF CCB4 F0C3
o_solo_miner
Legendary
*
Offline Offline

Activity: 2405
Merit: 1458


-> morgen, ist heute, schon gestern <-


View Profile
May 25, 2020, 05:54:21 PM
 #458

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://bitcointalk.org/index.php?topic=5248106.msg54421011#msg54421011

good luck to every miner

from the creator of CGMiner http://solo.ckpool.org for Solominers
paused: passthrough for solo.ckpool.org => stratum+tcp://rfpool.org:3334
Abbot Jeton
Newbie
*
Offline Offline

Activity: 8
Merit: 2


View Profile WWW
May 25, 2020, 09:05:34 PM
 #459

Will the pools proxy support work for 2PH worth of USB miners?
-ck (OP)
Legendary
*
Offline Offline

Activity: 4046
Merit: 1622


Ruu \o/


View Profile WWW
May 25, 2020, 10:23:08 PM
 #460

Will the pools proxy support work for 2PH worth of USB miners?

Yes

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 [23] 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 ... 216 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!