Use your own Bitcoin node
A node connection changes where the selected wallet obtains network data. It does not automatically configure every wallet application or make all computer traffic private. Bitcoin Core RPC and an Electrum protocol server are different connection types.
Watch the overview: Use your own node.
Before you start
Start with an authenticated Bitcoin Core download and sufficient disk/bandwidth capacity. Let chain synchronization finish. Check network, validated height, headers, progress and initial-block-download status together. Keep RPC credentials private and RPC on loopback for same-computer access; remote access requires a secured private connection.
Set up Bitcoin Core
- Open Bitcoin Core’s official download page. Choose your platform, save the matching signed checksums, and follow its verification instructions. Authenticate the signing-key fingerprints as well as checking that the file hash matches.
- Install Core and choose a data location with enough space. Decide whether pruning fits your wallet’s history needs. A pruned node validates blocks, but it cannot supply every old block for a later rescan.
- Start Core and let initial synchronization finish. In its console or command-line client, inspect getblockchaininfo: check the intended network, validated blocks, headers, estimated progress, and initial-block-download status together.
- For a wallet connection, enable the RPC server. Keep it on loopback for a same-computer setup. Treat RPC credentials as powerful access; never expose the RPC port directly to the public Internet.
- Restart Core after changing configuration, then repeat the readiness check. KeepKey recovery words are unnecessary here. Continue to the Sparrow connection lesson when Core is synchronized and its local RPC endpoint answers.
Connect Sparrow to Core
Follow Sparrow’s Core connection instructions for the current application’s configuration details.
- First let Core synchronize, enable its RPC server, and keep wallet support available. Open Sparrow’s Settings and select Server. Choose Bitcoin Core; an Electrum-server address belongs to a different connection type.
- On the same computer, use the local endpoint and Core’s cookie authentication. If you chose a custom Core data directory, select that directory so Sparrow can find the cookie. Keep the cookie private.
- Select Test Connection and inspect the returned result. A reachable process and a synchronized chain are separate checks. Resolve authentication, firewall, or configuration errors before treating missing wallet transactions as a zero balance.
- Import the intended public wallet account without entering recovery words. For an account with history, choose a scan starting point early enough to include it. With pruning, earlier blocks may need to be obtained again.
- Wait for the wallet scan to finish, then compare expected transactions and the connection status. Verify receiving addresses on the signing device. A remote node needs a secured connection and separate authentication planning; do not simply open RPC publicly.
Run your own Electrum server
Use the official electrs usage guide for the Core/electrs versions you install. The project’s current requirements take precedence over a frozen example.
- Electrs is an indexer in front of Bitcoin Core, not another wallet and not a miner. Start with its official installation and configuration guide, and check that your chosen Core and electrs releases are compatible.
- For the documented electrs path, Core needs server and REST access enabled, with pruning disabled. Its transaction index is not required by electrs. Budget storage for the chain and the additional index before starting.
- Install electrs from its official project instructions. Configure the Bitcoin network, Core data directory, authentication cookie, and a dedicated index directory. Do not reuse a directory holding unrelated files as the index database.
- Start the server and inspect its logs as indexing catches up. Core being synchronized does not mean the index is ready. Compare the indexed tip with Core and wait until wallet queries can be answered.
- Keep the Electrum listener on loopback for local use. Plain TCP is suitable only for the same-computer route; remote access needs a properly secured tunnel or transport. Continue only after checking the endpoint you actually configured.
Connect Electrum to your server
- Authenticate Electrum using its official download and signature guide. Open the intended wallet and its Network settings. Enter your own Electrum-server host and port, using the protocol your server actually provides.
- Turn off automatic server selection before choosing your private server. Automatic selection and connecting to only one server are different settings. For explicit single-server operation, use Electrum’s documented oneserver option with the chosen endpoint.
- For electrs on this same computer, the documented local example uses 127.0.0.1:50001:t. That final letter selects plain TCP. Do not copy this unencrypted route onto an untrusted network; plan secured remote access separately.
- Wait for the wallet to synchronize and inspect the connected-server details. Compare its chain tip and expected test-wallet history with your node. A familiar wallet balance alone does not identify the server supplying fresh data.
- As a controlled check, stop your own server and request fresh data. Expect connection failure, not an unexplained switch. Restore the service and confirm recovery. Never enter recovery words to repair a server connection or follow server-supplied update links.
Connect Desktop to Core
- In Desktop, select the intended Bitcoin-only wallet and open Self-host node in settings. An imported Bitcoin-only public watch-only wallet can use the saved node without a connected device; the wallet’s scope determines eligibility.
- Choose Bitcoin Core and enter its RPC URL. Enter the username and password separately. Use a local endpoint or secured private connection, and keep credentials out of screenshots and support messages.
- Select Test connection. Read the detected backend, network, height, and capability warnings. Correct mismatches before selecting Use my node. Desktop validates the endpoint again before saving it as the active connection.
- Allow the UTXO scan to finish. This Core backend discovers balances and unspent outputs, without transaction history. Legacy inputs may need Core’s transaction index to obtain full previous transactions for signing.
- Confirm active node status for the selected wallet. A failed active node should show an error. Leave self-host mode enabled for an outage test; deliberately disabling it changes routing. Offline mode separately blocks network operations.
Connect Desktop to Blockbook
- Begin with a synchronized Bitcoin Blockbook indexer. Select the intended Bitcoin-only wallet, then open Self-host node in settings. An imported Bitcoin-only public watch-only wallet can query the saved node without hardware connected.
- Choose Blockbook and enter its base URL, rather than an explorer page or Core RPC endpoint. Desktop uses Blockbook’s API. Keep a local deployment private, or secure the connection to a remote service.
- Select Test connection. Review the detected type, Bitcoin network, height, and synchronization warning. A reachable but lagging indexer can report incomplete balances or history. Let it catch up before relying on results.
- Choose Use my node after the test succeeds. This backend queries public account information for history and unspent outputs. Your indexer sees those queries; controlling it changes who learns the wallet’s activity.
- Confirm active node status and expected test-account history. Keep the same wallet scope for an outage check. Restore a failed indexer and retry. Deliberately disabling self-host mode is a separate choice that changes routing.
Check node failure behavior
- Use a test account and record the healthy backend. In Desktop, keep self-host mode enabled and the same Bitcoin-only wallet selected. A public watch-only wallet does not need connected hardware to use its configured node.
- Stop only the node or indexer you control. Request Test connection or inspect live node status. Expect an unreachable-node error. An old balance remaining visible does not establish that a fresh query succeeded.
- Desktop’s Core backend caches unspent outputs briefly. Judge its live probe separately from cached balances, and confirm the selected wallet’s scope. Switching wallets or deliberately disabling self-host mode changes the routing being tested.
- For Sparrow or Electrum, inspect private-server selection and isolation settings, then repeat a fresh-query test. Each application has its own connection rules. Desktop’s policy does not configure another wallet or privatize every application request.
- Restart your service, wait for synchronization, and require a successful fresh probe. Confirm wallet data again. Stronger proof requires observing network destinations; the accompanying video illustrates the test without claiming a traffic capture was performed.
Verify the result
For Desktop, select the same Bitcoin-only wallet throughout the test, then use Settings → Self-host node. Inspect Test connection, network, height and capability warnings before Use my node. A public Bitcoin-only watch-only wallet can query its saved node without connected hardware. A successful probe and a completed wallet scan are separate checkpoints.
If something fails
Stop the node or indexer you control while leaving self-host mode enabled. Request fresh data and inspect the live connection error. A cached balance is not a successful fresh query. Restore the service, wait for sync and require a successful probe. Disabling self-host mode or switching wallet scope changes the test.
Related
Last updated on