How to run your own Bitcoin node

What you will end up with

A machine running Bitcoin Core that downloaded the chain itself, checked every block against the rules, and can answer "did that payment arrive" from its own copy rather than by asking a company, with a wallet pointed at it.

This guide assumes you know what a node is and what it is for. If you do not, read that first: this post is the doing.

Checked in August 2026 against Bitcoin Core 31.1, released 8 July 2026, and against Core's own documentation. Versions and chain size both move, so check every figure below against the download page rather than trusting a blog post, including this one.

Before you start

Disk. Core's download page asks for "a one-time download of about 600GB of data plus a further 5-10GB per month", and says pruning brings that to as little as 10 GB. That 600 GB is where it stood in August 2026, and it only grows.

RAM. Core publishes no minimum, so here is the number that behaves like one: dbcache defaults to 1024 MiB, or to 450 MiB when the machine has less than 4096 MiB of RAM, per Core's reduce-memory notes. A 4 GB machine is comfortable. A 2 GB machine works and runs slower, because Core shrinks its validation cache to fit.

Bandwidth. The 600 GB is the download, once. The 5 to 10 GB a month is mostly upload, because a node accepting inbound connections serves blocks to other people.

Time. Nobody publishes an honest figure for the initial download and neither will this post: hours to days, decided more often by disk speed than by the network.

GPG, for step three: brew install gnupg on macOS, apt install gnupg on Debian.

The tradeoff you are accepting

This is the rare Bitcoin procedure where the downside is not lost coins. A node holds no money by default, so getting it wrong costs you a weekend.

What you take on instead is an operational commitment. A node is a service you now run: it has to stay online to be worth anything, it needs updating when Core ships a security fix, and once your wallet points at it, your wallet stops working whenever the node does. People abandon nodes over that last one more than any other.

Steps

Get the software, and prove it is the software

This is the step almost every guide compresses into "download Bitcoin Core", and the one that matters most. Core is built reproducibly: independent people compile the same source, get byte-identical binaries, and sign the resulting list of hashes. Skipping the check throws that away and leaves you trusting a web connection.

Download the binary for your system from bitcoincore.org/en/download, plus SHA256SUMS and SHA256SUMS.asc from the same page.
Check the binary against the list: sha256sum --ignore-missing --check SHA256SUMS on Linux or macOS, certUtil -hashfile <filename> SHA256 on Windows. Success is the filename followed by OK.
Import several builder keys from the builder-keys directory of bitcoin-core/guix.sigs, one gpg --import <name>.gpg each.
Check the signatures on the list itself: gpg --verify SHA256SUMS.asc. You want several lines reading gpg: Good signature, from keys you chose to import.

Step 2 alone proves nothing worth having: that the file matches a list which arrived from the same place the file did. Step 4 is what makes the list mean anything.

Core also ships a script that does all four, ./contrib/verify-binaries/verify.py pub 31.1, documented in contrib/verify-binaries.

Configure it before the first start

Install or unpack the binary.
Create bitcoin.conf in the data directory before starting, because some of these are painful to change afterwards. It goes at ~/.bitcoin/bitcoin.conf on Linux, ~/Library/Application Support/Bitcoin/bitcoin.conf on macOS, and %APPDATA%\Bitcoin\bitcoin.conf on Windows (doc/bitcoin-conf.md):

# Answer JSON-RPC, so wallet software on this machine can reach the node.
server=1

# Validation cache in MiB. Raise for the initial download, lower afterwards.
dbcache=4096

# Accept inbound connections. This is what makes you useful to other people.
listen=1

# Outbound traffic target, MiB per 24 hours. 0 means no limit.
maxuploadtarget=5000

# Compact block filters, so a wallet can scan for its own history quickly.
blockfilterindex=1

dbcache there is temporary generosity, worth lowering once the download is done, and maxuploadtarget exempts blocks mined in the past week, per Core's help text, so it caps serving history rather than all traffic.

