Setting up a Bitcoin full node comes down to three main questions: Do you have enough disk space? Can you accept the syncing time? And what do you plan to use the node for? If you only want your wallet to broadcast transactions and verify incoming payments through your own node, a pruned node is enough. You do not need to prepare a 1TB hard drive. A pruned node still downloads and verifies the entire blockchain history. It simply deletes old data after verification is complete, so there is no real sacrifice in security.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
First, Decide: Archival or Just Enough
Before you open the download page, make this decision. It affects every configuration that follows.
Archival Node stores the complete blockchain data from the genesis block to the present. You currently need to reserve 600GB or more of free space, and it grows by about 50–100GB per year. This option suits scenarios where you need to serve historical blocks to other nodes, run a block explorer, or perform on-chain data queries.
Pruned Node is also a fully validating node. It downloads and checks every transaction in every block, but after verification it deletes old block data according to the limit you set. You can set the block data limit as low as 550MB. In practice, total usage including the UTXO database and chain state usually means you should reserve 10–25GB. The trade-off is that a pruned node cannot serve historical blocks to other nodes, cannot rescan old transactions for a wallet, and cannot enable the -txindex transaction index.
My recommendation: If your goal is simply to connect your wallet to your own node and avoid relying on third parties for broadcasting and queries, choose a pruned node. If you clearly need to query arbitrary historical transactions or run an Electrum server, then consider an archival node.
Download and Verification
The official Bitcoin Core download page is at bitcoincore.org/en/download. As of October 2026, the latest version is 31.0.
Choose the installer for your operating system. After downloading, the official recommendation is to verify the integrity of the file. Verification has two steps: first check the SHA256 checksum, then use GPG to verify the signature of the checksum file itself. On Windows, you can use certUtil -hashfile in the terminal to generate the file hash and compare it character by character with the record in the official SHA256SUMS file. The node can run without this step, but if the file was tampered with or corrupted during download, the node may behave abnormally. The verification process is not complicated and is worth a few minutes.
Bitcoin Core supports Linux Kernel 3.17+, macOS 13+ (version 28.1 supports macOS 11+), Windows 10 and newer.
Configuration: Pruning, Cache, and RPC
The Bitcoin Core configuration file bitcoin.conf is located in different places depending on your system: Windows at %AppData%/Bitcoin, macOS at ~/Library/Application Support/Bitcoin, Linux at ~/.bitcoin. If the file does not exist, create it with a text editor.
Set the pruning size. Add prune=10000 to bitcoin.conf. This keeps block data at about 10GB. The official minimum is 550MB, but that only retains roughly the last 288 blocks, or about two days. If a chain reorganization happens, the rescan space is very tight. 10GB is a more comfortable starting point. Actual disk usage will be between 15–25GB because the chain state database itself is about 12GB and keeps growing.
Allocate database cache. The most effective optimization for syncing speed is dbcache. The default is about 450MB, which is small for modern machines. If you have 8GB or more of RAM, set dbcache=4096 (4GB). With 16GB of RAM, you can set dbcache=8192. After syncing is complete, this cache usage will drop, so you do not need to keep such a high value long-term.
Enable RPC service. If you plan to let Sparrow or another wallet connect to this node, you must add server=1. This line allows Bitcoin Core to accept connection requests from local applications through the RPC interface. If you only use Bitcoin Core's built-in wallet GUI, you can skip it. But for the common need of using your own node with an external wallet, server=1 is a prerequisite.
If you need to connect to the node from another machine on your local network, you also need to configure rpcbind, rpcallowip, and an RPC username and password. Do not expose the RPC port directly to the public internet.
Syncing: Expected Time and How to Check Progress
After the first launch, Bitcoin Core enters Initial Block Download (IBD). It first quickly downloads block headers, which finishes within minutes, and then downloads and verifies full blocks one by one.
Syncing time depends on hardware and network: SSD + 16GB RAM + fast internet takes about 4–8 hours; SSD + 8GB RAM + normal broadband takes 12–24 hours; a mechanical hard drive or low-power device can take several days. This is normal and is determined by the size of Bitcoin blocks and the verification workload.
Use bitcoin-cli getblockchaininfo to check the status. Pay attention to two fields: verificationprogress shows the progress percentage, and initialblockdownload must be false before syncing is truly complete. Note that the number of block headers usually runs ahead of the number of verified blocks. This is normal. Do not think the node is stuck just because blocks is temporarily behind.
If progress does not move for a long time, first check whether the network connection is normal. Since Bitcoin Core v25, there have been improvements to slow peer disconnection. The adaptive timeout mechanism reduces repeated disconnections caused by a single slow peer. Another common cause is disk I/O becoming a bottleneck. Mechanical hard drives will significantly slow things down at this stage.
Connecting a Wallet: Sparrow Configuration
To connect Sparrow Wallet to a local Bitcoin Core node, make sure server=1 is present in bitcoin.conf. If Bitcoin Core has not finished syncing, Sparrow may connect but cannot correctly scan balances. The wallet needs the node to provide complete on-chain data to query address history.
When Sparrow connects to a local node, you usually do not need to manually enter an RPC username and password because it uses Bitcoin Core's cookie authentication. If the node is on another machine, you need to configure rpcuser, rpcpassword, rpcbind, and rpcallowip in bitcoin.conf, and then enter the corresponding IP and credentials in Sparrow.
A practical limitation of pruned nodes: If your wallet is an imported old wallet, Sparrow may need the node to rescan the blockchain to find historical transactions. A pruned node can only scan from the earliest block it still retains. Earlier records cannot be recovered. For newly created wallets or wallets that have been in continuous use, this problem usually does not occur.
Risks and Checkpoints
The most notable risk during the download and configuration stage is running an unverified client. The consequence of running without verification may be abnormal node behavior, and in extreme cases it could be a fund security issue. The official verification steps are not complicated. At minimum, complete the SHA256 checksum comparison.
You do not need to sit and watch the syncing stage, but pay attention to disk space changes. The actual usage of a pruned node will be slightly higher than the prune setting because the chain state database is calculated separately. If the disk is nearly full, the node may stop working properly.
After syncing is complete, you can use bitcoin-cli getblockchaininfo to confirm that initialblockdownload is false, and then check the node connection status in Sparrow. From then on, your wallet's transaction broadcasts and address queries go through your own node, no longer relying on public servers.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
References
- Bitcoin Core·Download - Bitcoin, page undated; accessed: 2026-10-08.
- Bitcoin Core Documentation·Running a Pruned Node, published or updated: 2026-03-02; accessed: 2026-10-08.
- Chainstack·How much does it cost to self-host a blockchain node in 2026, published or updated: 2026-09-21; accessed: 2026-10-08.
- Blockstream Help·Should I run a Bitcoin full node or a pruned node?, page undated; accessed: 2026-10-08.
- GitHub·studyknots running-a-node.md, page undated; accessed: 2026-10-08.
- Bitcoin Core Documentation·Initial Block Download, published or updated: 2026-03-02; accessed: 2026-10-08.
- Bitcoin Core·Bitcoin Core 30.0 Release Notes, published or updated: 2025-10-09; accessed: 2026-10-08.
- Bitcoin Core·Bitcoin Core 28.1 Release Notes, published or updated: 2025-01-08; accessed: 2026-10-08.
- Sparrow Wallet·Connect to Bitcoin Core, published or updated: 2024-06-25; accessed: 2026-10-08.
- Big Data Week·Running a Bitcoin Full Node: Practical, Opinionated, and No-Nonsense, published or updated: 2025-07-17; accessed: 2026-10-08.
- Jameson Lopp·Revisiting Bitcoin Network Bandwidth Issues, published or updated: 2023-08-04; accessed: 2026-10-08.
