Running a Bitcoin Node — Verifying for Yourself

What It Means to Run a Node

• "Running a node" means operating software that participates in the Bitcoin network (most commonly Bitcoin Core) on your own machine, and continuously verifying the entire history of the blockchain yourself. The balance shown by an exchange and the screen of a block explorer are both the result of someone telling you that this is how things are. A node is the apparatus that recomputes that answer on your own hardware.
• In ordinary times this difference is invisible. The balance is the same number, and payments arrive the same way. The difference surfaces when the party telling you is wrong, goes down, deliberately displays something other than the facts, or when the rules of the network themselves come into dispute. At that moment, someone with a node does not have to take the majority's claim at face value — they can check against their own copy.
• "Don't trust, verify" is a slogan repeated throughout the Bitcoin world, and a node is where that phrase takes the concrete form of a machine. The mechanism described in the whitepaper ultimately assumes that each participant applies the rules for themselves.
• At the same time, inflated expectations are a mistake. Running a node earns no reward at all, and it has no direct relationship to price. The concept of the blockchain itself is covered in the separate topic "How Blockchain Works"; this topic focuses narrowly on the operational side — what actually happens when you run one.

What a Full Node Does — Validation and Rule Enforcement

• A full node's job is to check, one by one, whether every block and transaction it receives conforms to Bitcoin's consensus rules. Are the signatures valid? Does the balance (UTXO) being spent actually exist and remain unspent? Is this a double spend? Does the block's proof of work meet the difficulty target? Do the coinbase outputs exceed the block subsidy (3.125 BTC as of August 2026) plus the transaction fees contained in that block? Is the block within the weight limit? Anything that breaks the rules is rejected — even if a majority of miners support it.
• What matters is that this is rejection, not surveillance. A node does not vote. It quietly discards invalid blocks and keeps only the valid chain as its own ledger. For a node, "real Bitcoin" means the chain that conforms to the rules of the software it is running.
• The 21 million supply cap holds not because someone supervises it, but because nodes all over the world uniformly refuse to accept a block containing issuance outside the rules. What enforces the rules is not an abstract "network" but the aggregate of software each person is running.
• Beyond validation, a node also relays transactions and maintains a mempool. It passes valid transactions it receives on to other nodes, and temporarily holds transactions not yet included in a block. This relay policy (such as the minimum fee it will accept) sits in a layer separate from the consensus rules, and can be configured differently on each node.
• The division of labor with mining is clear too. Miners create new blocks; nodes verify the blocks that get created. You can run a node with no mining hardware whatsoever, and in fact the vast majority of nodes do no mining. Where the "Role of Nodes" section in the blockchain topic explains the concept, this topic covers the operational reality.

Types of Node — Full, Pruned, Archival, and SPV

• Nodes come in several configurations that differ in how much data they store and what role they play. The first thing to grasp is that full, pruned, and archival are identical in that all three verify every block for themselves; what differs is whether they keep the data after verifying it.

• A pruned node is not a shortcut on validation. It downloads and fully verifies every block, then discards the old block bodies and keeps only the UTXO set (the collection of unspent balances). Its rule-enforcing power is therefore identical to a default full node; what it loses is the ability to serve historical blocks to other nodes and the ability to rescan the pruned range with a wallet later. In Bitcoin Core's settings, the minimum pruning value is 550 (MiB).
• An archival configuration (a node with txindex enabled) additionally maintains an index that can look up any transaction by its ID. That is necessary for running your own block explorer or doing statistical analysis, but unnecessary if you simply want to verify your own balance.
• SPV and light clients fetch only block headers and use the Merkle tree to confirm that a given transaction is included. Because a block header is a fixed 80 bytes, collecting every one of the roughly 960,000 blocks that exist as of August 2026 still comes to only about 80MB. Fetching the compact block filters of BIP-158 for past blocks adds to that, however, so the total grows with the range you retrieve.
• This is the usage the whitepaper anticipated from the start, and most mobile wallets fall into this category. Because they do not verify the consensus rules themselves, however, they partly trust others' assertion that a block is valid. The compact block filters of BIP-157/158 are an improvement aimed at reducing the query leakage this approach used to entail.

What You Need — Storage, Bandwidth, and Uptime

