Reference · Terms

Glossary

Short definitions for language you will see on btcnode.run and in official Bitcoin documentation. These are educational summaries, not consensus specifications.

Full node: Software that downloads (or reconstructs) block data, validates it against Bitcoin’s consensus rules, and relays valid transactions and blocks to peers. A full node gives you your own view of the chain; it is not the same as mining or earning protocol rewards.
Bitcoin Core: The reference open-source implementation maintained by contributors. Most home operators run Bitcoin Core or a distribution derived from it. Release notes and security guidance live on the official project site—linked from resources.
Consensus rules: The network-wide rules every validating node applies to blocks and transactions (for example block size limits, subsidy schedule, and script rules). Nodes that disagree on consensus eventually follow the chain their rules accept—why staying current and informed matters.
Initial block download (IBD): The first-time (or after long offline) process of catching up with the historical chain. IBD can take days and significant disk and bandwidth depending on hardware, pruning, and network conditions.
Pruned node: A node configured to discard older block files after validation, keeping disk use lower within protocol limits. Useful on small disks; not identical to an archival full node. See pruning myths.
Peer: Another Bitcoin node your software connects to over the P2P network to exchange blocks, headers, and transactions. Peer visibility has privacy implications but is not a vanity metric—see privacy and maintenance.
Mempool: The set of valid unconfirmed transactions your node knows about and may relay. Wallet fee choices interact with mempool conditions; your node does not “set” market fees for the network.
RPC (remote procedure call): An operator interface many stacks expose for status queries and configuration—powerful and dangerous if exposed carelessly. Not for public internet exposure; see public RPC myths.
Tor: An overlay network that can route Bitcoin P2P traffic differently from clearnet in some setups. Adds complexity and latency; not a blanket privacy switch. This site does not provide Tor setup tutorials.
VPS (virtual private server): Rented virtual machine hosted by a provider. Can host a node but shifts trust and visibility to that provider compared with hardware at home—see setup paths.
Block: A package of transactions miners (or mining pools) proposed and the network accepted under consensus rules. Blocks link backward to form the blockchain.
Transaction: A signed message spending previous outputs and creating new ones according to script rules. Nodes validate transactions before relaying them.
UTXO (unspent transaction output): An output not yet spent by a later transaction. Wallets track UTXOs to construct spends; your node validates chain data—it does not replace wallet key management.
Wallet: Software (or hardware) that manages keys and constructs transactions. Connecting a wallet to your node can improve verification for that wallet when configured correctly; it does not merge wallet privacy with node privacy automatically.
Backup: In node operations, usually copies of configuration, documented restore steps, and optional application data—not a substitute for wallet key backups managed by wallet software. This site does not document seed phrases or wallet recovery procedures.
Chainstate: The database tracking which outputs are unspent after validated blocks. Grows with chain activity; lives alongside block storage on most Core layouts.

For deeper reading, see resources. For day-two habits, see maintenance.