TERM_DEF // NETWORKING / FULL_NODE
FULL
NODE
NODE
node/">Full Node. A node that downloads and verifies every block and transaction against consensus rules.
This page sits in the Networking section — How nodes find peers, exchange transactions and blocks, and stay in sync. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
This page sits in the Networking section — How nodes find peers, exchange transactions and blocks, and stay in sync. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
WHAT_FULL_NODE_IS
Full Node — at a glance
NETWORKING
Full Node is part of Bitcoin's peer-to-peer-p2p/">peer-to-peer network — a global mesh of independent nodes that gossip transactions and blocks. A node that downloads and verifies every block and transaction against consensus rules. There is no master server. Every node finds peers, exchanges data, and enforces the consensus rules on its own behalf.
Why it exists
DESIGN
If Bitcoin had a central server, that server would be the system. It could be shut down, subpoenaed, censored, or compromised. The peer-to-peer architecture removes that single point of failure: any individual node can vanish and nothing happens; the rest of the network keeps going. This is the same insight as BitTorrent — but applied to money, with strict consensus rules layered on top.
HOW_IT_WORKS
Mechanism
HOW IT WORKS
A new node bootstraps by querying hard-coded DNS seeds for a list of recent peers, then connecting to ~8–10 of them over TCP port 8333. Each connection exchanges a "version" handshake, then transactions and blocks flow as INV announcements followed by GETDATA requests. A node only fetches data it doesn't already have. Validation is local: each node re-checks every signature, every PoW, every consensus rule itself.
1. Bootstrap: node asks DNS seeds → receives a list of recent peer IPs.
2. Handshake: TCP connect to ~8 outbound peers + accept up to ~117 inbound; exchange "version" and "verack" messages.
3. Sync: download headers first (fast, ~80 bytes each), then blocks in parallel, validating as they arrive.
4. Steady state: relay new transactions / blocks via INV announcements; fetch via GETDATA only when needed.
5. Mempool: keep unconfirmed transactions waiting for inclusion; evict lowest-fee ones when full.
6. Validation: every full node enforces every consensus rule itself — no trust required.
WORKED_EXAMPLE
A typical full node session (Bitcoin Core)
EXAMPLE
bootstrap : seed.bitcoin.sipa.be, dnsseed.bluematt.me, …
connect : ~8 outbound peers (default), TCP port 8333
sync time : ~12-48 hours for initial block download (~700 GB)
storage : ~700 GB chain + ~7 GB chainstate (pruned: ~6 GB total)
bandwidth : ~250 GB/month relaying blocks and txs at typical settings
cpu / ram : modest — a Raspberry Pi 4 with an SSD is enough
After IBD, your node:
• verifies every new block in <1 second
• enforces every consensus rule itself
• does not trust ANY external party for validation
• is the strongest privacy + verification setup possible
KEY_PROPERTIES
Anyone can run a node. No whitelist, no signup, no gatekeeper. Default port: 8333.
REDUNDANT
Tens of thousands of full nodes worldwide hold the entire chain. Taking any one offline changes nothing.
GOSSIP-BASED
Transactions and blocks propagate by INV → GETDATA → DATA, in seconds globally.
TRUSTLESS
Every full node validates every rule itself. No third party can lie to it about the chain state.
COMMON_PITFALLS
Things that catch people out
PITFALLS
- "Light wallets" (SPV, Electrum, mobile) trust whatever upstream server they connect to for fee data, transaction history, and balance. A full node is the only way to verify.
- Running a node behind Tor is private but slower; behind a clearnet IP it can be enumerated and probed.
- Pruned nodes save disk but lose the ability to serve historical blocks. Choose based on whether you want to help bootstrap others.
- Initial Block Download (IBD) is bandwidth-intensive — the first ~700 GB will saturate a residential connection for hours.
RELATED_CONCEPTS
Other terms from Networking — click any to read its page:
TERMINOLOGY_INDEX
TERMINOLOGY
Full Node
A node that downloads and verifies every block and transaction against consensus rules.
Light Node (SPV Node)
A node that downloads only headers and uses Merkle proofs to verify specific transactions.
SPV (Simplified Payment Verification)
Verifying inclusion of a tx by checking its Merkle proof against a downloaded header chain.
Bloom Filter
A probabilistic filter an SPV node sends so full nodes only forward potentially-relevant transactions.
Peer
Another node your node has an open connection to.
Peer Discovery
Finding new peers via DNS seeds, hard-coded seeds, or peer-exchange messages.
DNS Seed
A DNS hostname returning A-records of well-known node IPs; bootstrap mechanism.
Magic Bytes
The 4-byte network identifier prefixing each P2P message frame.