TL;DR: To run a Bitcoin node, install Bitcoin Core (or another compatible implementation), let it download and validate the full chain, and configure it to stay synced and reachable. The Bitcoin node hardware floor is a recent x86 or ARM machine with at least 8 GB of RAM, an SSD, around 1 TB of free space for a full node or as little as ~15 GB for a pruned node, and a broadband connection. A Raspberry Pi handles a pruned node well. Initial Block Download (IBD) takes about 8 to 24 hours on an SSD with good bandwidth, longer on slower hardware. Operators who would rather not manage hardware can use a hosted node service instead.
What Setting Up a Bitcoin Node Actually Involves
A Bitcoin node downloads every block, validates every transaction against consensus rules, stores the resulting state, and serves blocks and transactions to peers. Running one means running software that does all of that without trusting anyone else's view of the chain. Bitcoin Core is the reference implementation and the most common choice; Bitcoin Knots and Libbitcoin follow the same consensus rules.
Five steps describe the entire process:
- Download the Bitcoin Core binary or source.
- Verify the download against the project's SHA256 checksums and GPG signatures.
- Install (extract the archive, run an installer, or compile from source).
- Configure the node by editing bitcoin.conf.
- Start the node and wait for Initial Block Download to finish.
Each step is covered below.
Premade Node Distributions for Newcomers
A novice should opt for one of the open platforms maintained by the Bitcoin community, some with dedicated hardware and some software-based. Below is a select list of such distributions:
Each of these solutions has an easy-to-follow setup process and may offer additional functionality, including BTCPayServer, Electrum, and the ability to use Bitcoin layer-2 protocols like Lightning and Liquid, which makes the node easier to administer.
Hardware Requirements
Bitcoin node requirements are modest: a desktop or single-board computer is enough. The constraints are storage and disk speed, not raw CPU.
A recent x86_64 laptop, a Mac, or an ARM board such as a Raspberry Pi 5 all work. RAM should be at least 8 GB; 16 GB allows a larger database cache during IBD.
Storage matters most. An SSD is strongly recommended for a full node because validating blocks during IBD involves heavy random I/O against the UTXO set, and a spinning HDD turns hours into days. The Bitcoin blockchain occupies roughly 745 GB as of 2026-06-03 (blockchair), and grows by about 50–80 GB per year. A 1 TB SSD gives a full node room for several years of growth. A pruned node keeps only the most recent blocks beyond the configured threshold and can run on as little as ~15 GB (the UTXO set plus a small block budget).
A wired broadband connection is preferred over Wi-Fi. Initial Block Download moves several hundred gigabytes, and steady-state operation for a listening node uses approximately 100–200 GB per month (varies by hardware and bandwidth) depending on peer count.
CPU requirements stay low. Block validation is mostly signature verification and hashing; a modern multi-core CPU validates blocks faster than they arrive once IBD is complete.
Running a Bitcoin Node on a Raspberry Pi
A Raspberry Pi is one of the cheapest ways to run a Bitcoin node, especially a pruned one. A Raspberry Pi 5 (or a Pi 4 with 8 GB of RAM) paired with a 1 TB SSD over USB 3 runs Bitcoin Core comfortably. A pruned node at the 550 MB block floor fits on a smaller drive while still validating every block in full. Premade distributions such as Umbrel, RaspiBlitz, and Start9 target this hardware and handle the install. A Raspberry Pi node is low-power enough to leave running 24/7 at negligible electricity cost.
Do Node Operators Need Their Own Hardware?
Running a node on owned hardware gives the strongest sovereignty: the operator controls the machine, the keys, and the network path. For operators who want a node without buying, configuring, and maintaining hardware, a hosted node service is an alternative. Blockstream Greenlight runs Lightning node infrastructure on behalf of the user while the user keeps the keys, giving a wallet Lightning capability without managing a server. (Greenlight is hosted Lightning infrastructure, not a substitute for a full Bitcoin node, which is what provides independent chain verification.) It suits anyone who wants to run a Lightning node without operating the server themselves, while still holding their own keys.
Choosing an Operating System and Bitcoin Implementation
Bitcoin Core ships official binaries for Linux (x86_64, ARM 64-bit, ARM 32-bit, RISC-V, PPC64), macOS (x86_64 and Apple Silicon), and Windows (installer and portable zip). Linux is the most common host for a dedicated node because of low overhead, easy service management, and a long tradition of headless server operation. macOS works fine for a desktop node. Windows works but adds friction around services and the Windows Defender path.
Bitcoin Core is the recommended implementation for almost everyone. Bitcoin Knots is a derivative maintained by Luke Dashjr that ships additional policy options and earlier mempool features. Libbitcoin is an alternate codebase for operators who want a different architecture. Premade node distributions like Umbrel, Start9, MyNode, and RaspiBlitz bundle Bitcoin Core with a web interface and one-click installs of related software such as BTCPay Server, Electrum Server, and Core Lightning, the Lightning node implementation maintained by Blockstream. They suit operators who want a turnkey experience on a Raspberry Pi or Intel NUC.
Operators who want full control over configuration and updates should run Bitcoin Core directly. The rest of this guide assumes that path.
Setting Up Bitcoin Core Directly
More advanced users may want to rely on something other than third-party distributions for their node software. They can choose from several implementations of Bitcoin software, including Bitcoin Core, Libbitcoin, and Bitcoin Knots. We will use Bitcoin Core (Bitcoin's official open-source software client) as an example to outline the setup process:
- Go to bitcoincore.org and find the version that you want to install.
- Download the Bitcoin archive that fits the target computer architecture.
- Download the SHA256 hashes and hash signatures files and compare them with the downloaded archive. There are detailed step-by-step instructions on how to do this right where the download files are.
- Unpack the archive and install the software. The exact process depends on the computer architecture and OS, and the download site documents each one.
- Configure your Bitcoin node software to your liking. A configuration file generator hosted here makes it very easy to customize your configuration.
- Start (or restart) the Bitcoin daemon and wait until Initial Block Download finishes. This takes hours or days, depending on the computer and internet connection. The Bitcoin GUI shows progress toward completion.
Alternatively, a more advanced user can clone the software repository directly on github.com/bitcoin and compile the software.
Downloading and Verifying Bitcoin Core
Binaries live at bitcoincore.org/en/download/. The current stable release is Bitcoin Core 31.0 (released April 2026). Download three files: the binary archive for the target platform, SHA256SUMS, and SHA256SUMS.asc.
Verification is two steps. First, compare the SHA-256 hash of the downloaded binary against the entry in SHA256SUMS. The output should match the corresponding line in SHA256SUMS. On Windows, certUtil -hashfile <file> SHA256 produces the same hash.
Second, verify that SHA256SUMS was signed by trusted Bitcoin Core contributors. Import the developer signing keys from the bitcoin-core/guix.sigs repository on GitHub, then verify the signature file. A successful verification prints "Good signature" with the signer's fingerprint. GPG (GNU Privacy Guard) is the standard tool for signature verification; install it via the system package manager if it is not already present.
Verification matters because Bitcoin Core runs as a persistent network service and holds wallet keys for many operators; a tampered binary could exfiltrate keys or relay poisoned blocks. Cross-check sync progress against a public source such as Blockstream Explorer (blockstream.info) if a node's block height looks wrong.
Binary Install vs. Build From Source
Most operators install the pre-built binary. On Linux, extract the tarball and either run bitcoind and bitcoin-cli directly from the extracted directory or copy them into /usr/local/bin. On macOS, drag the .dmg contents into Applications. On Windows, run the installer or extract the portable zip.
Building from source is straightforward on a modern Linux distribution. Bitcoin Core uses CMake. After cloning the repository and installing dependencies (CMake, Python 3, libevent, Boost, and optionally SQLite for the wallet), the build follows the documented sequence. Build instructions for Ubuntu, Debian, Fedora, Alpine, and Arch are documented at github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md. Build flags allow disabling components: -DENABLE_WALLET=OFF for a P2P-only node, -DBUILD_GUI=ON to compile the Qt-based GUI, -DWITH_ZMQ=ON for ZeroMQ message queue support.
First Run and Initial Block Download
The first launch of bitcoind (or Bitcoin Core's GUI, bitcoin-qt) starts Initial Block Download. The node connects to peers, downloads block headers, then downloads and validates every block from genesis forward.
IBD time depends on storage and bandwidth. On an SSD with a 200 Mbps connection, IBD finishes in roughly 8 to 24 hours. On an HDD, the same machine takes days or weeks because the UTXO set updates thrash a spinning disk. AssumeUTXO (the loadtxoutset snapshot feature) lets a new node load a recent UTXO snapshot and begin operating immediately while background validation catches up in parallel. The snapshot is checked against a hash baked into the release, then validated against the chain history as IBD continues underneath.
During IBD the node uses substantial disk I/O and CPU. A node started inside a desktop environment runs slower than the same node running headless. Wired Ethernet during IBD shortens the process noticeably.
bitcoin.conf Basics
bitcoin.conf controls how the node behaves. Its location depends on the operating system:
- Linux: ~/.bitcoin/bitcoin.conf
- macOS: ~/Library/Application Support/Bitcoin/bitcoin.conf
- Windows: %APPDATA%\Bitcoin\bitcoin.conf
The file is plain text. Common flags include dbcache=N to size the database cache during IBD, prune=N to cap block storage (the minimum is prune=550 for 550 MB), txindex=1 to build a full transaction index, listen=1 to accept inbound connections, and server=1 to enable RPC.
Two flags are mutually exclusive in practice. prune=N and txindex=1 cannot both run, because a transaction index requires the full block history. Operators who need a transaction index must run a full node.
Block-filter indexing (blockfilterindex=1) and peer-block-filter serving (peerblockfilters=1) allow the node to answer compact-filter queries from light clients. They add disk usage but improve the privacy of any light wallet that connects to the node.
Port 8333 and Inbound Connections
A node that accepts inbound connections (listen=1) helps the network and is considered a "listening" or "reachable" node by tools like bitnodes.io. To accept inbound, the router or firewall must forward TCP port 8333 to the node's local IP.
Carrier-grade NAT (CGNAT), common on mobile broadband and some residential ISPs, blocks inbound connections entirely. CGNAT cannot be fixed with router configuration; the alternative is to run the node as a Tor hidden service, which sidesteps NAT and CGNAT.
UPnP (Universal Plug and Play) is disabled by default in Bitcoin Core and should stay that way. UPnP lets any process on the LAN punch holes in the router and is a known source of misconfiguration. Manual port forwarding on the router is the safer path.
Running a Node Over Tor
A Tor-only node hides the operator's IP address from peers and lets the node accept inbound connections without exposing a public port. Install Tor from the system package manager or from torproject.org, then set proxy=127.0.0.1:9050 and onlynet=onion in bitcoin.conf.
Bitcoin Core can create a Tor hidden service automatically using Tor's control port. Add torcontrol=127.0.0.1:9051 and configure Tor's torrc with ControlPort 9051 and CookieAuthentication 1. The node logs its .onion address on startup.
A Tor-only setup trades some performance for privacy. Block propagation over Tor is slower than over clearnet, and IBD takes longer. Many operators run dual-stack (clearnet for IBD, Tor for steady-state) by enabling proxy= without onlynet=onion. See the Blockstream guide on whether Tor or a VPN is the better fit for node operators.
Keeping the Node Running
A node that restarts unexpectedly resyncs the last few blocks, which is cheap, but a node that quietly stops running stops protecting the operator. Running Bitcoin Core as a system service keeps it up.
On Linux with systemd, the Bitcoin Core repository ships a sample unit file at contrib/init/bitcoind.service. Copy it to /etc/systemd/system/, enable it with systemctl enable bitcoind, and start it with systemctl start bitcoind. Logs go to journalctl -u bitcoind.
On macOS, a launchd plist accomplishes the same thing. On Windows, the official installer can register Bitcoin Core to start at boot.
Log rotation matters because debug.log grows over time. Bitcoin Core shrinks debug.log at each startup via -shrinkdebugfile (enabled by default) rather than rotating it continuously; operators do not need to wire up logrotate separately, but the file can grow large during a long uninterrupted uptime.
Wallets on Top of the Node
Bitcoin Core includes a built-in Bitcoin wallet. It supports legacy, SegWit, and Taproot addresses, descriptor-based key management, and PSBT (Partially Signed Bitcoin Transactions) for coordination with hardware wallets such as Blockstream Jade, which signs transactions while the node holds the chain data.
External wallets can also connect to the node. Wallet software such as Sparrow and Specter Desktop connects directly over RPC to a self-hosted Bitcoin Core node (Bitcoin Knots is not a wallet client but an alternative full-node implementation with its own GUI); the Blockstream app connects through an Electrum-protocol server (such as Electrs or Fulcrum) placed in front of the node. This configuration gives a self-custodial wallet the strongest privacy and verification guarantees: the wallet asks the node, directly or through its Electrum-protocol server, for balance and transaction history rather than querying a third-party server.
Recovery phrase backups are independent of the node. The recovery phrase backs up the keys; the node holds the chain data and can be restored from scratch by re-running IBD or by restoring a snapshot.
Verifying Sync and Health
The fastest way to check that a node is fully synced is the getblockchaininfo RPC call. The output includes blocks (current best block), headers (current best header), and verificationprogress (a fraction from 0 to 1). When blocks equals headers and verificationprogress is 1.0, the node is fully synced.
Other useful calls: getnetworkinfo reports peer counts and the externally visible address; getpeerinfo lists every connected peer; getmempoolinfo shows mempool size and fee floor.
A listed entry on bitnodes.io confirms the node is reachable from the public internet. The crawl takes 24–48 hours after the node first listens.
Updating Bitcoin Core
Each Bitcoin Core release ships with release notes at github.com/bitcoin/bitcoin/releases. Read them before upgrading; some releases include database migrations that require additional disk space or a one-time longer startup.
The update sequence:
- Download the new binary and SHA256SUMS.asc.
- Verify SHA-256 and GPG signatures (same process as the original install).
- Stop the running node (bitcoin-cli stop or systemctl stop bitcoind).
- Replace the binary.
- Restart the node.
The chain data, wallet, and configuration remain intact across upgrades. A clean upgrade from a recent prior version takes a few minutes once the binary is verified.
Where to Get Help
- The Bitcoin Core documentation at bitcoincore.org/en/doc/ covers installation, configuration, and RPC reference.
- bitcoin.stackexchange.com is the highest-signal Q\&A community for operational questions.
- The GitHub issue tracker at github.com/bitcoin/bitcoin/issues is the right place for genuine bugs and reproducible problems with the software itself.
- The Blockstream education series covers related topics including the difference between a full node and a pruned node, keeping a node secure and private, and Tor versus VPN for node operators.
Frequently Asked Questions
Does running a Bitcoin node earn rewards?
No. Node operators validate and relay; only miners receive block subsidy and fees. Running a node provides verification and privacy benefits, not direct revenue.
Can a Bitcoin node run on a Raspberry Pi?
Yes. A Raspberry Pi 4 with 8 GB of RAM or a Raspberry Pi 5 paired with an SSD over USB 3 runs Bitcoin Core comfortably. Premade distributions such as Umbrel, RaspiBlitz, and Start9 target this hardware.
How long does Initial Block Download take?
On an SSD with 100+ Mbps broadband, approximately 8 to 24 hours (varies by hardware and bandwidth). On a spinning HDD, several days to weeks because UTXO updates thrash random I/O. AssumeUTXO snapshots bring the operational sync down to minutes while background validation continues.
Is a pruned node still a full node?
A pruned node validates every block in full as it arrives (it is a full node in the consensus sense) and then discards block data older than the configured threshold. It cannot serve historical blocks to peers or rescan the chain for old transactions.
Do node operators need a static IP address?
No. Most listening nodes run behind a dynamic IP. Reachability depends on inbound port forwarding (8333) rather than on the IP being stable. A node behind CGNAT or a strict firewall is unreachable on clearnet but can still operate as a Tor hidden service.
How much bandwidth does a Bitcoin node use?
After IBD, a listening node uses approximately 100–200 GB per month, depending on peer count (varies by hardware and bandwidth). A non-listening node uses substantially less, often under 30 GB per month.
Next Steps
Download Bitcoin Core from bitcoincore.org/en/download/, verify the signatures, and start the install. For background on what a node actually does, see What Is a Bitcoin Node? and What Is Bitcoin Core?.