Running a full node

A bitcoin full node is a program that stores the whole chain, checks every block and transaction against the rules, and passes valid data on to its peers. Bitcoin Core is the reference implementation and the easiest way to run one. You need a computer with enough disk space, a steady connection, and time for the first sync, which can take days.

Explore21 reads everything from its own node, so the pages on this site match what the network sends. This page covers the node types, what you need, how to start a node, and what it checks. For what a node does in plain words, see the beginners' node guide. For the one-line definition, see node.

What are the node types?

The words overlap, so here are the three that matter.

A full node keeps every block and checks every rule. It can give the whole history to a new peer.

A pruned node also checks every rule. It deletes old block files once it no longer needs them, but it keeps the UTXO set, which it needs to check new transactions. It cannot serve old blocks to other nodes.

An SPV client, also called a lightweight client, keeps only block headers. It asks peers for proofs that a transaction is in a block. It trusts that the blocks behind those headers are valid, so it cannot check the rules itself.

Only full and pruned nodes enforce the rules. A miner does not have to run its own node, because it can get the data it needs from a full node.

What do you need to run one?

These figures come from bitcoin.org's full node guide. They change as the chain grows, so check that page for current values.

• Disk, full node: over 750 GB, and it keeps growing.
• Disk, pruned node: around 7 GB.
• RAM: 2 GB at least.
• Download: about 20 GB a month. The first start downloads the whole chain, which bitcoin.org puts at about 740 GB.
• Upload: often 200 GB a month or more on a fast connection.

A pruned node is the way to save disk space. Its setting is in the next section.

How do you run a full node?

1. Download Bitcoin Core. Get it from bitcoincore.org. Check the file against the signed checksums that the download page publishes.
2. Start the node. Open the Bitcoin Core app, or run bitcoind in a terminal if you want no window. On the first start, the node finds peers and begins the initial block download.
3. Let it sync. The node downloads and checks every block from the genesis block forward. This is the slowest part. To see how far it has got, run:

bitcoin-cli getblockchaininfo

The blocks field is the height your node has processed. The verificationprogress field runs from 0 to 1. The initialblockdownload field is true while the node is still syncing.

4. Optional: prune the chain. To save disk space, add a prune line to bitcoin.conf in your data directory. The value is the number of MiB to keep for block data, and 550 is the smallest value above 0.

# bitcoin.conf
prune=550

A pruned node cannot use -txindex or -rescan.

5. Optional: accept incoming connections. Bitcoin Core listens on TCP port 8333. If you forward that port on your router, other nodes can connect to you. You do not need this to use your node.
6. Keep it running when you can. A node does not have to run all the time. It catches up with the chain when it starts again. To see who it is talking to, run bitcoin-cli getpeerinfo.

What does a node check?

A full or pruned node checks every block before it accepts the block:

• The block header hash meets the target, which is the proof of work.
• The header points at a block the node knows about, and its timestamp follows the rules.
• The merkle root in the header matches the transactions in the block.
• The block stays within the limits: 4,000,000 weight units, and a capped number of signature operations.
• The coinbase transaction does not claim more than the subsidy plus the fees.

It also checks every transaction in the block:

• Each input spends an output that exists and has not been spent.
• Each input's unlocking data satisfies the locking script, including the signatures.
• The outputs do not add up to more than the inputs.
• The rules that apply at that height hold. Since block 481,824 that includes SegWit, and since block 709,632 it includes Taproot.

Nodes also apply policy rules before they relay a transaction. The main one is a minimum fee rate. A transaction can break a policy rule and still be valid. A miner who accepts it can include it in a block, so a node may refuse to relay something that is valid. Policy is a choice each node makes, and consensus is what every node must agree on.

How does a new node find peers?

A node needs at least one reliable peer, because that peer can tell it about others. Bitcoin Core tries three sources, in this order:

1. Previous connections. It keeps a list of peers it has used before, and it tries them first.
2. DNS seeds. On a first start there is no list. The node then asks DNS seed servers run by Bitcoin developers for addresses of reliable nodes. The Bitcoin Core source lists current seeds, such as seed.bitcoin.sprovoost.nl and dnsseed.bluematt.me.
3. Hardcoded seeds. If both fail, it falls back to a fixed list in chainparamsseeds.h.

Which software can run a node?

Bitcoin Core is the reference implementation, and most people who run a node use it. Other full node implementations exist, including btcd, bcoin and BitcoinJ, but they are used far less. The bitcoin-cli commands in this course assume Bitcoin Core. The network is open, so you can also write your own node software, as long as it follows the same rules.

Should you run your own node?

Running your own node means you check every rule yourself. You do not have to ask a third party what a transaction did, and you can broadcast your own transactions through your node. The costs are disk space, bandwidth and the first sync.

For the network identifiers your node uses, read the magic bytes page. For the messages it sends, read the networking page.