• Start with storage. As of August 2026 the block data alone comes to roughly 760GB (a figure that excludes database indexes). Because a block is produced roughly every ten minutes and each block has a weight limit, the total will keep growing by tens of gigabytes per year. A configuration that keeps everything needs headroom for the UTXO database and free space for the operating system, so a 1TB drive filled to the brim will feel cramped before long. A pruned configuration brings this down to about 7GB according to the official documentation's guidance.
• Next, bandwidth. The requirements published on bitcoin.org call for an upload speed of at least 400 kilobits (50 kilobytes) per second, and it is common for full nodes on high-speed connections to use 200 gigabytes of upload or more per month. Download runs around 20 gigabytes a month, plus a full download of the entire history the first time you start the node (bitcoin.org states this as roughly 740 gigabytes; the gap from the ~760GB figure above is mainly a difference in when each was measured). On metered or mobile connections, the initial sync alone can reach a contractual cap, so checking beforehand is essential.
• The stated minimums for memory and uptime are 2GB of RAM and six hours a day of running time. Running continuously nonetheless keeps both chain-tip tracking and connection quality more stable. Disk read/write speed of at least 100MB/s is listed as a requirement, which in practice means an SSD.
• As for hardware categories, options include an always-on desktop, an off-the-shelf mini PC, a NAS, a single-board machine such as a Raspberry Pi, prebuilt node kits combining these, and rented VPS instances. This site does not recommend any particular product or provider. The factors worth weighing are disk speed and lifespan, heat and noise under 24-hour operation, the reliability of external drives, and whether you can recover the setup yourself when something fails.
• Placing the node on a VPS (a virtual server in the cloud) is also an option, but note that its character changes. You escape the constraints of a home connection, yet the machine is held by a provider — a step back from the original point of verifying on hardware under your own control. Cloud data-transfer charges are not negligible either, given the scale of the initial sync.

How Bitcoin Core Setup Goes, and What Happens During Sync

• The broad sequence is: (1) obtain Bitcoin Core from the official site, (2) verify the signatures and hashes of the distributed files, (3) decide your settings (whether to prune, whether to enable txindex, how much cache to allow), (4) start it and wait through the initial block download (IBD), and (5) point your wallet at your own node once sync completes. Step-by-step instructions change with version and operating system, so consult the official documentation.
• As of August 2026 the latest release is Bitcoin Core 31.1, published on July 8, 2026. Step (2) is the first gate. Skipping it means trusting the distribution path unconditionally at the very entrance to "verifying for yourself" — an unglamorous step that is nonetheless essential.
• During the initial sync, the node first collects block headers to determine which chain has the most work, then downloads the block bodies in order, applies them, and rebuilds the UTXO set from scratch. Depending on hardware and connection, this takes anywhere from several hours to several days. What is happening in that window is not "downloading" but recomputing seventeen years of transactions on your own machine.
• The default settings include a speed-up called assumevalid. For the stretch of chain up to a specific block hash compiled into the software, it skips script (signature) validation; checks on block structure, proof of work, and double spending are not skipped. If you want to confirm everything from zero, you can disable this feature and validate signatures across the entire history (at a substantial cost in time).
• A newer option is assumeutxo. It loads a snapshot of the UTXO set so the node can begin verifying recent blocks immediately, while validating the full history in the background. The snapshot's contents are checked against a hash value compiled into the software, and once background validation finishes the node arrives at the same state as any other. The design says: you can start using it sooner, but you have not abandoned verification.
• Once sync completes, the daily load drops sharply — the node simply verifies one new block roughly every ten minutes and relays transactions. The demanding phase of running a node is the initial sync.

Why Connect to Your Own Node — Not Leaking Your Queries

• Of the practical benefits of having your own node, privacy is the most concrete. To learn your balance and history, a light wallet asks a third-party server (an Electrum-style server or an explorer API) to tell it the status of your addresses. Whoever is asked is in a position to learn which group of addresses belongs to the same querying party, and from which IP address the query came.
• Connect to your own node and that query stays entirely inside your own machine. You can also broadcast your own transactions directly from your own node, which reduces the material available for inferring who first put a transaction on the wire. These two points are why a full node sits at the foundation of the best practices in the privacy topic.
• The limits need to be stated just as clearly. Running a node does not make on-chain transaction history any less public. Addresses that were previously linked to your real name at a KYC exchange are not detached by standing up a node. Network-layer privacy of the node itself — for example, your home IP address becoming observable as a public node — is a separate question, with measures such as running over Tor available.
• Nor is it as simple as "nothing is protected unless you run a full node." The compact block filters of BIP-157/158 structurally reduce query leakage on the light-client side. Privacy is best treated not as a binary but as a matter of degree, calibrated to a threat model: what do you want to hide, and from whom.

Relationship to a Lightning Node

• A Lightning node is software separate from a Bitcoin full node. Opening and closing channels are on-chain transactions, so a Lightning implementation needs some means of knowing the state of the chain. The assumptions about this "backend" differ by implementation: some require Bitcoin Core, while others can run in a light-client mode such as Neutrino.
• The nature of operating one is quite different. A Bitcoin full node essentially just reads and verifies; if it stops, restarting lets it catch up. A Lightning node, by contrast, must stay online continuously while holding funds, and brings operational requirements where failure translates directly into loss — backups of keys and channel state, and monitoring for fraudulent closes using outdated state (watchtowers).
• It is therefore easier to think of the order as: a Bitcoin full node first, and Lightning on top of it if you need it. The mechanics of Lightning itself — payment channels, HTLCs, routing — are covered in "Lightning Network Primer."

The Economics of Running a Node — There Is No Reward

