Glossary

AssumeUTXO

A Bitcoin Core feature that starts a node from a UTXO snapshot (loadtxoutset) and verifies the full history in the background. The snapshot is checked against a hash built into Core, but there is no official download source and the node is not fully verified until the background check finishes. Optional and advanced; see sync stuck.

Air-gapped

A device that never connects to a computer or network directly. It exchanges transactions through QR codes or an SD card. Some hardware wallets work this way.

Bandwidth cap

A monthly data limit on a hosting plan. The first sync downloads hundreds of gigabytes, which can hit it. See VPS.

Block

A batch of transactions added to the chain roughly every ten minutes. Your node downloads and checks every one; a pruned node deletes old block files afterwards.

Block explorer

A website that shows chain data. Convenient, but you are trusting its server unless you check against your own node.

Chain tip

The newest block your node accepts as valid. When your blocks count equals the network's, you are at the tip.

Consensus rules

The rules every node enforces: valid signatures, no double spends, the supply schedule, block structure. Checking them yourself is the reason to run a node.

Cookie authentication

Bitcoin Core writes a file with a random secret (.cookie) into its datadir on each start. Programs on the same machine that can read the file, such as bitcoin-cli and Sparrow, use it to log in to RPC. No password to choose or leak. See connect your wallet.

datadir

The folder where Core keeps blocks, the UTXO database, config and logs (~/.bitcoin by default on Linux; /var/lib/bitcoind with the setup on this site). Stop Core before moving it; see disk recovery.

dbcache

How much RAM Core uses to cache the UTXO set. More speeds up the first sync. Leave room for the OS. See the conf reference.

Electrum server

A program such as electrs or Fulcrum that reads from your node and indexes addresses, so wallets can look up their history from your machine instead of a public server. It needs an unpruned node. See Electrum server vs full node.

Full node

A node that keeps every block back to 2009 (roughly 800 GB in 2026) and checks all the rules. Compare with pruned.

Hardware wallet

A small device that holds your private keys and signs transactions, so the keys never touch your computer. Sparrow can use many of them; see connect your wallet.

Headers-first sync

Core downloads block headers first, which are cheap to check, then the full blocks. Headers well ahead of blocks during sync is normal.

IBD

Initial block download: the first sync from nothing to the chain tip. Disk speed and bandwidth dominate. See sync stuck.

Mempool

Your node's list of valid transactions that are not yet in a block. Mostly empty or incomplete during the first sync.

Onion service

A Tor address (ending in .onion) that lets others connect to your node without learning its IP address. See Tor and privacy.

Peer

Another Bitcoin node your node is connected to. No peers means no sync. Check with getconnectioncount.

Port 8333

The default Bitcoin peer-to-peer port. Forwarding it lets others connect to you and reveals that you run a node. Not the same as RPC on 8332.

Prune mode

Core verifies every block, then deletes old block files, keeping the UTXO set and recent blocks. Saves disk, does not shorten the first download. See pruned vs full.

RPC

Remote procedure call: Core's local control interface on port 8332, used by bitcoin-cli and wallets such as Sparrow. Keep it on localhost or a trusted LAN, never the internet. See security basics.

rpcauth

A bitcoin.conf setting that stores a hashed RPC login, so no plain password sits in the file. Used when a wallet on another machine needs RPC.

SPV wallet

A wallet that does not verify the whole chain and asks a server for your history. Sparrow and Electrum can work this way with a public server, or against your own node.

Tor

A network that hides your IP address from the services you connect to. Optional for a node and slows it down. See Tor and privacy.

txindex

An optional Core index that looks up any transaction by its id. Adds tens of gigabytes, cannot be combined with pruning, and Fulcrum requires it.

UTXO

Unspent transaction output: a coin that can still be spent. Your node keeps the full set (about 11 GB in 2026) to check new transactions, and building it is most of the work in the first sync.

verificationprogress

A field in getblockchaininfo estimating how far along the first sync is, by transaction count. Near 1.0 means caught up. It moves slowly on recent blocks, so also watch blocks.

Watch-only wallet

A wallet that can see addresses and balances but holds no private keys, so it cannot spend. Sparrow tracks your addresses on your node this way.

xpub

An extended public key: one string from which a wallet derives all its receiving addresses, with no ability to spend. Sharing it with a server reveals every address in that wallet, which is why a public wallet server learns so much about you.

Next: Do you need a node? · Setup · Commands · Maintenance