Cannot Get Farmer to Sync - HELP!

Hello Chia Forum, I have 520 C8 plots created with MadMax, but I can’t get the farmer to connect / sync. I have the plots being found by the farmer, but I cannot get it synced or connected to peers. I am not sure what else to do at this point. I’ve been following YouTube videos from people with large farms & gotten this far, anyone’s help would be greatly appreciated. I’ve been trying to figure this out for a week+ now.

Farming status: Not synced or not connected to peers
Total chia farmed: 0.0
User transaction fees: 0.0
Block rewards: 0.0
Last height farmed: 0
Local Harvester
520 plots of size: 36.200 TiB
Plot count for all harvesters: 520
Total size of plots: 36.200 TiB
Estimated network space: 22.264 EiB
Expected time to win: 4 months and 3 weeks
Note: log into your key using ‘chia wallet show’ to see rewards for each key

All those peers are identified as “non-trusted” what could potentially suggest that you have problem with your SSL certificate. So, maybe this is the first place to check. If you have access to a Linux box, you could follow that post (point it to your node, could be your private IP).

It has nothing to do with your plots being there or not.

Actually, all that whining is coming from your wallet, so maybe this implies that you have a mixed setup - part of your installation is the original chia and part is Max’s gigahorse. As you created those plots with MM plotter, you need to be 100% MM setup (cannot mix with it chia node / wallet components, I think). I am not sure, but I think that MM setup doesn’t have a wallet, so maybe you are trying to start chia GUI on the top of gigahorse node or something like that.

Maybe when you followed those YT videos, you just got those two setups mixed up. Maybe you should try to follow the official MM docs - GitHub - madMAx43v3r/chia-gigahorse

Thank you for your reply Jacek. I’ve been working on a few things in this Proxmox Chia VM & those messages seem to have stopped. I’m still not able to sync though. I am doing this on Linux & I don’t think I mixed things between MM / Chia. I don’t have the Chia GUI, everything has been done on Ubuntu Server through CLI. I was following Digital Spaceports videos on YouTube, specifically for Linux / MM. I am going to go through that GitHub link now, thank you. This is what I’m getting now in the logs:

Thank you,

Just noticed that I didn’t include the link to that post about checking on SSL certs. Here it is - Connection closed IP-Address Node Id - #5 by Jacek

So, those non-trusted peers coming from the wallet are not there anymore?

Also, looking at that screenshot, it looks like your harvester may be loading plots every other minute or so. I am not sure what kind of setup gigahorse for chia has, but you may want to check what kind of plot refresh rate you have there for your harvester. You would want to set it up for about an hour or longer, as those plot loads can be heavy on the system. If you are plotted, there is no problem to have it once a day or so.

Just a suggestion. Disconnect your plot drive. Install the gui from cli and run it. Download the blockchain from the chia website and let it sync. U need port 8444 opened thru the firewall or it will take many days. us the port checker to make sure the port is opened, wait for sync, then, reconnect the plott drive.
I have the cli and gui thru the cli install. I then ran the regular deb gui install for ubuntu. They all will run and i can switch between each one, as long as they have the same keys and are pointed to the plot drive. When switching between programs it takes a few minutes for the blockchain to sync but that’s the only drawback.
I switched between MM and chia reg plotter and had no problems. Running on Linux Mint 20.1

Thank you Jacek, I will look at that link. Today, the log is saying Cannot connect to host ssl:<ssl.SSLContext object at 0x7f4e89574540> [Connect call failed (‘’, 8444)] - So I am thinking I need to look more at the SSL settings.

Thank you Dxione, I have the farmer running on Proxmox in an Ubuntu Server VM. I’m also using C8 compressed plots & using the MM software for these C8’s. I don’t think you can run compressed plots with the Chia GUI yet. I have the Blockchain loaded onto this VM from another computer that was synced. I also am sure I have port 8444 open too. I have it open on the firewall & I’ve confirmed 8444 is open in the CLI too.

