Table of ContentsWhat are harvesters, farmers, full nodes, and timelords?

You can read about each of them and the architecture in the network architecture document. The consensus document is the most current documentation, however. You can also check out our Timelord documentation.

A proof of space is a proof that a farmer has allocated a portion of their storage in a way that is very difficult to create in real-time but efficient to pre-compute and store on a hard drive. The Chia Proof of Space Construction document goes deeply into the math and implementation considerations to mitigate Hellman's Time - Memory tradeoff problem. A plot is a large set of proofs of space. A harvester can harvest multiple plots on the same machine. A farmer can then control multiple harvesters across many machines to manage the whole "farm."

Farming uses substantially less electricity than Proof of Work for the same unit of security. You can learn more at chiapower.org.

A VDF, also known as a proof of time, is a sequential operation that takes a prescribed amount of time to compute (and which cannot be accelerated by parallelism) and which produces an accompanying proof whose result may be quickly verified. This must be done in a group, for which Chia uses ideal class groups. You can learn about them in our class group document. Timelords usually run three VDFs at a time for the three internal blockchains of the Chia blockchain. They run as vdf_client processes.

XCH is the currency symbol for Chia. TXCH is the currency symbol currently being used for testnet chias. TXCH has no value and is only used for testing purposes. Chias and testnet chias can be divided up to 12 decimal places (trillionths). The smallest unit of chia, a trillionth of a chia, is called a mojo, as a tribute to Mojo Nation, a decentralized file storage platform created in the early 2000s by Zooko Wilcox, Bram Cohen, and others.

"k" is the space parameter that controls the size of plots. It is an integer for the following equation: plot_size_bytes = C1 * 2^k(k + C2) where C1 is constant 1 and C2 is constant 2. In practice this means that final size is roughly ((2 * k) + 1) * (2 ** (k - 1)) * 0.762 though that constant is estimated. You can examine the Space Required section of the Chia Proof of Space Construction document for the calculation of how much space is required for a given k.

You can see some example plot sizes, times to plot, and working space needed based on various k's in these k size tables. Current working space needed for the default plotting options of a k=32 is 239 GiB and the final file is approximately 101.4 GiB. There is small natural variation in temp space needed and the final file size of each plot. Note that 239 GiB is 256.6 GB.

The minimum plot size is k=32. There is only one reason why you might want to plot larger than k=32: to maximize the total utilization of a given drive or space. A couple of k=33 plots with a majority of k=32 plots can reduce the amount of leftover unused space on a drive.

The reason k=32 was chosen as the minimum plot size was to prevent a short-range replotting attack, which is detailed in our consensus doc. The gist of the attack is that if someone can create a plot in less than ~30 seconds, they could create a new plot that passes the filter for each signage point, and then delete the new plot immediately afterward. This would effectively emulate storing 512 plots, thus turning Chia into PoW.

This attack won't be economically feasible for some time, if ever. Two potential mitigation techniques are to lower the plot filter (thus reducing the benefit of the attack), or to increase the minimum plot size (thus making the attack more difficult to perform).

k=32 is expected to be the minimum plot size until at least 2026. If and when that size is increased, you will be given ample notice to replot before the change is made effective.

We think you will want to use used Data Center grade NVMe SSD drives to create your plots. Regular consumer NVMe SSD generally has too low of a TBW rating. One of our community members keeps this handy SSD Endurance document up to date so you can compare various SSDs. You should never use your root/OS SSD to plot as it can lead to drive failure and loss of booting. You can plot directly to hard drives and get good results, especially if you plot in parallel to different drives. You can use non-root SSD over Thunderbolt 3 and migrate your plots off to whatever storage you want to keep them on long term. You could even load them on a Raspberry Pi 4 with outdated USB 2.0 drives attached and they will harvest and farm just fine. PC World offers this great background on current storage technologies but this graph gives you a quick view of why we recommend NVMe SSD:

Yes, using either the GUI or CLI. Over the short run you have a bit more control of plotting using the CLI. There are tips for Windows users and Mac users can find their CLI commands in the Quick Start Guide. You may have better results if you stagger the start time of parallel plotting processes depending on your hardware setup.

