# Running a full node > Source: https://timechain.wiki/wiki/running-a-full-node · TimechainWiki, the Bitcoin encyclopedia. (note · self-custody) > A Bitcoin full node is a copy of the Bitcoin blockchain plus the software that independently validates every transaction and block against the consensus rules. Running one is **the sovereignty layer beyond the keys**: a holder who self-custodies but consults a third-party block explorer is still trusting that third party for transaction history and balance verification, and a full node eliminates that dependency. Practical capabilities: independent transaction verification (the wallet consults the operator's own node, not a third-party server); privacy (third-party queries reveal holdings; an operator's own node does not); censorship resistance (no third party can refuse service); and broadcasting sovereignty (transactions go out through the operator's own node). The trade-offs are real but bounded — storage (~700 GB and growing as of 2026-05-14), initial block download time (1-3 days on typical hardware), and modest ongoing operational complexity. For Tier 1+ holders, the cost is small and the sovereignty benefit substantive. The practice is treated here as a first-class self-custody discipline — orthogonal to the configuration ladder but complementary to it. --- ## Why this note matters Running a full node is the most-underweighted self-custody practice. Many holders self-custody their keys but trust third-party block explorers for balance and history, defeating much of the self-custody benefit. The note matters because: - It establishes **the sovereignty layer beyond keys**. Self-custody of keys without verification of state is partial sovereignty. - It clarifies the **realistic operational cost** of running a node — which is bounded and modest compared to common perception. - It addresses the **privacy implications** of NOT running a node — every wallet query to a third-party server reveals information. The defensible position: every Tier 1+ holder should consider running a full node. The cost is bounded; the benefits are real. The configurations and product choices (Umbrel, Start9, Raspiblitz, custom builds) are discussed in [Node hardware options](https://timechain.wiki/wiki/node-hardware-options.md). --- ## What this is A Bitcoin full node consists of: - **A copy of the Bitcoin blockchain** — every block since the genesis block in January 2009. As of 2026-05-14, the chain is approximately 700 GB and growing at ~50 GB per year. - **The Bitcoin Core software** (or an alternative implementation like Knots, btcd, libbitcoin) — runs the consensus rules and validates the chain - **Network connectivity** — the node communicates with other nodes to receive new blocks and broadcast transactions A node may also include: - **An Electrum server** (Electrs, ElectrumX, or others) — provides an API your wallet can query - **A block explorer** (BTCPay's built-in explorer, mempool.space's self-hosted variant) — provides a web interface for inspecting the chain - **A Lightning node** — operates on top of the full node for Lightning Network participation - **Various supporting services** — Tor for privacy, RPC for programmatic access, monitoring tools For the self-custody use case, the minimum useful node is: Bitcoin Core + Electrum server. This is what a Sparrow Wallet, Specter Desktop, or BlueWallet can be configured to query. ### What a full node actually does When your wallet queries the node: 1. **Balance**: the node has the entire UTXO set and can compute the balance of any address without trusting external data 2. **Transaction history**: the node has every transaction ever made and can return the full history for any address 3. **Address derivation**: the wallet derives addresses from the extended public key; the node confirms which are used and which are not 4. **Fee estimation**: the node observes mempool activity and provides fee estimates 5. **Transaction broadcasting**: when you send a transaction, the node broadcasts it to the Bitcoin network When the wallet does NOT run against a node — when it uses a third-party API or block explorer: - The third party knows which addresses you've queried - The third party can return false information (in principle) - The third party can refuse to serve you - The third party can correlate queries with other data they have about you Self-custody plus third-party-server queries is partial sovereignty. Self-custody plus your own node is full sovereignty. --- ## When this matters Running a full node is appropriate for: - **Any Tier 1+ holder** — the privacy and verification benefits accrue at any scale - **Holders who value sovereignty explicitly** — the practice operationalizes the political-philosophical claim - **Holders who participate in Lightning** — Lightning requires a hot node; pairing with a full node is the standard - **Multisig users with regular spending** — the node serves as the coordinator's backend, eliminating one trust dependency - **The privacy-conscious** — third-party block explorer queries are a real information-leak channel Running a full node is **less critical** for: - **Tier 0 hot-wallet users** — the wallet often doesn't easily support custom-node backends; the friction is high - **Holders who use Bitcoin only as a savings vehicle and rarely query** — the per-query privacy concern is small if queries are rare - **Holders without stable network connectivity** — node operation requires reasonable bandwidth --- ## How a full node works in practice ### Initial setup 1. **Choose a setup** — [Umbrel](https://timechain.wiki/wiki/umbrel.md) ($50-300 plug-and-play), [Start9](https://timechain.wiki/wiki/start9.md) (similar), Raspiblitz (DIY Raspberry Pi), or custom (Bitcoin Core on a dedicated computer). See [Node hardware options](https://timechain.wiki/wiki/node-hardware-options.md). 2. **Install Bitcoin Core** (manually or via the chosen platform) 3. **Initial Block Download (IBD)** — the node downloads and verifies the entire blockchain. Takes 1-3 days on typical hardware; uses ~700 GB of disk. 4. **Optionally set up an Electrum server** — Electrs is the common choice; provides the wallet-API layer 5. **Configure your wallet** to query your node — Sparrow, Specter, Nunchuk all support this ### Daily operation Once initial download is complete: - The node runs continuously, receiving new blocks (~6 per hour on average) - New blocks add ~1.5-2 MB per 10 minutes to the chain - The node's network footprint is modest — a few GB per month upload/download - The node auto-updates the UTXO set; the wallet queries return current data The operational footprint is light. Most node operators don't think about the node day-to-day; it runs in the background. ### Periodic maintenance - **Software updates** — Bitcoin Core releases updates every few months; security and performance updates should be applied - **Disk monitoring** — the chain grows; storage needs eventually expand - **Network monitoring** — ensure connectivity remains stable - **For Lightning nodes** — additional maintenance (channel management, balance monitoring) ### Long-term considerations - **Storage growth** — ~50 GB/year currently; over 10 years, a node started today will need ~1.2 TB - **Bandwidth** — typically a few GB per month; not a binding constraint for most home connections - **Power** — a small dedicated computer uses 5-20 watts continuously; the cost is small ($5-20/year in electricity) --- ## Tradeoffs and considerations ### The privacy gain is substantial The most-underweighted benefit. When your wallet queries a third-party server (mempool.space, blockchain.info, mempool.space) for balance and transactions: - The server logs the addresses you queried - The server can correlate those queries with other information about you - The server can build a profile of your holdings over time - A breach of the server exposes this profile When the wallet queries your own node, none of this happens. The privacy benefit is structural — not "the server says it doesn't log," but "the server is yours." For holders concerned about identification-driven attacks (per [Common attack vectors](https://timechain.wiki/wiki/common-attack-vectors.md)), this matters. The KYC-data-leak pipeline that feeds physical-attack targeting is augmented by block-explorer-query patterns. ### Verification matters less than people think — except when it matters Most holders never face a situation where a third-party block explorer would lie about balances or transaction status. The risk is low-probability. But the risk is real: - A compromised third-party server could display false balances, leading to bad decisions - A government-pressured block explorer could refuse service or hide transactions - The third-party explorer could fail at the worst possible moment (during a critical recovery) For Tier 2+ holdings, the verification benefit becomes more relevant — the cost of any single decision is larger. ### The IBD is the operational barrier The 1-3 day initial download time is the primary friction. Most holders set it up over a weekend and forget about it. Some holders are deterred by the time investment. Mitigations: - Run the IBD on a faster machine (16+ GB RAM, NVMe SSD), then move the data to a slower target - Use AssumeUTXO snapshots (faster initial setup; some trust trade-offs) - Use pre-built node packages (Umbrel, Start9) that handle the IBD as part of setup For most holders, the one-time setup is worth the ongoing benefits. ### Lightning's structural dependence Lightning Network operation requires a full Bitcoin node. Holders who want to participate in Lightning (running their own Lightning node rather than relying on custodial services like Wallet of Satoshi or Phoenix) need a full Bitcoin node first. The combination — Bitcoin full node + Lightning node — is what most Lightning enthusiasts run. The synthesis of self-custody and Lightning sovereignty is structurally tight. ### Pruned vs full nodes A full node has the entire blockchain (~700 GB). A **pruned node** validates the same way but only keeps the most recent blocks (configurable; typically a few GB). The trade: - Pruned nodes save substantial disk space - Pruned nodes still validate every transaction; the security is the same - Pruned nodes cannot serve old blocks or be used as the backend for some wallet operations (specifically, importing a watch-only wallet with old transactions requires the historical blocks) - For self-custody wallet querying, pruned is generally fine For storage-constrained setups (older Raspberry Pi configurations), pruning is the standard. For new setups, full is the default unless storage is a binding constraint. ### Tor and privacy Running the node over Tor provides additional privacy: - The node's network connections are anonymized; no one can observe which IP is running the node - Tor incoming connections allow others to query you without revealing your IP - The wallet-to-node communication can be Tor-routed Most pre-built node packages (Umbrel, Start9) include Tor setup. For custom setups, Tor integration is well-documented. The benefit is meaningful for the privacy-conscious; for casual users, the marginal benefit is smaller. The cost is modest (some performance hit; occasional connectivity quirks). --- ## Comparison with alternatives | Approach | Verification | Privacy | Operational cost | Sovereignty | |---|---|---|---|---| | Wallet querying third-party block explorer | Trust the explorer | None (the explorer sees your queries) | Lowest | Partial | | Wallet querying public Electrum server (e.g., Blockstream's) | Trust the server's Bitcoin Core | None | Lowest | Partial | | Self-hosted node (Umbrel/Start9) | Independent validation | Full (your node) | Setup + maintenance | Full | | Self-hosted node + Tor | Independent validation | Strongest (network anonymization) | Slightly more | Full+ | | Custodial wallet (no self-custody) | Trust the custodian fully | None | None | None | The verification + privacy benefits of running a node are structurally distinct from the wallet-key benefits. A holder who self-custodies keys but uses a third-party explorer is in the "verification: trust the explorer; privacy: none" row above. --- ## Tiered application **Tier 0:** Optional. Phone wallets often don't easily support custom-node backends; the friction is high relative to the benefit. **Tier 1:** Strongly consider. The privacy benefit alone justifies the modest setup cost. Plug-and-play options (Umbrel, Start9) make this accessible. **Tier 2:** Standard practice. The verification benefit becomes more relevant at this scale; the operational discipline that running a node represents aligns with broader self-custody discipline. **Tier 3:** Likely multiple nodes (one at each major location; redundancy). Tor integration. Possibly a Lightning node as well. For all tiers running a node: the setup is one-time; the ongoing operational cost is modest; the sovereignty benefit accrues continuously. --- ## Common pitfalls **Skipping the node because "I trust the block explorer."** Trust the block explorer until you don't; the privacy leak is ongoing regardless of trust. **Running an outdated Bitcoin Core.** Software updates address real vulnerabilities. Keep the node current. **Failing to verify the node's downloads.** During initial setup, verify the Bitcoin Core binary against GPG signatures. A compromised binary undermines the node's purpose. **Co-locating the node with the hardware wallet.** The node should be operationally separate from the signing device. The signing device's air-gap is preserved by transferring PSBTs via QR or microSD, not by running both on the same computer. **Underestimating storage growth.** The chain grows ~50 GB/year currently. A node that fits comfortably today may need expanded storage in 5-10 years. **Trusting the node platform's defaults blindly.** Umbrel, Start9, and similar platforms have reasonable defaults but verify configuration against your specific needs (Tor on/off, pruning on/off, etc.). **Not setting up the Electrum server.** Bitcoin Core alone is not sufficient as a wallet backend; wallets need the Electrum API. Most node platforms install Electrs as part of the standard setup. **Forgetting to actually connect the wallet to the node.** Some holders run a node but never configure their wallet to use it. The node provides no benefit if the wallet still queries third-party servers. **Operating the node on the same machine as daily computing.** A dedicated machine (Raspberry Pi-class is fine) is structurally cleaner. The synthesis doesn't recommend running a node on the holder's primary laptop. --- ## Tooling and resources **Bitcoin Core**: - bitcoincore.org — the canonical implementation - The Bitcoin Core release notes — security advisories and update guidance **Node platforms** (see [Node hardware options](https://timechain.wiki/wiki/node-hardware-options.md)): - [Umbrel](https://timechain.wiki/wiki/umbrel.md) — consumer-friendly plug-and-play - [Start9](https://timechain.wiki/wiki/start9.md) — sovereignty-focused alternative - Raspiblitz — DIY Raspberry Pi-based - mynode — another DIY platform **Wallet coordinators that query custom nodes**: - Sparrow Wallet — strong native support - Specter Desktop — multisig-focused; uses Bitcoin Core directly - Nunchuk — desktop and mobile; supports custom nodes - Electrum (the wallet, not the protocol) — established support - BlueWallet — mobile; supports Electrum-server configuration **Resources**: - *Mastering Bitcoin*, Andreas Antonopoulos (3rd ed., 2023) — see [Mastering Bitcoin - Andreas Antonopoulos](https://timechain.wiki/wiki/mastering-bitcoin-andreas-antonopoulos.md). Detailed treatment of node operation. - Bitcoin Core documentation — comprehensive - Various Bitcoin community guides — Bitcoin Magazine, ronaldstoepel.com, etc. **The synthesis document**: *Bitcoin Self-Custody & Security* (LegacyCipher, April 2026) — treats node operation as part of the broader sovereignty practice. _As of 2026-05-14_: Bitcoin Core is well-maintained; the node-platform landscape is stable. Storage requirements continue to grow but at predictable rates. --- ## Open questions for further development - AssumeUTXO and faster sync mechanisms are emerging. Do they meaningfully change the IBD cost-benefit, or do they introduce new trust dependencies that partially undermine the node's purpose? - The Lightning operation alongside Bitcoin nodes is increasingly common. How does the framework recommend integrating Lightning sovereignty with the broader self-custody practice? - Mobile-first wallet patterns are increasingly common. The "wallet on phone + custom node at home" pattern requires reliable connectivity. Should the framework recommend specific patterns for this? - Pruned-node-only setups are common in storage-constrained configurations. Are there scenarios where pruning becomes structurally problematic for self-custody operations? --- ## Related notes **The framing context**: - [Self-custody as a moral act](https://timechain.wiki/wiki/self-custody-as-a-moral-act.md) — the moral framework node operation instantiates - [Sovereignty and personal responsibility](https://timechain.wiki/wiki/sovereignty-and-personal-responsibility.md) — the political-philosophical foundation - [Self-custody configuration ladder](https://timechain.wiki/wiki/self-custody-configuration-ladder.md) — node operation is orthogonal to the ladder; can apply at any rung **Adjacent operational notes**: - [Common attack vectors](https://timechain.wiki/wiki/common-attack-vectors.md) — third-party explorer queries as an attack surface - [Operational security practices](https://timechain.wiki/wiki/operational-security-practices.md) — node operation is part of the opsec discipline **Node-specific notes**: - [Node hardware options](https://timechain.wiki/wiki/node-hardware-options.md) — the platform choices - [Connecting wallets to your own node](https://timechain.wiki/wiki/connecting-wallets-to-your-own-node.md) — the wallet-side configuration - [Umbrel](https://timechain.wiki/wiki/umbrel.md) — consumer-friendly platform - [Start9](https://timechain.wiki/wiki/start9.md) — sovereignty-focused platform **Hardware wallets**: - [Hardware wallets overview](https://timechain.wiki/wiki/hardware-wallets-overview.md) — the signing layer that pairs with the verification layer - All per-device notes — every hardware wallet works with custom node setups **Custody configurations**: - [Multisig setups](https://timechain.wiki/wiki/multisig-setups.md) — the coordinator (Sparrow, Specter, Nunchuk) can use a custom node as its backend - [Collaborative custody services](https://timechain.wiki/wiki/collaborative-custody-services.md) — partners typically don't require custom nodes but support them **Storage and key concepts**: - [PSBT and wallet descriptors](https://timechain.wiki/wiki/psbt-and-wallet-descriptors.md) — the wallet-to-node interaction uses PSBT - [Seed phrases and BIP-39](https://timechain.wiki/wiki/seed-phrases-and-bip-39.md) **The technical foundations**: - [Bitcoin Core](https://timechain.wiki/wiki/bitcoin-core.md) - [Full nodes vs pruned vs SPV](https://timechain.wiki/wiki/full-nodes-vs-pruned-vs-spv.md) **The principal practitioners**: - [Andreas Antonopoulos](https://timechain.wiki/wiki/andreas-antonopoulos.md) — *Mastering Bitcoin* covers node operation comprehensively - [Pieter Wuille](https://timechain.wiki/wiki/pieter-wuille.md) — Bitcoin Core developer - [Jameson Lopp](https://timechain.wiki/wiki/jameson-lopp.md) — operational guidance **The sub-MOC home**: - [Practical self-custody and sovereignty](https://timechain.wiki/wiki/practical-self-custody-and-sovereignty.md)