Start it: bitcoind -daemon, or open Bitcoin-Qt for the graphical version. Only one of the two can run at a time.
Leave it alone. This is the initial block download, and interrupting it is safe but wasteful.

Verify it worked

Run bitcoin-cli getblockchaininfo. Four of its fields answer the question, and the RPC reference defines all of them:

initialblockdownload is the direct answer. While it reads true the node is still catching up, and should not be trusted to tell you a payment arrived.
verificationprogress is an estimate between 0 and 1, and it is not linear: the last one percent takes far longer than the first, because recent blocks are full.
blocks and headers should be equal. Headers running ahead is normal mid-sync: Core fetches the header chain first and fills blocks in behind it.
size_on_disk is what it is costing you, and chain should read main.

Synced and validating are the same thing here, with one caveat. Core's assumevalid option ships with a block hash baked in and, for that block and its ancestors, will "assume that it and its ancestors are valid and potentially skip their script verification". Everything else is still checked from scratch: the issuance schedule, the proof of work, whether an input exists and has not already been spent. Set assumevalid=0 for no shortcut at all, and expect a much longer download.

Pruning, and exactly what it costs you

Set prune=550 or higher, a target in MiB, and Core deletes old block data once it is finished with it, keeping the unspent output set and a recent window. A pruned node validated every block it ever saw, so it is a full node in the sense that matters.

Four things you give up, and the third catches people:

You stop serving history. Nobody can sync from you. A loss to the network rather than to you, but a real one.
txindex is unavailable. No looking up arbitrary transactions by ID.
Wallet rescans cannot reach past pruneheight. Import a wallet whose transactions predate your pruned window and the node cannot find them. A correct wallet birthday plus blockfilterindex=1 covers most cases; genuinely old history wants an unpruned node.
Reverting requires re-downloading the entire chain, per Core's help text. Pruning is close to a one-way decision.

Connecting a wallet

A node nothing is pointed at is a hobby. In Sparrow, set the server type to Bitcoin Core and the URL to 127.0.0.1 on the default port, and leave authentication on the cookie file, which Core writes into the data directory and Sparrow finds by itself. Sparrow's connection notes add two requirements on the Core side: server=1 set, and disablewallet=1 not set.

Then confirm the wallet is really using it rather than quietly falling back to a public server. Stop bitcoind and watch the wallet lose its connection. If it carries on cheerfully, it was never talking to you.

If something goes wrong

gpg: Can't check signature: No public key. You verified nothing. Import the builder keys and run it again.

gpg: WARNING: This key is not certified with a trusted signature. Expected, not a failure: it means you have not personally signed the builder's key, which almost nobody has. Good signature on the line above is the part that matters.

BAD signature. Stop. Do not run the binary, and do not treat it as a download glitch.

Sync crawls with the disk light solid. Almost always disk rather than network, and almost always a spinning drive or an SD card. Raise dbcache if the RAM is there, and move the data directory to an SSD.

The disk fills up mid-download. Add prune=550 and restart. Core prunes what it has.

Cannot obtain a lock on data directory. Another Core instance is running, usually Bitcoin-Qt behind a window.

What running a node does not do

It does not earn anything. No reward, no yield, nothing to stake. Anyone selling node hardware on a return-on-investment argument is selling something else.

It is not mining. Miners propose blocks by doing proof of work and are paid for it. Your node checks what they propose and is paid nothing.

It does not make your transactions private. It fixes one leak: a light wallet tells some company which addresses you are asking about, and your own node tells nobody. It does nothing about the rest. The chain is still public, your unspent outputs still link to each other, and anything you broadcast is visible to every node that relays it. Privacy is a separate discipline; a node is one component of it.

It does not give you a vote. A node enforces rules for itself. It outvotes nobody, and if your rules differ from everyone else's, you are alone on a different chain.

What it gives you is narrower and better. When your wallet says a payment confirmed, that is now a statement your own machine checked, against rules you chose to run.