Yes. The moving plots topic here on the wiki gives you the details. You may also want to consider running a remote harvester. You can also use the same private key set to plot on more than one machine at a time but be aware of the uPnP issues.

-2 is in use during phase 3 and 4. It is the file being built into the resulting .plot file. As it is done compressing tables during phase 3, it will move them into the .plot.2.tmp file (-2), and phase 4 will scan through the entire .plot.2.tmp (-2) file, and write table headers for easy access by the harvester. When phase 4 is done, if -2 = -d, it will simply rename the .plot.2.tmp to .plot. If -2 != -d, it will copy the file into place, then rename, and finally remove the -2 file. The amount of writing is about 110% of the resulting .plot file size. It is a setup dependent option - is your setup faster at moving the compressed tables into the .plot.2.tmp file, and then scan through the entire file, and write table headers during phase 4 - and then copy to -d (-2 = -t) - or is it faster to send the compressed tables directly into the -d (-2 = -d) directory, and then in phase 4, scan through the entire file, and write table headers inside -d (-2 = -d) thereby skipping the final copy into place. The -2 directory can be set in the Advanced Options for Step 3 in the GUI.

If you see something like Caught plotting error: Not enough memory for sort in memory. Need to sort X.XXGiB then you need to either select more memory buffer or more buckets. More buckets require less memory but will create more temp files and more sporadic disk writing. You will almost always want to use 128 buckets and you should try increasing the RAM max usage/-b to 4608MiB.

This is a RAM problem with your machine. It can be how your swap file is configured. It is often your overclock, or XMP settings and even can be a faulty RAM stick. Chia plotting is better than memtest at surfacing broken or mis-configured RAM.

Unfortunately, resuming a plot is not supported. We suggest that you disable power saving mode - especially for external drives - and try to limit other possible causes of interruptions. Plotting a k=32 could take multiple hours, depending on your hardware, so these interruptions can be painful. They are also a part of why we don't recommend plotting plots larger than k=32 as each increment in k generally doubles the time to complete a single plot.

No. Plotting can be done entirely offline and needs nothing from the blockchain to complete. The only time you have to be online and synced is when you're farming so that you receive new challenges for the next blocks and transactions to include in a transaction block if you're lucky enough to win one of them and get the transaction fees. Note that one farmer winning is independent of other farmers winning at the same time. All farmers can "win" at nearly the same time. That is why sometimes there are 10 blocks in one minute, and sometimes there is only 1 block per minute, etc.

No. As long as you plot at least k=32, those plots will be eligible to win on mainnet. In a decade or more, k=32 may become too small, but that's speculative. Usually the only reason to plot larger than k=32 is to optimize using all of the space on a given drive. For example, it may make sense to have two k=33's and the rest k=32 so that you only leave 10 GB free on a given drive.

Yes.

Run chia plots check -n 30 to try 30 sample challenges for each plot. Each of your plots should return a number around 30, which means it found around 100% of the attempted proofs of space. If you're still worried try -n 100 as more random attempts will give you a more valid assessment that the plots is fine. It really is ok if your plot is within 80%-120%. If some of your plots are missing for some reason you may need to add the directory they are in to your config.yaml file. That can be done in the GUI with the MANAGE PLOT DIRECTORIES button or on the command line with chia plots add -d [directory].

UPnP is an optional setting that allows users to open a port in their router and therefore allow other nodes to connect to them. This is not required, since your node can still make outgoing connections without UPnP.

For some routers, UPnP is enabled automatically, but for others, you might have to go into your router settings and enable UPnP manually. Sometimes restarting the router is also necessary.

Another option is port forwarding, where you tell your router/NAT to forward requests on port 8444 or 58444 for testnet to your machine.

First, running more than one node with the same private keys on your home network is wasting bandwidth by syncing two copies of the blockchain over your download link. You can get the same results by running one node and using multiple harvesters on multiple computers. Second, if you have uPnP enabled on both nodes and your home router supports uPnP (and most do) it will cause both of your nodes to not sync the blockchain. You need to disable uPnP on all or all but one node behind a uPnP enabled router. The CLI command chia configure --enable-upnp false will turn uPnP off on a node. It requires a restart of the node to take effect. If you disable UPnP on all but one of your nodes then your local router will forward inbound 8444 traffic to the one node and the rest will now be able to connect to the network but just will not accept inbound connections from the network.