I’m sure port 8444 is open… I have renamed the synced database I uploaded & deleted the other files, then restarted Chia services. It created a new DB, but it just sits there & is not syncing. I have the Chia GUI / full node open on my desktop (Behind same firewall) and that is able to sync. It actually just finished. The one on this Proxmox VM in Ubuntu Server is not syncing though…

Couple of things about that post. You should use port 8444 on that line (8447 is to check farmer’s cert).

I checked one of those nodes, and luckily the port was open. Here is what you need to look for:

depth=1 O = Chia, CN = Chia CA, OU = Organic Farming Division
verify error:num=19:self signed certificate in certificate chain
140378145167248:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s2                                       3_lib.c:177:
Certificate chain
 0 s:/CN=Chia/O=Chia/OU=Organic Farming Division
   i:/O=Chia/CN=Chia CA/OU=Organic Farming Division
 1 s:/O=Chia/CN=Chia CA/OU=Organic Farming Division
   i:/O=Chia/CN=Chia CA/OU=Organic Farming Division

Basically, that is chia’s signature there (there are more chia related stuff there).

That means that those peers you have on that screenshot are legit, and your side is struggling. So, no need to check more of them, just run it once to get used to that command.

Once you see the result, switch that IP to your local / private IP. If you are running that command from your node, most likely you can use

The output from your node should more or less match what you get from those other peers (maybe not cert data, but all the other info.

Just to be on the sane side, check your config.yaml what is your wallet’s port (should be 8447), and run that command also against that one.

Kind of recalling one previous issue about it, there is a chance that somehow you have mixed up certs, and they may still be valid chia certs, but not for that service. Just check if you have those entries there:

    private_crt: config/ssl/full_node/private_full_node.crt
    private_key: config/ssl/full_node/private_full_node.key
    public_crt: config/ssl/full_node/public_full_node.crt
    public_key: config/ssl/full_node/public_full_node.key


    private_crt: config/ssl/wallet/private_wallet.crt
    private_key: config/ssl/wallet/private_wallet.key
    public_crt: config/ssl/wallet/public_wallet.crt
    public_key: config/ssl/wallet/public_wallet.key

Just pay attention whether what follows config/ssl/ is what the main section is (i.e., full_node and wallet respectively).

That part is irrelevant to the problem. Assuming that the port is closed, your node will be reaching out to other peers. From protocol point of view, there is zero difference whether connection is in- or out-band (it only matters for the health of the overall network).

All those things are irrelevant as long as you are not going to fix that SSL issue.

The only thing that you should worry right now is your config.yaml and .chia/mainnet/config/ssl folder and what is in those service specific subfolders.



I went through this page & did what it said, except the parts about the Windows GUI, since I’m using Windows currently.

Well, as mentioned I don’t run gigahorse for chia, so cannot verify that. Also, I don’t think that MMX setup translates easily to chia’s (yes, services are the same, but protocols differ a bit). The ports that I mentioned are possibly irrelevant, as those are for chia’s setup. It is possible that MM gigahorse may be using different ports for its services (thus that 9256 port). Although, we do not have any problems with ports so far, but with SSL certs, so for now I would go with all those port numbers are good.

Since you have mentioned that you have another box running chia and it is already synced, is that box running chia’s or MM’s software? If that would be MM setup, maybe you could run an experiment as follow:

  1. stop chia on both boxes
  2. move aside .chia folder on both boxes
  3. start chia on the working box, don’t need to login
  4. stop chia on the working box
  5. move .chia folder to non-working box
  6. start chia on that non-working box (assuming the newly generated .chia structure is in place)
    6.1. you may want to adjust config.yaml to whatever folder structure you had before - e.g., dbs, but it is most likely irrelevant to SSL setup)
    7, check the logs whether you are still having those SSL problems.

At this point, I would hope that the non-working box would start syncing. If that is the case, check if those new SSL certs are matching those original ones from the working box. If those are different certs, potentially this structure could be used instead of the old one. It may whine about keys, etc., but those are good errors to have at this point, as not related to SSL problems.

By the way, those cert folders look good, but there is a need to show the main section header (as in my post). I assume that those are good, though.