• Let us correct a misconception up front. Running a full node earns you not a single satoshi of bitcoin. Rewards are paid for mining (as of August 2026, 3.125 BTC of new issuance per block plus transaction fees), and nowhere in the protocol is there any party that pays for the act of validation.
• The confusion arises because both look like machines humming away connected to the network. The jobs, however, are different. Mining is a for-profit activity competing on computing power for the right to create new blocks, and it requires specialized hardware and cheap electricity. Running a node is the act of applying the rules for your own sake: income zero, costs electricity, connectivity, and hardware.
• So what motivates it? First, self-verification: you can confirm your own balance and its conformity to the rules without asking anyone. Second, privacy, as described in the previous section — your queries never leave your machine. Third, a secondary public-good quality: the more reachable nodes there are, the more paths new participants have for obtaining blocks. But that third point is a contribution to others, not revenue for yourself.
• The "node count" metric needs careful reading. Publicly observed counts of "reachable" nodes — those accepting incoming connections — stood at roughly 20,000 to 30,000 in 2026 (Coin Dance displayed 23,795 at its final update in May 2026). But since Bitnodes, the standard source for thirteen years, went offline when its domain expired on May 3, 2026, no single authoritative figure exists.
• Estimates also diverge sharply. The total including nodes behind NAT or firewalls that accept no connections is commonly put in the range of tens of thousands up to around 100,000, yet a dashboard at the Karlsruhe Institute of Technology that counts unique IP addresses seen in gossip indicated something in the 250,000 to 350,000 range as of May 2026 — while other tallies put listening nodes at under 14,000, or even under 2,500. Published figures must always be read together with who measured them and when. Node count is also an easily inflated metric; what carries real weight is whether participants who actually receive and spend are verifying under their own rules.
• The one place income can arise is Lightning routing fees, but the amounts are small, and once you account for the opportunity cost of capital sitting in channels and the operational effort, whether it works as a business is a separate question. This site offers no forecasts or advice regarding profitability.

Practical Constraints and Risks

• On cost, the realistic burdens are the electricity of continuous operation, metered data charges, and hardware wear. The write endurance of SSDs and the failure of external drives in particular are things long-term operation will inevitably confront. The initial sync is the most demanding phase of all, and it is not unusual for a machine's weak points to surface right there.
• On operations, there is resyncing after power outages or restarts, and software updates. Updates that include vulnerability fixes are published from time to time, so leaving a node unattended should be avoided (the categories of defects found in the past are covered in "Bitcoin Vulnerabilities"). Settings that expose the RPC port or remote access to the outside also widen the attack surface, so the default of leaving them closed is the baseline unless you have a reason otherwise.
• Separating node data from funds matters too. A node and a wallet are distinct concepts: if node data is corrupted you can recover by resyncing, but wallet keys (the seed phrase) do not come back from a resync. Mistaking what needs backing up is the accident most worth avoiding when running a node.
• On the legal position in Japan: under the Payment Services Act, crypto-asset exchange business is a registration regime covering anyone who conducts, as a business, (1) buying and selling crypto assets or exchanging them for other crypto assets, (2) intermediation, brokerage, or agency for those acts, (3) managing users' money in connection with them, or (4) managing crypto assets for others (custody). Running a node — participating in the network for your own sake to verify and relay blocks — is generally understood not to fall under any of these categories of conduct. The assessment changes, however, once elements are added such as holding other people's assets alongside the node or providing exchange or brokerage services. The regime is also migrating to the Financial Instruments and Exchange Act under the amending act enacted on July 15, 2026, and the crypto-asset provisions had not yet taken effect as of August 2026 (no cabinet order fixing the enforcement date has been promulgated). Any specific determination should rest on current guidance from the authorities and professional advice.
• Finally, a limit on expectations. What your node protects is your own verification; it does not prevent harm to others. Nor does it guarantee that your node "wins" when rule changes are contested. What you reliably get is one thing: you cannot be made to accept a different set of rules without knowing it.

Summary — Who It Suits

• Stated neutrally, the conditions that suit running a node are: holding a large self-custodied balance and not wanting to depend on a third party's display; placing weight on privacy; wanting to confirm protocol behavior yourself for development, research, or teaching; and wanting to hold the idea of "applying the rules yourself" in a hands-on way.
• There are also cases where declining is entirely reasonable. Only a metered connection available; difficulty securing space and power for a machine that runs continuously; no time to spare for maintaining hardware; small-scale use for which a light wallet's assumptions are sufficient — all legitimate judgments. SPV is the usage the whitepaper anticipated from the outset, and it is not an inferior choice.
• There is a middle path as well. A pruned configuration lets you start from around 7GB, with validation exactly as strict as a default full node. Starting small and expanding capacity or configuration when the need arises is a practical way to proceed.
• A node is neither an investment product nor a source of income; it is a tool. The clearer you are about what you want to confirm without relying on anyone else's word, the clearer the point of running one becomes. This site recommends no particular configuration, product, or provider, and leaves the judgment to each reader's circumstances.