Step 1. Make sure you are running the most recent version of the Chia software. Check out the INSTALL page.

Step 2. If your node has no connections, it could be one of many reasons. The most likely reason is that there are no users with space to have new connections, so you cannot connect to them. To solve this, you should try opening port 8444 on your router so other peers can connect to you. Follow the steps here: Resolving Sync Issues Port 8444

Port 8444 is the port through which other Chia computers can communicate with your PC. When you set up port forwarding on port 8444, the Chia software on your computer can quickly talk to other PCs, link up, and start downloading and syncing with the Chia blockchain.

The network is undergoing rapid growth and expansion. Many of the newly arrived Chia peers (computers) do not open up port 8444. It makes it very hard for the network. So please port forward on port 8444!

Use this link to check if your router's port 8444 is closed: https://portchecker.co/

Step 3: You might need to disable UPnP in the config file (~/.chia/mainnet/config/config.yaml) or by using the cli command chia configure -upnp false. You might have multiple nodes running on the same machine, or in the same wifi network. Make sure to close all Chia applications on your computer. Also check your firewall or antivirus software, which might be blocking connections.

Step 4: Try deleting your peer DB which is located at ~/.chia/mainnet/db/peer_table_node.sqlite. Close then restart Chia.

Step 5: Edit ~/.chia/mainnet/config/config.yaml, search for weight_proof_timeout and increase it from 180 to 400. If that value is not there, you can add it under the full_node section.

It can take a few minutes to start receiving peers and several hours to completely sync.

This is usually a system clock issue, which is causing the display of "Not synced", even though you are. Your clock must be set to the exact time, and cannot be more than 5 minutes off. Check your phone and your computer and ensure the time is the same.

Beginning in 1.3, Chia uses version 2 of its blockchain database. The new database is still written in SQLite, but it has undergone a series of optimizations, such as storing hashes in binary, rather than human-readable hex format. It also is more compressed than version 1. These two factors combined have resulted in an approximately 45% reduction in the size of the database, as well as a slight improvement in its performance.

If you install a brand new full node in Chia 1.3 or later, version 2 of the database will be created when you run chia init. If you want to stick with version 1, simply run chia init --v1-db instead.

If you were already were running a full node prior to upgrading to Chia 1.3, the upgrade will not happen automatically. The command to perform the upgrade is chia db upgrade. This is documented in detail in our CLI reference.

You do not need to stop Chia in order to perform the upgrade. This is because the program performing the upgrade only needs to read from your original database file, while your upgraded file will be written alongside it in the same folder. Be sure you have enough free space on the disk that contains your database file to write the new file.

The current size requirement (2nd quarter 2022) is around 55 GB. Note that the database is always growing, so the size requirement for the v2 database will have gone up by the time you are reading this plan accordingly.

The upgrade could take several hours, so feel free to perform it at your leisure. After the upgrade has completed, run chia start farmer -r to restart your farmer and switch to the new database.

Note that the new database will have the same peak as version 1 at the time you initiated the upgrade. Your node will still need to run a short sync to fetch the remaining blocks that had gotten added while the upgrade was being performed.

Because the upgrade from version 1 to 2 of the database is time-consuming, most users will likely only perform it on one of their systems and copy the new database file to their other systems afterward. If you choose this option, be sure to either copy the file before running chia start farmer -r, or stop Chia altogether if it is already using the new database. Once the database is swapped from v1 to v2, you also need to update you config.yaml to reflect the new v2 database change. Under the full_node: section set database_path: db/blockchain_v1_CHALLENGE.sqlite to database_path: db/blockchain_v2_CHALLENGE.sqlite

WARNING: If you copy your database file to another computer while Chia is currently using it, you'll risk corrupting it, which will necessitate a full sync from genesis.

