Your wallet says a payment is confirmed. Confirmed by whom? On 9 November 2026 at 08:56 UTC, the crawler at btcnodes.io listed 20,832 reachable Bitcoin nodes, each checking every new block against the same rules before passing it on. This guide explains how to run a Bitcoin node of your own, so that one of the machines answering that question for your money sits on your desk: the hardware to buy or reuse, how to install Bitcoin Core and prove the download is genuine, how to get through the first sync, and how to plug your wallet into it.
No programming is needed. You need a disk of 1 TB or more, a few days of patience and the habit of installing updates. The node pays nothing. In return you check the rules yourself, and your wallet stops telling a company’s server which addresses belong to you.
The kinds of node (full, pruned, archive, light) and why a node is not a miner are covered in our lesson on what a node is; this tutorial starts where its short “running one at home” sidebar stops. It also follows the previous lesson of this path, on the Lightning Network: every Lightning node watches the chain through a Bitcoin node, so the machine you set up here can later carry Lightning too.
What you need: about 1 TB of fast disk, 2 to 8 GB of RAM and a steady connection
Disk: 782 GB of blocks, and the figure only grows
As of 9 November 2026 at about 09:45 UTC, Blockchair put Bitcoin’s block data at 781,884,199,030 bytes, roughly 782 GB, at block 975,157. That is what an unpruned node keeps in its blocks folder before any optional index. Bitcoin Core’s download page still speaks of about 600 GB plus 5 to 10 GB a month: the monthly rate is the project’s own figure, the total is out of date.
The software plans with a wider margin. In the source code of Bitcoin Core 32.1, the main-network parameters assume 897 GB of block data plus 14 GB for the chainstate. The first-run screen of the graphical version adds those two figures and a 10 GB margin, and ticks the pruning box for you when the chosen disk has less free space than that. A 1 TB drive is therefore the floor for a full copy; a 2 TB drive leaves room for the indexes some wallet servers need and for several years of growth.
The chainstate folder holds every unspent output, the UTXO set described in our lesson on the UTXO and account models. It is far smaller than the blocks but is read and rewritten constantly, which is why disk speed matters more than disk size during the first sync. Once your node is synced, bitcoin-cli gettxoutsetinfo returns the exact number of unspent outputs and an estimate of the chainstate’s size on your own disk.
| Item | Size | Source and date |
|---|---|---|
| Block data, unpruned | about 782 GB | Blockchair, 9 Nov 2026, block 975,157 |
| Space Core plans for, unpruned | 897 GB of blocks plus 14 GB of chainstate | Bitcoin Core 32.1 source code |
| Space Core plans for, pruned | the prune target plus 14 GB | Bitcoin Core 32.1 source code |
| Smallest automatic prune target | 550 MiB | Bitcoin Core 32.1 source code |
| Growth of the chain | 5 to 10 GB a month | bitcoincore.org download page, read 9 Nov 2026 |
Memory, processor and connection
The full-node guide on bitcoin.org sets a low bar: 2 GB of RAM, a disk that reads and writes at 100 MB/s or more, an upload speed of at least 400 kilobits per second, and a machine left running at least 6 hours a day. Those minimums get a pruned node through, slowly.
Memory matters mostly for the database cache, the dbcache setting, which keeps part of the UTXO set in RAM so the node touches the disk less often. Since version 31.0, Bitcoin Core on a 64-bit system sets that cache to 1,024 MiB by default when it detects at least 4 GiB of RAM, and keeps the older 450 MiB otherwise. Inside containers the detected memory can exceed what the container may really use, and the release notes advise setting the cache by hand there. For a dedicated machine, 8 GB of RAM is the comfortable figure most home-node guides use.
Bandwidth is the cost people forget. Bitcoin.org says nodes on fast connections often upload 200 GB or more a month, against about 20 GB of download once the first copy is done. On a capped plan, that upload can end the month early; step 4 shows how to rein it in.
Choosing the machine: Raspberry Pi 5, mini-PC, old laptop or your own computer
The cheapest box to run is a single-board computer. The Raspberry Pi 5 has a quad-core 2.4 GHz Arm processor, 1 to 16 GB of RAM and a PCIe connector, but an M.2 SSD needs a separate HAT or adapter board, and Raspberry Pi recommends a 5 V, 5 A USB-C power supply. Take the 8 GB model or larger, and keep the node off the microSD card: Umbrel’s instructions say a Pi 5 must boot from an NVMe or USB drive instead.
A small x86 mini-PC, new or second-hand, has more room: memory slots, an internal SSD bay and a standard 64-bit processor that every distribution supports. An old laptop works if its disk is an SSD or can be swapped for one, and if you switch off sleep and suspend, which bitcoin.org warns can slow or halt the node. The computer you already own is the quickest start: install the graphical Bitcoin Core, prune if the disk is short, and let it run while you work.
| Machine | Good for | Watch out for |
|---|---|---|
| Raspberry Pi 5 (8 GB or more) | a quiet always-on box with low power draw | needs an NVMe HAT or USB 3 SSD; no microSD; slower first sync |
| Mini-PC (x86, 8 GB or more) | node, wallet server and Lightning on one box | fan noise on some models; check the SSD size |
| Old laptop | reusing hardware at almost no cost | sleep settings; replace a spinning hard disk with an SSD |
| Your everyday computer | trying a pruned node this week | runs only when the computer is on; shares disk and RAM |
Which software: Bitcoin Core on its own, or a node-in-a-box
Most reachable nodes run Bitcoin Core, and every option below builds on it. As of 9 November 2026 the latest version is 32.1, published on 28 October 2026 according to the project’s GitHub releases, together with maintenance releases 31.2, 30.4 and 29.5. (Version 32.0 was tagged but, as its release notes explain, never fully released.) It runs on Windows 10 version 1903 or later, macOS 14 or later and Linux with kernel 3.17 or later. The package holds the three programs this guide uses: bitcoin-qt, the graphical version with a wallet window; bitcoind, the same node without a window, for machines you reach over the network; and bitcoin-cli, which sends commands to a running node.
Umbrel, StartOS, RaspiBlitz and myNode put Core behind a dashboard
Node-in-a-box systems install a whole operating system on a dedicated machine, then offer Bitcoin and its companions as apps. umbrelOS cannot be added on top of another Linux; its app store lists a “Bitcoin Node” app powered by Bitcoin Core, a separate Bitcoin Knots app, and the electrs and Fulcrum servers named later in this guide. Umbrel is published under the PolyForm Noncommercial 1.0.0 licence: free for personal and non-profit use, while selling it on hardware needs the company’s permission.
StartOS, from Start9, is MIT-licensed and its marketplace lists a full Bitcoin node, a Lightning node and BTCPay Server. RaspiBlitz, also MIT-licensed, is a set of scripts that builds a Bitcoin and Lightning node on a Raspberry Pi 4 or 5. myNode has a free Community Edition and a paid Premium edition, bundles a Bitcoin full node with the LND Lightning software and other apps, and sells its own hardware.
The trade-off: a distribution spares you the configuration in this guide, and in return you wait for its maintainers to package each Bitcoin Core release and you trust their code as well as Core’s. Umbrel’s Bitcoin app, for example, added 32.1 on 30 October 2026, two days after the release. Doing the steps below by hand once, even on a spare machine, also teaches you what the dashboard does when something breaks.
Core or Knots, in two lines
Bitcoin Knots is a derivative of Bitcoin Core maintained by Luke Dashjr: same consensus rules, different default relay policy and extra options. In the 9 November 2026 crawl, 2,066 of 20,832 reachable nodes (9.9%) reported Knots in their user agent; the dispute behind that choice belongs to a later lesson of this path, on Bitcoin governance and BIPs.
How to run a Bitcoin node, step 1: download Bitcoin Core and verify it
This is the step people rush, and the one that matters most. A fake copy of Bitcoin Core could do anything with your machine and any wallet on it, and the project’s site carries an “X impersonation” notice in its menu because fake accounts circulate. The checks take about ten minutes and follow the bitcoincore.org download page.
- Type bitcoincore.org into the address bar yourself, open the download page and take the file for your system. Never use a link from an advert, a message or a video description.
- From the same page, download SHA256SUMS, the list of checksums of every release file, and SHA256SUMS.asc, the signatures of that list by the people who built the release. Keep all three files in one folder.
- Open a terminal in that folder and check the checksum. On Linux and macOS, the command below compares your file with the list and must print “OK” after its name. On Windows,
certUtil -hashfilefollowed by the file name andSHA256prints the checksum, which you compare character by character with the matching line of SHA256SUMS; without the word SHA256, certUtil computes a different kind of hash that will never match. - Install GnuPG if you do not have it, then import the public keys of a few builders you choose from the builder-keys folder of the bitcoin-core/guix.sigs repository. The download page uses fanquake.gpg as its example.
- Run
gpg --verify SHA256SUMS.asc SHA256SUMS. Each valid signature prints a line starting with “gpg: Good signature” and a “Primary key fingerprint” line. Check that fingerprint against the one you expect for that builder, ideally from a second source. Warnings that a public key is not available concern signers you did not import and can be ignored, as long as every signer you trust shows a good signature. - Only then run the installer on Windows, move the application to the Applications folder on macOS, or unpack the archive on Linux.
The commands, as given on the download page for version 32.1. The first line is for Linux and the second for macOS; the next two are for the Windows command prompt (put the name of the file you actually downloaded); the last two work on every system once you have downloaded a builder’s key file from guix.sigs.
sha256sum --ignore-missing --check SHA256SUMS
shasum -a 256 --ignore-missing --check SHA256SUMS
certUtil -hashfile bitcoin-32.1-win64-setup.exe SHA256
type SHA256SUMS
gpg --import fanquake.gpg
gpg --verify SHA256SUMS.asc SHA256SUMSWhat a good signature proves, and what it does not
The checksum proves your file is the one listed in SHA256SUMS. The signatures prove that people whose keys you chose published that list. Neither proves the code is free of bugs, and the whole chain is only as strong as your choice of keys: a key taken from a fake site proves nothing. This is where Bitcoin Core’s reproducible builds come in. Several contributors build each release from the public source code on their own machines, check that they get identical files and sign the result in the guix.sigs repository; anyone can repeat the build and compare.
One exception: the project says it lacks the information to help verify the Snap package of Bitcoin Core. Take the files from bitcoincore.org if you want to follow every check above.
Step 2: write a bitcoin.conf that fits your machine
Bitcoin Core runs with sensible defaults, and many home nodes never need a configuration file. When you want one, it is a plain text file called bitcoin.conf that you create yourself in the data directory: $HOME/.bitcoin/ on Linux, $HOME/Library/Application Support/Bitcoin/ on macOS and %LOCALAPPDATA%\Bitcoin\ on Windows, according to the Bitcoin Core configuration documentation.
Each line reads option=value, without the leading dash used on the command line; # starts a comment. Command-line options beat the settings the graphical version saves, which beat bitcoin.conf. Every change needs a restart, and an option the program does not recognise shows up as a warning in debug.log, in the same folder. Read that file after each edit.
| Option | What it does | When to use it |
|---|---|---|
| server=1 | accepts commands over RPC from bitcoin-cli and wallets | almost always on a home node |
| prune=550 | keeps only recent blocks, at least 550 MiB | short disk; no wallet server |
| dbcache= | size of the database cache in MiB | raise during the first sync if RAM allows |
| txindex=1 | indexes every transaction | required by Fulcrum; impossible with pruning |
| blockfilterindex=1 | builds BIP 158 compact block filters | faster wallet rescans; serving light wallets |
| peerblockfilters=1 | serves those filters to peers (BIP 157) | helping light clients; off by default |
| maxuploadtarget= | tries to keep upload under a daily target, in MiB | capped internet plans |
| blocksonly=1 | stops relaying unconfirmed transactions | saving bandwidth; costs fee estimation |
An example for an 8 GB machine with a 2 TB SSD that will also feed a wallet server: every block kept with a transaction index, compact filters built, a larger cache for the first sync only (delete that line afterwards) and an upload target of about 5 GB a day.
server=1
txindex=1
blockfilterindex=1
dbcache=2000
maxuploadtarget=5000Go easy on the cache. Its help text says to make sure you have enough RAM, and Core prints a warning when the value looks too large for the machine. A node killed for lack of memory loses whatever progress was still in the cache and may need a long repair at restart. On an 8 GB Pi 5, the RaspiBolt guide uses 2,000 MiB during the first sync and drops it afterwards; it was written before the new 1,024 MiB default, so the gain is smaller now.
To rehearse before real money is involved, run the whole guide on signet or testnet4. Bitcoin Core keeps each test network in its own subfolder of the data directory, with coins that have no value: the right place to practise wallet connections and Tor.
Step 3: the first sync, or initial block download
What your node does during those days
On first start the node finds peers through a short list of DNS seeds run by known contributors, then through the addresses those peers share; our lesson on peer-to-peer networks covers the mechanics. It downloads the chain of block headers first, picks the one with the most proof of work, then fetches the blocks from several peers at once. Each block is checked and applied to the chainstate: spent outputs leave the UTXO set, new ones join it. At the end your node has rebuilt, on its own, the same set of unspent coins as every other honest node.
One shortcut is built in. Each release carries an assumevalid block hash, reviewed like the rest of the code. For that block and its ancestors, the node may skip checking the signatures inside the scripts; it still checks proof of work, block structure and every coin’s accounting. In version 32.1 that block is block 966,143, which you can look up as shown in our guide to reading a block explorer. Setting assumevalid=0 makes the node verify every signature since 2009, which is slower.
A second shortcut, assumeutxo, is for experts. The node loads a snapshot of the UTXO set at a fixed height (version 32.1 accepts snapshots at heights 840,000, 880,000, 910,000, 935,000 and 965,000), becomes usable once it has caught up from there, and checks the older history in the background. You must find the snapshot file yourself and load it with the loadtxoutset command, so it is not a first-timer’s step.
How long it takes: hours on a fast desktop, days on a Pi
Bitcoin Core’s README says the synchronisation “can take anywhere from a few hours to several days or more”, and bitcoin.org warns of at least several days. For a Raspberry Pi 5 with a good SSD, RaspiBolt’s Bitcoin client page gives roughly two to five days, against five to seven for a Pi 4 with 8 GB. A recent desktop with a fast NVMe drive sits at the short end of the README’s range.
Disk speed, cache size and peers decide where you land. A spinning hard disk can stretch the sync over many days, because the chainstate is read in small random pieces, and a small cache sends more of those reads to the disk. A sync that crawls with almost no connections usually points to a network or firewall problem rather than the disk.
Two commands show progress. bitcoin-cli getblockchaininfo returns the current height, the best known header and a verificationprogress value that climbs towards 1 (in version 32 it also shows a backgroundvalidation section when a snapshot is loaded). bitcoin-cli getconnectioncount gives the number of peers. You can keep using the computer meanwhile, but the node will compete for disk and memory.
Pruning keeps every check and drops the old files
A pruned node is still a full node. It downloads and verifies every block once, then deletes old block files, keeping the chainstate and at least the latest 288 blocks, about two days. The setting is prune= followed by a target in MiB, 550 being the smallest automatic value; prune=1 lets you delete blocks by command instead.
The price: no transaction index, so no Fulcrum and no answers about old transactions; no wallet rescan past the blocks still on disk; and, as the help text warns, turning pruning off later means downloading the whole chain again. For a node that only checks your own wallet from now on, those limits rarely bite.
Step 4: open port 8333 for inbound peers, or decide not to
Without inbound connections your node still works. It opens its own outbound links, eight that relay transactions and blocks plus two that relay blocks only, per the defaults in the source code. Inbound connections let other nodes reach yours, which helps the network and puts your node in crawls like the one quoted above. Bitcoin uses port 8333 for peers on the main network and port 8332 for RPC commands; only 8333 should ever face the internet.
- Give the node’s machine a fixed address on your home network, in the router’s settings, so the forwarding rule keeps pointing at it.
- Forward TCP port 8333 from the router to that address, and allow it in the machine’s firewall.
- Restart the node and, an hour later, run
bitcoin-cli getnetworkinfo: its connection fields show how many inbound and outbound peers you have.
Bitcoin Core can try the forwarding itself. Version 29.0 dropped UPnP; the remaining method, PCP or NAT-PMP, is on by default in 32.1 when the node listens and no proxy is set. Many routers ignore it, which is why bitcoin.org still explains the manual way.
If upload worries you, maxuploadtarget aims for a daily ceiling but is not a hard cap: blocks from the past week are still served. blocksonly=1 cuts traffic much further by refusing unconfirmed transactions from peers, at a price: your node stops estimating fees from its own mempool, the subject of our lesson on the mempool and transaction fees, and stops broadcasting wallet transactions automatically.
Step 5: run the node over Tor
By default your node connects from your home IP address, so its peers, and anyone watching them, can tie that address to a Bitcoin node and to the transactions it is first to announce. Tor takes the address out of the picture. The project’s Tor documentation gives the full setup; on Linux, the minimal version runs as follows.
- Install the Tor service from your system’s packages and check that it runs; it opens a SOCKS proxy on 127.0.0.1:9050 by default (Tor Browser uses 9150 instead).
- In Tor’s configuration file, usually /etc/tor/torrc, add the four lines shown below, which open the control port and cookie authentication so Bitcoin Core can create an onion address for itself.
- Add the user that runs Bitcoin Core to Tor’s group (often debian-tor on Debian and Ubuntu) so it can read Tor’s authentication cookie, then restart Tor.
- In bitcoin.conf, set
proxy=127.0.0.1:9050to send outbound traffic and DNS lookups through Tor, andlisten=1, because a proxy turns listening off by default.listenonionis already on and creates the onion service. - For no clearnet connections at all, add
onlynet=onion, and expect fewer peers to choose from and a sync that can be slower.
The four lines for torrc:
ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1
DataDirectoryGroupReadable 1And the lines for bitcoin.conf, the last one only if you want Tor peers alone:
proxy=127.0.0.1:9050
listen=1
onlynet=onionThe 32 line brings one protection: onion services that Bitcoin Core creates automatically get Tor’s proof-of-work defence against connection floods, when the Tor daemon supports it. Core can also use the I2P network, with i2psam pointing at a local I2P router and i2pacceptincoming to accept peers there.
What Tor hides and what it does not
Over Tor, peers see an onion address instead of your IP. In the 9 November crawl, 9,884 of the 20,832 reachable addresses were onion addresses, 4,694 were I2P, 5,574 IPv4 and 680 IPv6. An address is not a person: one operator can run several, and a node reachable on both Tor and clearnet lets an observer link the two, as the documentation warns. If you set only an onion proxy (the onion= option) rather than the general proxy= line, DNS lookups go through your provider, which then sees that you run a node.
Tor protects the node’s traffic. It does nothing about what your wallet reveals when it asks a stranger’s server about your addresses, which is the next step.
Step 6: connect your wallet to your own node
A node no wallet uses only protects the network. Your own benefit starts when your wallet asks your node, and nobody else, whether a payment arrived. Keys stay where they are: a node never needs your seed phrase, and no software that links a wallet to a node should ask for it.
Sparrow on the same machine
- Make sure bitcoin.conf contains
server=1and does not containdisablewallet=1, then restart Bitcoin Core. - Optionally add
blockfilterindex=1(Bitcoin Core 25 or later) for faster rescans, andtxindex=1if the node is not pruned. - In Sparrow’s server settings, choose Bitcoin Core and keep the local address and default port; Sparrow authenticates with the cookie file Core writes in its data directory at each start.
- Press Test Connection, then open your wallet: balances and history now come from your node.
Those steps follow Sparrow Wallet’s documentation, which also covers a node on another machine of your home network: an RPC user and password, with rpcbind and rpcallowip limited to local addresses. Keep the RPC port off the internet. Verify Sparrow’s own download as well: version 2.5.6 comes with a manifest signed by its developer, Craig Raw, and the application can check a download’s signature from its Tools menu.
Electrum and phone wallets through Fulcrum or electrs
Electrum and many mobile wallets do not talk to Bitcoin Core directly. They speak the Electrum protocol to a server that indexes the chain by address, and Fulcrum and electrs are two such servers you can run next to your node. Fulcrum needs an unpruned Bitcoin Core with txindex=1 and RPC enabled, at least 1 GB of RAM and preferably an SSD; its README puts the first index build at 4 to 20 hours or more. electrs builds a similar index. Both take extra disk space, which is where the 2 TB drive earns its place.
October gave a concrete reason to bother. Before version 4.8.3, Electrum took its server’s word about unconfirmed payments. A malicious server could hide a payment the user had just sent and show a forged one in its place; when the user raised the fee, the genuine wallet signed a payment to the attacker. The advisory rated the flaw High and said some servers were running the attack in the wild, as our report on the Electrum fee-bump theft explains. A wallet that only talks to your own server never meets a stranger’s.
Compact block filters for light wallets, BIP 157 and 158
BIP 157, by Olaoluwa Osuntokun, Alex Akselrod and Jim Posen, lets light wallets use a node without telling it which addresses they watch. The node computes a small filter per block, in the BIP 158 format; the wallet downloads the filters, tests its addresses locally and fetches only the blocks that match. It replaced the bloom filters of BIP 37, which leaked addresses and could be abused to load nodes. On your node, blockfilterindex=1 builds the filters and peerblockfilters=1 serves them. Neutrino, the client named in the BIP, also powers the light mode of the LND Lightning software; Sparrow does not use filters to reach your node.
Lightning on top
A Lightning node such as LND or Core Lightning needs a Bitcoin backend to watch for channel openings, closings and cheating attempts. The node you have just built can be that backend. Finish the first sync before adding Lightning, and plan its backups seriously: unlike a plain Bitcoin node, a Lightning node holds funds.
Step 7: keep it updated before its version reaches end of life
A node left alone for two years becomes a liability. Bitcoin Core’s life-cycle page states: “We always maintain the latest three major versions.” When a new major version ships, the oldest maintained line reaches end of life and does not generally receive security fixes any more. The project aims for a major release every six to seven months.
| Version line | Released | End of life (bitcoincore.org, read 9 Nov 2026) |
|---|---|---|
| 32.x | 27 Oct 2026 | after version 35.0 |
| 31.x | 19 Apr 2026 | after version 34.0 |
| 30.x | 10 Oct 2025 | after version 33.0 |
| 29.x | 14 Apr 2025 | 27 Oct 2026 (ended) |
| 28.x | 2 Oct 2024 | 19 Apr 2026 (ended) |
Many operators lag. In the 9 November 2026 btcnodes.io snapshot, more than 3,000 of the 20,832 reachable nodes still reported version 28 or older, lines that no longer get fixes; version strings are self-reported, so read that as an order of magnitude. A crawl by the Karlsruhe Institute of Technology on 18 October gave a similar picture for Bitcoin Core nodes, as our report on outdated Bitcoin Core nodes shows; the two crawlers count differently, so their figures do not make a trend.
The cost of falling behind showed on 28 October 2026, when the project published three advisories for bugs found by an AI-driven scan. The most serious let a malicious peer exhaust the memory of a node on Windows, macOS or BSD until it crashed. Fixes shipped in 29.5, 30.4, 31.2 and 32.1 together; older lines got none, as our report on the AI-found Bitcoin Core bugs details.
bitcoin-cli getnetworkinfo shows your version in its subversion field. To upgrade:
- Stop the node with
bitcoin-cli stopor the Quit menu, and wait until it has completely shut down, which can take a few minutes. - Download and verify the new release exactly as in step 1.
- Run the installer on Windows, replace the application on macOS, or replace the bin and libexec folders on Linux.
- Start the node and check the version. Coming from an end-of-life version, the first start can take longer while the data directory is migrated.
The life-cycle page recommends the latest maintenance release of the most recent major version you are able to upgrade to. On a node-in-a-box, check that the distribution’s Bitcoin app has followed. Backups are short: a node without a wallet holds nothing that cannot be downloaded again. If you use Bitcoin Core’s built-in wallet, back it up and keep its seed phrase or descriptors offline, as for any wallet.
What a Bitcoin node costs to run: electricity, bandwidth and time
Hardware is a one-off, and the cheapest is the machine you already own. The running cost is electricity: watts times 8,760 hours, divided by 1,000, gives kilowatt-hours a year; multiply by your price per kWh.
Raspberry Pi does not publish the Pi 5’s draw under a node’s load, so the wattages below are assumptions for the example: 10 W for a Pi 5 with an SSD, 25 W for a mini-PC, 50 W for an old desktop. A plug-in power meter gives your real number within a day. Prices come from the US Energy Information Administration (average residential price, August 2026, preliminary), Ofgem (price cap average unit rate for direct debit, 1 October to 31 December 2026) and Eurostat (EU household average, first half of 2026, taxes included).
| Example machine (assumed draw) | kWh a year | US at 18.16 cents/kWh | UK at 26.32p/kWh | EU average at 0.2832 EUR/kWh |
|---|---|---|---|---|
| Pi 5 with SSD (10 W, example) | 87.6 | about $16 | about £23 | about 25 EUR |
| Mini-PC (25 W, example) | 219 | about $40 | about £58 | about 62 EUR |
| Old desktop (50 W, example) | 438 | about $80 | about £115 | about 124 EUR |
The UK rate is an average for England, Scotland and Wales; Ofgem says there is no VAT on electricity from 1 October 2026 to 31 March 2027, and the daily standing charge is due with or without a node. The US average hides a wide spread between states. The arithmetic makes the point: the machine you pick, more than the country, decides whether the bill is a rounding error or a real line in the budget.
Bandwidth comes second, at the 200 GB or more of monthly upload quoted earlier if you accept inbound peers. Time comes third: an evening of setup, days of waiting for the sync, then a few minutes per release.
Mistakes that cost node operators days, or more
- Installing Bitcoin Core from a link in an advert or a message, or skipping the checksum and signature checks.
- Running a Raspberry Pi node from its microSD card instead of an SSD.
- Setting a cache larger than the machine’s free memory, so the node is killed before it saves its progress.
- Forwarding the RPC port, 8332, instead of the peer port, 8333.
- Pruning the node, then trying to install Fulcrum or rescan an old wallet.
- Letting a laptop sleep through the night and wondering why the sync never ends.
- Leaving the node on a version past its end of life.
Once your node is synced and your wallet points at it, the next lesson of this path turns to what people have started writing into Bitcoin blocks: ordinals, runes and BRC-20 tokens, and why some node operators object.
