Self-Custody Bitcoin: Node and Wallet Setup

The evolution of Bitcoin self-custody solutions has created a complex ecosystem where understanding the distinction between server-side and client-side applications becomes crucial for maintaining security and functionality. This analysis explores the fundamental architecture of Bitcoin nodes, wallet integration, and the importance of proper setup for maintaining true self-custody.

The relationship between Bitcoin nodes and wallet software represents a critical intersection in the self-custody landscape. A Bitcoin node serves as the backbone of the network, validating transactions and maintaining a copy of the blockchain, while wallet software provides the interface through which users interact with their bitcoin. Understanding this separation of concerns is essential for implementing secure self-custody solutions.

Server applications, such as Bitcoin Core and Electrum Server implementations, are designed to run continuously on dedicated hardware, providing services to multiple clients while maintaining consistent network connectivity. These services form the foundation of a self-sovereign Bitcoin infrastructure, enabling users to validate transactions and interact with the network without relying on third-party servers.

Client applications, by contrast, are designed to run on personal computers and mobile devices, providing user interfaces and handling sensitive operations like transaction signing. This separation serves both security and practical purposes. Wallet software needs direct access to hardware devices and local system resources, which is more appropriate for client machines than servers.

The implementation of air-gapped cold storage adds another layer of complexity to this architecture. Cold storage solutions deliberately maintain physical separation between signing devices and networked computers, requiring careful consideration of how these components interact. This security model relies on the ability to carry unsigned transactions to the air-gapped device and the signed transactions back to the networked computer.

When setting up a self-custody solution, it’s critical to understand the proper placement of different components. The node and associated services should run on dedicated server hardware, while wallet software should operate on personal computing devices. This separation maintains security boundaries while enabling proper access to necessary system resources.

Electrum Server implementations like electrs play a vital role in this architecture by indexing the blockchain and providing efficient access to transaction data. However, these services operate at the protocol level and should not be confused with user-facing wallet applications. The distinction becomes particularly important when implementing hardware wallet solutions.

Hardware wallets represent the gold standard for securing private keys, but their integration requires direct physical connection or air-gapped transfer mechanisms. This necessitates running wallet software on machines with appropriate hardware interfaces, typically personal computers rather than headless servers.

The future of Bitcoin self-custody continues to evolve, with emerging solutions seeking to balance security, usability, and sovereignty. Innovations in hardware security modules, multisignature schemes, and network protocols are expanding the possibilities for secure bitcoin storage while maintaining the fundamental principles of self-custody.

As the ecosystem matures, maintaining clear boundaries between server and client components becomes increasingly important. This separation enables specialized solutions for different aspects of Bitcoin interaction while preserving the security properties that make self-custody effective. Understanding these distinctions helps users implement robust solutions that align with their security needs and technical capabilities.

Step-by-Step Guide

Follow this process to set up a proper self-custody Bitcoin stack with separate node and wallet components.