If you're interested in learning more technical details of the new database, see the first Github Pull Request that introduced the changes:https://github.com/Chia-Network/chia-blockchain/pull/9442

And there were two follow-up Pull Requests with additional improvements, along with some benchmarks.https://github.com/Chia-Network/chia-blockchain/pull/9454https://github.com/Chia-Network/chia-blockchain/pull/9455

Finally, here is the Pull Request that added the upgrade functionality:https://github.com/Chia-Network/chia-blockchain/pull/9613

When you load Chia's client GUI for the first time, you'll be asked to choose whether to run in Wallet Mode or Farming Mode. Here are the main features of each mode:

Wallet Mode:

Farming Mode:

To switch between Wallet Mode and Farming Mode, click the gear icon on the upper-right side of your client. The settings menu will appear. Click the desired mode.

Note that in both modes, the light wallet protocol is always used. This protocol will sync your wallet by only downloading information from a subset of the blocks. The more transactions your wallet has had, the longer this process will require.

The following are situations when your wallet will NOT connect to external peers:

For example, let's say you're running Chia for the first time and you have not modified connect_to_unknown_peers. Here is one potential workflow:

Depending on how you are using your Chia client, we recommend the following:

There are two types of peer nodes -- trusted/known and untrusted/unknown. By default, your local node is your only trusted node. It is possible to add other nodes to the trusted list, for example if you personally run more than one full node. One reason to add a trusted node is to speed up the sync time of your light wallet.

The light wallet protocol has two techniques to sync:

Typically, it is much faster to sync a wallet by connecting to a trusted node. Therefore, if you have access to a synced node that you trust, you may want to add that node to your trusted peers list. We recommend that you only add your own full nodes to this list.

Inside the wallet: section in config.yaml, you should see trusted_peers:. Add a new line with the value of Node ID, like this example (do not use this Node ID, use the one from your trusted node):

This response will give a non-technical overview of Chia's light wallet syncing process. For technical info, see our docs site, as well as the FlyClient White Paper, which details the process from which Chia's light client is based.

First, a bit about addresses in Chia. A single Chia wallet can use up to four billion (2^32) addresses. Hopefully, you won't need more than that! Using multiple addresses can help provide anonymity. Rather than having to sign up for a new account each time you want to receive money, you can simply click "NEW ADDRESS" and presto -- a new address appears. Additionally, each time you receive change from sending money, a new address is automatically generated. Your wallet keeps track of each of the addresses that have been used. As long as your wallet is synced, it always knows how much money you have.

One important thing to remember is that your wallet addresses will always be generated in the same order. When you generate a "new" address, you're actually calculating the next address in the sequence. Your wallet doesn't know what the next address will be until it's generated, but the sequence will always be the same. For example, if you generate 50 new addresses (and write them down), and then install Chia on a new computer and import the same wallet, the first 50 addresses you generate will exactly match those from your original computer.

Next, we'll introduce a setting called initial_num_public_keys. This setting is part of config.yaml, located in ~/.chia/mainnet/config on Linux and MacOS, and C:Users.chiamainnetconfig on Windows. The default value of this setting is 100. The majority of users should not change it.

You can think of initial_num_public_keys as the number of future addresses to examine. It's a window that expands with time (and never contracts). Here's how it works:

The first time you run Chia's software, your wallet will attempt to sync. It does this by checking the first address in the sequence. If that address has ever received money, your wallet will account for that transaction history and examine the next address, and so on. It would take a very long time to examine all four billion addresses, so your wallet will stop looking at some point. This is where initial_num_public_keys comes in.

By default, your wallet will stop after it has examined 100 straight addresses that have never received money. If it examines 50 empty addresses and then finds a transaction on the 51st address, the number left to examine is reset back to 100. Because the addresses always appear in the same sequence, it will be rare to have even a single address without any transaction history. But there is one exception: if you click "NEW ADDRESS" twice, then one address will remain unused. If you click "NEW ADDRESS" 101 times without receiving money at any of those addresses, then you'll have 100 consecutive unused addresses in the sequence. Let's say you receive money at the 101st address. When your wallet attempts to sync, it will stop looking after the 100th blank address. Transactions from subsequent addresses will remain undiscovered, and your balance will be incorrect.