That page talks about chia’s setup. I am not sure how relevant that is to MM setup, maybe not at all. I really don’t know how close the internal MM-for-chia structure is to chia, but I would assume there is no point to be compatible. So, I would really only follow what is on github gigahorse for chia read-me(s).
Maybe there is one more possibility. I am not sure whether MM is using .chia folder structure. Maybe that is just some leftover from an old chia setup.

The working box is my desktop computer, from when I first started looking at farming Chia (Running Windows 11 with the Chia full node GUI). As I got into this more, I bought a Dell R720XD & started learning how to setup Proxmox on it. It has a VM for plotting, a VM for Farming & a VM running TrueNAS for storage. I read most things are similar between MM & Chia, but instead of using chia you use ./chia in commands.

I have not seen anything like that on anything on my end. Where did you get that from?

Thank you VERY much for your help!

openssl s_client -connect YOUR_FARMER_PRIVATE_IP:8444

Not sure how far that notion goes. As mentioned, the only thing that needs to be the same is port 8444 protocol, and from farmer to the pool. Everything else is whatever was working for Max.

There are significant differences between MMX and chia (on internal protocol levels), thus being Max, I would make MM-for-chia internally as close to MMX as possible, just to dump the historical garbage from chia and when fixes are needed be able to reuse the code. Otherwise, that would be more or less like Flax or any other clone that basically runs unmodified chia fork. So, milage may really vary.

Can't use SSL_get_servername
depth=1 O = Chia, CN = Chia CA, OU = Organic Farming Division
verify error:num=19:self-signed certificate in certificate chain
verify return:1
depth=1 O = Chia, CN = Chia CA, OU = Organic Farming Division
verify return:1
depth=0 CN = Chia, O = Chia, OU = Organic Farming Division
verify return:1
Certificate chain
 0 s:CN = Chia, O = Chia, OU = Organic Farming Division
   i:O = Chia, CN = Chia CA, OU = Organic Farming Division
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Apr 11 14:18:39 2023 GMT; NotAfter: Aug  2 00:00:00 2100 GMT
 1 s:O = Chia, CN = Chia CA, OU = Organic Farming Division
   i:O = Chia, CN = Chia CA, OU = Organic Farming Division
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan 23 08:51:06 2021 GMT; NotAfter: Jan 21 08:51:06 2031 GMT

When you put a block like that, select all lines and hit Ctrl+e, as that would remove formatting (e.g., font size, weight).

Not sure what that second line means (Can’t use SSL_get_servername), but the rest looks good. Looking at that github ticket Can't use SSL_get_servername · Issue #12731 · openssl/openssl · GitHub, I would start worrying, though. Read mattcaswell comment there (second from the bottom - That error just seems to indicate that the server has not acknowledged the SNI extension in the ClientHello - which may or may not be a problem..

When I hit one of those peers from your list, I didn’t get that error. I don’t really know how relevant SNI is, but maybe relevant enough to have those peers tell your node to get lost. Maybe that is somehow related to how proxmox is handling those VMs. Maybe, when you setup such VM, you need to ask proxmox to use bridged rather than masquareded IP path (don’t know anything about proxmox, so cannot help with that).

Basically, openssl / s_client may be more forgiving as far as such errors, thus recovered from that error, where chia’s implementation is quite rigid thus those peers barfing at your node.

Thank you, I fixed the formattig.

@jonesjr if you have a minute, could you help here. It looks like the issue may be with proxmox VM setup. Basically, neither the node nor the wallet can connect to any peers, as handshake is rejected due to SSL problems.

When using openssl s_client -connect on the proxmox chia there is an SSL potential problem that may be related to why those peers are dropping connections. (There is no such error when connecting to those peers, thus suggesting proxmox VM setup issue.) Maybe this is somehow related to how Ethernet is setup for that VM (is not in a bridged mode). Usually, the SSL SNI problems are related to HTTP virtual hosts that are not the root host for a given cert, but I am not sure how that could translate to proxmox setup.

You potentially know the most here about proxmox, so may know the problem already.