Your node, a computer that stays on day and night with no screen (steps 1 to 4), runs two programs. Bitcoin Core exchanges blocks and transactions with other nodes on the network and checks every block against the rules itself. An Electrum server, electrs or Fulcrum, indexes those blocks by address (umbrelOS on a Pi set up the way Umbrel recommends can't run one yet, see step 4). Sparrow, on your computer (step 5), talks to the Electrum server over your home network or Tor. It holds only your xpub, so it sees every address and balance but has no private keys and can't sign. Payments go to your hardware wallet (step 6) to sign, by USB, QR code or microSD, and come back signed. The hardware wallet holds your private keys, made and kept inside, and shows and signs each payment. Step 7 tests every link with a small payment in, then one out. — **The node checks, the computer watches, the device signs.** Steps 1 to 4 build the node, step 5 puts Sparrow on your computer and step 6 adds the hardware wallet. Of the three machines, only the hardware wallet ever holds a private key; its backup is your recovery words, on paper or metal.

1. Choose Your Node Hardware

Dedicate a machine for running your Bitcoin node. For a budget setup, a Raspberry Pi 5 with 8 GB of memory and a 2 TB SSD in a USB 3 enclosure works; our node setup lesson explains why it suggests a Pi 5 rather than a Pi 4. For better performance, use an Intel or AMD mini-PC or an old laptop with a 2 TB internal SSD. Buy 2 TB: as of November 2026 Bitcoin Core plans for about 900 GB of disk, and the blockchain grows by roughly 80 GB a year. The node runs 24/7, so choose hardware with low power consumption. Avoid running your node on your daily-use computer — it needs to stay online continuously and the initial sync uses significant resources.

2. Install Node Software

Choose between a plug-and-play solution (Umbrel, Start9, RaspiBlitz) or a manual Bitcoin Core installation. Plug-and-play options include a web interface and one-click app installation for Electrum Server, Lightning, and other services. Manual installation gives you more control but requires command-line skills. Regardless of method, enable Tor for all connections during initial setup to protect your IP address from the Bitcoin network.

3. Wait for Initial Block Download (IBD)

Your node must download and verify the entire Bitcoin blockchain, about 800 GB as of November 2026. Expect roughly two to four days on a Raspberry Pi 5 and a day or two on a mini-PC with a fast NVMe SSD. Do not attempt to use the node before IBD completes. Monitor progress through your node’s dashboard or by checking the debug log. A partially synced node cannot reliably verify transactions.

4. Install and Configure Electrum Server

Install electrs (Rust implementation) or Fulcrum (C++ implementation) on your node. These index the blockchain so wallet software can efficiently query address balances and transaction history. electrs keeps the smaller index; Fulcrum answers wallets faster, but its index is bigger and it needs Bitcoin Core’s transaction index (txindex=1). electrs doesn’t need txindex, but since version 0.12 (September 2026) it needs Bitcoin Core 31 or later with the REST interface switched on (rest=1). Neither works with a pruned node. The Electrum Server provides the bridge between your node and your wallet software through a standard protocol. One exception, as of November 2026: on a Raspberry Pi that runs umbrelOS from the microSD card, as Umbrel recommends, an Electrum server can’t move to the external SSD and its index won’t fit on the card, so on that setup you connect Sparrow straight to Bitcoin Core over Tor instead, as our node setup lesson shows. Keep the .onion address and the password Umbrel gives you for it private; Bitcoin Core warns that its RPC interface isn’t hardened against outside traffic, even through a Tor onion service.

5. Set Up Wallet Software on Your Personal Computer

Install Sparrow Wallet on your laptop or desktop. In Sparrow’s Settings, on the Server tab, choose Private Electrum and point it to your node’s Electrum Server. Over Tor, enter the Electrum server’s own .onion address and port, not the one Bitcoin Core uses for its peers. Umbrel and RaspiBlitz create it with the app, Start9 has you add one to the Electrum interface, and on a manual install you add it to Tor’s configuration yourself. If on the same local network, use the local IP. Click Test Connection: a green tick appears on the button, and Sparrow shows the name and version of your server. Once Sparrow is connected, its status bar reads “Connected to … at height …”, and that block height should match your node’s.

If Bitcoin Core runs on the same desktop you use as your wallet computer (see the first FAQ below), Sparrow can also skip the Electrum server and talk to Bitcoin Core directly: choose Bitcoin Core on the same tab. On one machine it authenticates with Bitcoin Core’s cookie file; bitcoin.conf needs server=1 and must not contain disablewallet=1. Connecting that way directly from another computer needs rpcbind and rpcallowip lines plus a user name and password (Bitcoin Core prefers an rpcauth line to rpcuser/rpcpassword). That opens the node’s full RPC interface to your network without encryption, so the password crosses it in clear text; for anything beyond a single machine, the Electrum server is the safer route. The direct connection also works with a pruned node, with one limit: Sparrow cannot find transactions older than the earliest block the node still keeps.

Phone wallets connect the same way. Use a mobile wallet that lets you set your own Electrum server and route it through Tor, enter the Electrum server’s .onion address (on Android, Orbot supplies Tor to apps without a built-in client), and switch off any automatic fallback to public servers so a dropped connection shows as offline instead of sending your addresses elsewhere.

Three ways a wallet can reach your Electrum server. At home: Sparrow on your computer uses the node's local IP address, kept fixed with a DHCP reservation on your router, and the traffic stays on your home network. Away from home: your phone or laptop uses the Electrum server's .onion address through Tor. Both the phone and the node connect out to Tor, so no port is open, and it works whatever your home IP address is. An open router port, 50001 or 50002 forwarded to the internet, is a door anyone can come through: never do it. Anyone who finds it can use your server, and port 50001 isn't encrypted. — **Use the local address at home and Tor everywhere else.** Neither one opens a door in your router. Port forwarding does, for anyone who looks.

6. Connect Your Hardware Wallet

Plug your hardware wallet (Coldcard, Trezor, Ledger, or Passport) into your personal computer via USB, or use air-gapped transfer via QR codes or microSD. In Sparrow, create a new wallet and select your hardware device. Import the public key (xpub) — the private keys remain on the hardware device. Sparrow uses your Electrum Server to look up address balances and broadcast transactions, while the hardware wallet handles signing. Before funding the wallet, export its output descriptor from Sparrow and store it with your backup notes. For a single-signature wallet the seed (plus its passphrase, if you set one) is enough to recover the funds, and the descriptor saves you guessing the script type and derivation path; for multisig, you need enough seeds to meet the threshold plus the descriptor, which records every cosigner’s xpub, the threshold, the script type and the derivation paths.

7. Verify the Full Stack Works End-to-End

Send a small test transaction to your new wallet. Watch it appear in Sparrow as unconfirmed, then confirmed. Verify the transaction in your node’s mempool and block explorer. Create a test outgoing transaction, sign it on the hardware wallet, and broadcast it. Without Tor, Sparrow sends it through your node; when Sparrow connects over Tor, it sends it over Tor through a public server instead, which its FAQ calls more private, and waits until your node has received it. Confirm the transaction propagates to the network. Once this round-trip works, your self-custody stack is fully operational.

Four steps. 1 Build: Sparrow builds the payment, unsigned, on your computer. The unsigned payment goes to the hardware wallet. 2 Sign: you check the address and amount on the device's own screen, and it signs inside. The signed payment comes back to Sparrow. 3 Send: back in Sparrow, you send it, and Sparrow waits until your own node has it. 4 Confirm: it waits in nodes' mempools until a miner puts it in a block. Only the payment goes to the device and back, by USB, QR code or microSD; the keys never leave it. — **Only the payment travels to the device and back; the keys stay inside it.** The device, reached by USB, QR code or microSD, is the one place where an unsigned payment becomes a signed one. Without Tor, Sparrow sends it through your node; over Tor it uses a public server, and either way it waits until your node has the payment.

Common Mistakes to Avoid

1. Running Wallet Software on the Node Server

Installing Sparrow Wallet or Electrum directly on your headless node server works against this setup. Sparrow’s build for machines without a screen only creates software or watch-only wallets, so it can’t use your hardware wallet, and you would be left driving the device through command-line tools such as HWI. It also adds wallet software to a machine that is online day and night. Keep the node as a server-only machine and run wallet software on your personal computer where you can physically connect signing devices.

2. Exposing Your Electrum Server Port to the Internet

The Electrum Server ports (50001 for plain connections, 50002 for encrypted ones) should never be reachable from the public internet. An exposed port lets anyone who finds it use your server: the electrs README warns that running it publicly exposes you to denial-of-service and possibly other attacks, and its documentation recommends plain connections only on your local network, because on the open internet anyone along the way can read what your wallet asks. Use Tor hidden services for remote access or restrict connections to your local network. Firewall rules should block all external access to Electrum Server ports.

3. Skipping Tor Configuration During Initial Setup

Without Tor, every peer your node connects to over the ordinary internet sees your home IP address, and your ISP can see that you run a Bitcoin node. Anyone connected to many nodes can also watch which node announces a transaction first and guess where it started; researchers showed this in 2014, as our network privacy lesson explains. Configure Tor before your node connects to any peers. Retroactively adding Tor helps for future connections but does not erase the peer records from your non-Tor period.

4. Using Public Electrum Servers as a Fallback

When your personal node is temporarily offline, it is tempting to switch Sparrow to a public Electrum server to check your balance. This sends every address in your wallet to the public server operator, who can now see your complete transaction history and current holdings. Wait for your node to come back online, or accept that you cannot check your balance until it does. The privacy cost of using a public server is too high for a single convenience check.

While your node is offline, the network carries on. Your node goes offline after your payment went out; other nodes keep your payment in their mempools; a miner puts it in a block; back online, your node downloads the blocks it missed. Your wallet should wait for it: Sparrow shows Disconnected and nothing leaves your computer. Switching to a public server instead sends every address in your wallet, linked, to its operator, who then sees your balance, history and, without Tor, your IP address. — **Your node going offline pauses your view, not your bitcoin.** A payment you already sent confirms as it would with your node online, and nothing is lost. Switching to a public server to check your balance hands a stranger your whole wallet.

5. Neglecting Node and Software Updates

Running outdated Bitcoin Core or Electrum Server versions can expose you to security vulnerabilities and consensus bugs. Check for updates monthly. Read the release notes before updating — a new version occasionally has to rebuild an index, and the notes say so when it does. Keep your node software, Electrum Server, and wallet software all within their supported version ranges to avoid compatibility issues.

6. Trusting the Address on Your Computer Screen

Your own node tells you the truth about the blockchain, but it cannot protect the screen of the computer running Sparrow. Malware there can swap the receive address you copy or share for one it controls. Before giving out an address, display it on the hardware wallet (for a USB-connected device, Sparrow’s Receive tab has a Display Address button; air-gapped devices can show their addresses from their own menus) and check that the two match character for character. The hardware wallet’s screen is the one you can trust.

A swapped address can start and end like yours. Checking the first and last few characters is not enough. Compare the whole address with the one your hardware wallet shows on its own screen.

Frequently Asked Questions

Can I run a Bitcoin node and wallet on the same machine?

Yes, if the machine is your personal desktop that you use directly (not a headless server). Bitcoin Core’s built-in wallet works on that desktop too. It can sign with a hardware wallet only through an external signer, a separate tool such as HWI, so Sparrow, as in step 5, is the simpler route. However, for a dedicated node that runs 24/7, keep it separate from your wallet machine. The node stays online serving the network, while your wallet machine connects only when you need to transact.

What happens if my node goes offline while I have pending transactions?

Once your transaction has reached the network, it waits in the mempools of other nodes (there is no single mempool: each node keeps its own), so it confirms just as it would with your personal node online. When your node comes back, it syncs the missed blocks and updates your wallet’s view. You will not lose funds or miss confirmations — you just temporarily cannot see updated balances until your node catches up.

Do I need a static IP address to run a Bitcoin node at home?

No. Most home internet connections use dynamic IP addresses, and Bitcoin nodes handle this gracefully. If you use Tor (recommended), your node gets a stable .onion address that works regardless of your IP changes. For local network access, use your router’s DHCP reservation to assign a consistent local IP to your node. External connections through Tor do not depend on your public IP at all.

How much bandwidth does a Bitcoin node use per month?

Most of a node’s traffic is upload: the blocks and transactions it passes on to other nodes. bitcoin.org says it is common for full nodes on fast connections to upload 200 GB or more a month, and puts downloads at about 20 GB a month once the first sync (about 800 GB as of November 2026) is done. To use less, set maxuploadtarget in Bitcoin Core (a target per 24 hours, not a hard cap) or switch off incoming connections with listen=0, so fewer nodes connect to yours. Watch your usage for the first month and adjust.

Related Resources

Part of our free Bitcoin course: This topic is covered in Setting Up Your Bitcoin Node Step by Step, from the Lightning Network & Bitcoin Nodes course.

Filed under: Bitcoin Nodes & Infrastructure