The default setting for initial_num_public_keys is quite conservative -- it should be rare for anyone to click "NEW ADDRESS" more than 100 times without actually using any of those addresses. That said, you might have a legitimate reason to do this, for example if you're running an exchange. In that case, feel free to set initial_num_public_keys to a higher number, stop your wallet, delete your wallet database, and start your wallet again to begin a fresh sync.

Why not set initial_num_public_keys to a higher number by default? Because it would take longer for your wallet to sync. Why not set it lower? If the default setting were 2, most wallets would likely still show the correct balance and the sync time would be faster. However, we set the default to 100 to prioritize showing the correct balance over syncing as fast as possible.

How does your wallet know it has the correct info for each address? It polls one or more of its peers. These peers can be either trusted or untrusted, as explained in the previous question. By default, your own node is the only one you trust. If your node is fully synced, then your wallet only needs to query your node to determine your transaction history for each address. If your node is not fully synced, then your wallet will query a number of peers about this info. If any of them lie, omit info, or disconnect in the middle of a query, your wallet will know because the responses won't all match.

If you believe your balance is incorrect, changing initial_num_public_keys is unlikely to fix the problem. If at all possible, you should sync a full node, stop Chia, delete your wallet database, and start Chia again. This time, Chia will sync based on your own node alone. If this is not an option, then resyncing from untrustred nodes might fix the problem as well.

If you see plots in the Plots section of the Farm page in the GUI - your plots are being farmed. You will see challenges and proof attempts as they come through in the Last Attempted Proof section however you usually will not have a proof worth sending to the network due to the plot filter. You can additionally see the Total Size of Plots on the Farm view and it will tell you how much unique space is being farmed and statistically how long it should take - on average - to win a block.Also, your node needs to be synced for you to farm properly. In the GUI, check the Full Node page. On the cli, do chia show -s -c.

No. You have 30 seconds to respond to challenges.

ChiaCalculator.com does a good job at running the numbers.

First, the bad news. Statistically, it would take multiple years to win a reward with a 10-TB farm. ("So you're saying there's a chance...")

Now, the good news. You can join a pool and collect regular rewards, no matter your farm's size! See our Pooling User Guide for more info.

Farmers compute a plot filter based on the signage point, their plot id, and the sub-slot challenge - which are hashed together to create the plot filter bits. If the plot filter bits start with 9 zeroes, that plot passes the filter for that signage point, and can proceed. This disqualifies around 511/512 of all proofs of space on the network, for each signage point. There are 4608 * 2 or 9216 signage points per day so the average plot should pass the filter 18 times per 24 hours on average. Once a plot passes the plot filter it then competes for the best proof of space with every other plot that also passed that plot filter for that signage point. For reasons that aren't super simple to intuit, the only thing each plot is competing on is to have the best proof of space and thus the chances of getting a reward depend on total size of plots on the farm - even with the plot filter in place.

As long as the plot passes the filter, and do not have any internal file errors, the plot will always be eligible to compete for the best proof of space. Moving the plot to another directory or server will not change its eligibility.

Please note that the speed of your lookups when passing the plot filter should be below 5 and preferably below 2 seconds. When you actually win a reward, your drive will have to do more lookups than these, so it's important that the the lookups are happening fast.

Yes you can. Please check the Pooling User Guide.

There is a possible attack where an attacker who can co-ordinate N deep from the tip of the chain can try to coerce a winning farmer to re-write a historical transaction block. This attack is much more difficult and thus less of a risk in new consensus and thus we only recommend deleting and re-plotting a plot to farmers with in excess of 1PB of farm size. Anyone smaller than that would be difficult for an attacker to locate and can more safely continue to farm plots that have already won. We plan to have the software automate the process up to and including kicking off a remote plotting process if the current hardware that a farmer or harvester are on is not up to the task of re-plotting. But to repeat, deleting winning plots is, and will always be, totally optional.

No, your plots are virtually unaffected by the passage of time, aside from hardware errors. Even in the presence of bit flips due to aging hardware, plots remain mostly effective. The only cases where you would need to re-plot are: 1. if you are using solo plots (not NFT plots) and wish to join a pool (please see note below) or 2. if hardware speeds advance to the point of a certain k value becoming obsolete (e.g., k=32 becomes too fast to plot and we ban them, forcing you to replace them with k33 plots). For case 1., you are free to have any mix of solo plots and pool plots if you do not want to re-plot. For case 2., k=32 is not expected to become outdated until sometime between 2026-2031.

It is unlikely, but it is possible. There are multiple reasons why this might be the case. The most common is that due to network delay, or drive speed delay (for example using a slow NAS), you missed the time for inclusion into the blockchain, which is 28 seconds. This time is from when the timelords create the signage points, to when the timelords infuse your block. Check to make sure that you are connected and synced to multiple peers, and that your quality lookup are fast (<2 seconds, definitely less than 5). Another reason might be that the signage point where you won did not get included into the blockchain. This can sometimes happen, since timelords may publish signage points that don't end up on chain.

The Wallets page in the GUI will display your receive address and provide an interface for you to spend your chia funds. You can also obtain a new wallet receive address any time you would like and those funds will all come to the same place as they are based on HD Keys.

There is growing wallet functionality available on the command line. Try chia wallet -h. Wallet software also provides features related to CAT's, and trade offers. You can get a receive address on the cli with chia keys show.

The coin (or UTXO) model is a Bitcoin-style transaction model which is also used in Chia. Your wallet keeps track of a set of coins, where each coin can be any amount of XCH. When spending a coin (making a transaction), you have to spend the entire amount, and split that coin into multiple outputs, called coin additions. One addition is to the recipient of the transaction, and the other one is to you, as change. The change usually goes to a new address, so you will not see it in your normal address on Chia explorer, but your wallet will keep track of it and include it in the balance. Each block in Chia is a list of removals (coins spent) and additions (coins created). There are no transactions in the blockchain, which is why you cannot lookup transactions in the block explorers.

HD or Hierarchical Deterministic keys are a type of public key/private key scheme where one private key can have a nearly infinite number of different public keys (and therefor wallet receive addresses) that will all ultimately come back to and be spendable by a single private key.

Small reorgs in Chia are possible, though rare. In order to be confident that your transaction won't be reorged, you should wait around six blocks, or two minutes, after the first confirmation. More details are available in our consensus documentation.

Try the following options:

To delete your wallet DB follow these steps:

Your pending transaction can take a few minutes if blocks are full. If it's not confirmed after a while, your pending transaction might be stuck. Try the following steps:

Known problem: After your wallet is resynced, any previous outgoing transaction will appear as incoming transaction at the block height you made the outgoing transaction.

Visit chia.net/buy-xch for instructions on buying Chia with USDS and offers using the Chia light wallet and Offers.

There are also several exchanges that offer XCH. You can see a list of exchanges supporting XCH here. This list is for informational purposes only. It is up to the reader to do their own research on the best exchange for their needs.

If you were running the light wallet beta app (v1.2.11 dev 265) and youve upgraded to the latest beta (v1.2.12+), you can get your offer history and your CAT wallets back by following these instructions:

This is because of the newly integrated light wallet client sync. The wallet will sync through the light wallet sync while the full node syncs up in the background. Once the full node is synced up, then the wallet will sync primarily through the local trusted full node.

If youve lost your offer history and want to cancel those offers but cant access them, then the only way to cancel the offer would be to send yourself a transaction with the CAT tokens that were part of the offer.

The wallet no longer automatically adds unknown CATs wallets for CATs that may have been airdropped to your wallet. This is to help ensure that syncing doesnt slow down with all the additional CATs that could suddenly show up. It is recommended that you use a tail database to look up and add. We understand that this will add some extra work to know which CATs to add wallets for and set them up manually. We do hope to improve upon this experience Soon

This is the way our tools work today. Just make sure when you submit feedback or an issue in Github to use the app version (1.2.12 dev269) when reporting it so we know exactly which version you're running.

Follow this link:

FAQ Chia-Network/chia-blockchain Wiki GitHub