> ## Knowledge Base Index > Fetch the complete knowledge base index at: https://help.bitcoinwell.com/sitemap.xml > Use this file to discover available pages before exploring further. > Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash). # Connect Sparrow to your own Bitcoin Core node Sparrow needs a server connection to find transactions and broadcast new ones. A public server is convenient, but its operator can observe the wallet information Sparrow requests and associate activity with your connection. Connecting Sparrow to your own Bitcoin Core node removes that third-party server from the path and lets your node validate blockchain data locally. This article covers the Sparrow side of the connection. Bitcoin Core must already be installed, configured, and synchronized far enough for the wallet history you need. Use Sparrow’s official Bitcoin Core guide for the node prerequisites, authentication options, pruning limits, and rescan settings. Do not expose a node to the public internet just to complete this setup. Here is a useful [YouTube tutorial](https://www.youtube.com/watch?v=Bt7eBbqOol0\&t=2s) illustrating setting up Sparrow Wallet with your node. > Stop if Bitcoin Core is not synchronized, if you do not know whether the node is local or remote, or if you are about to copy authentication credentials into a screenshot or support request. Fix the node first, then connect Sparrow. ## Choose the right connection model Sparrow offers `Public Server`, `Bitcoin Core`, and `Private Electrum` under its `Server` settings. These choices have different privacy and operational properties. A public server can see wallet transaction queries. It does not receive signing authority, but wallet history and future activity are still sensitive. Direct Bitcoin Core avoids disclosing those queries to a third-party Electrum server and validates data with your node. Sparrow’s best-practices documentation also notes a trade-off: when Sparrow connects directly to Bitcoin Core, the node stores wallet public keys and balance information unencrypted for this use. A private Electrum server connected to your own node uses a full transaction index and is Sparrow’s preferred model for its advanced cold-storage design. It takes more infrastructure. Direct Bitcoin Core is a practical own-node route when you understand its metadata footprint and rescan behavior. “Own node” does not describe one fixed privacy state. A local node on the same computer, a node elsewhere on your private network, and a remote node reached across the internet have different network and authentication risks. ## Prepare Bitcoin Core Follow [Sparrow’s official Bitcoin Core connection guide](https://sparrowwallet.com/docs/connect-node.html) for the current prerequisites. The guide distinguishes local cookie authentication from remote connections that use a username and password. It also explains how pruning and wallet birth dates affect rescans. For a node on the same computer, local cookie authentication avoids maintaining separate RPC credentials. Sparrow needs access to the cookie file. Do not broaden file permissions more than necessary, and do not publish the cookie path. For a remote node, use strong, unique authentication and protect the network route. Do not open the RPC service broadly to the internet. Firewall it to the required source and use a secure private network or another protected transport appropriate to your environment. The official Sparrow guide describes the application settings, but network hardening remains your responsibility. A pruned node may be unable to rescan old wallet history if the required blocks are no longer available. Set an accurate wallet birth date when Sparrow’s procedure calls for one. Guessing too recent a date can omit earlier transactions; choosing a very early date may require more data and time. ## Configure Sparrow In your Node settings, navigate to Preferences, and open Configuration File, make sure you enter server=1 So within the bitcoin.conf you have server=1. Save and you will need to restart your Node. Now your Node is ready to be synced with Sparrow. ![](https://storage.crisp.chat/users/helpdesk/website/-/4/2/3/b/423bb8bf04277800/server1_1v7110p.png) Open Sparrow’s application settings and select `Server`. Set `Type:` to `Bitcoin Core`. Enter the details for the already prepared node. For a local connection, use the local authentication method described in Sparrow’s guide. For a remote connection, supply the host, port, username, and password defined for that protected node. Treat every endpoint and credential as sensitive. A screenshot should leave hostnames, addresses, usernames, passwords, cookie locations, and personal file paths blank. Do not reuse example values found in source code or documentation as if they were secure defaults. Select `Test Connection`. A successful result shows that Sparrow can communicate with the node using the supplied settings. It does not by itself prove that the node is fully synchronized, that old wallet history can be rescanned, or that traffic is taking the route you intended. The workflow below was executed with Sparrow 2.5.3 and Bitcoin Core 31.1 on an isolated local regtest node. Cookie authentication succeeded, and Sparrow reported Cormorant 2.5.3, batched RPC, protocol version 1.4, and the Bitcoin Core banner `/Satoshi:31.1.0/`. ![Successful local Bitcoin Core connection test in Sparrow 2.5.3](https://storage.crisp.chat/users/helpdesk/website/-/4/2/3/b/423bb8bf04277800/we-35cd7026ca-g03-02-core-test_7zmayq.png) > Stop if `Test Connection` fails. Do not switch to a public server merely to make the wallet appear operational if privacy is the reason for this change. Check node status, authentication, firewall rules, host and port, and whether the node is listening on the expected interface. ## Check that Sparrow is using the intended node After the connection test passes, return to the wallet and allow it to load. Confirm the selected server type remains `Bitcoin Core` and the endpoint is the one you intended. Check your node’s status locally. Wallet history should agree with records you have independently verified, without exposing those records to support. In the executed regtest (regression test) workflow, Sparrow connected to the configured local RPC endpoint at block height 106. The height independently matched Bitcoin Core’s RPC result. ![Sparrow connected to the intended local Bitcoin Core endpoint at height 106](https://storage.crisp.chat/users/helpdesk/website/-/4/2/3/b/423bb8bf04277800/we-abc4d42dcf-g03-03-core-conn_11wmjja.png) Test failure behavior deliberately while no urgent transaction is pending. Stop the node or temporarily block the connection, then confirm Sparrow reports the connection problem rather than silently moving to an unintended server. Restore the node and make sure Sparrow reconnects. This tells you what to expect during an outage. This failure drill was also executed. After Bitcoin Core stopped, Sparrow changed to a disconnected state and reported that it could not find the local cookie file. It did not silently switch to a public server. After Bitcoin Core restarted, Sparrow automatically returned to the same local endpoint at height 106. ![Sparrow showing the expected local Bitcoin Core outage stop condition](https://storage.crisp.chat/users/helpdesk/website/-/4/2/3/b/423bb8bf04277800/we-60f56c5381-g03-04-core-offl_1ey6oqy.png) If transaction history is incomplete, do not assume funds are gone. Check synchronization height, pruning, the wallet birth date, the selected wallet and account, and whether the node has the blocks required for the scan. Preserve the original wallet and backups while troubleshooting. ## Decide whether to use a proxy or Tor Sparrow’s server settings include `Use Proxy:`. Its FAQ explains that the configured proxy applies to external connections, with exceptions for specified local-network ranges. Onion destinations can also trigger Sparrow’s internal Tor behavior. Tor is optional rather than a requirement for Sparrow. A proxy changes the network path; it does not correct a wrong server endpoint or make a public server private. If the node is on your local network, confirm whether Sparrow’s local-network exception means that connection bypasses the proxy. If the node is remote, verify where name resolution and traffic leave your network. Broadcast routing also matters. Sparrow’s FAQ says that when Tor is used, Sparrow relays a broadcast over Tor through a public server. Otherwise, it broadcasts to the connected server and waits for that server to observe the transaction. If your policy requires broadcasts to go only through your own node, test the current behavior before relying on it. > Stop if a certificate changes unexpectedly, proxy behavior differs from your plan, or Sparrow connects to an endpoint you do not recognize. Investigate the change before opening a sensitive wallet or broadcasting. ## Maintain the connection Keep Bitcoin Core and Sparrow updated through their verified release processes. Monitor node synchronization and available disk space. Retest after changing RPC credentials, node location, firewall rules, proxy settings, certificates, or pruning configuration. Store non-secret connection notes separately from credentials. Do not place a complete remote-access recipe and its password in one document. Review server configuration before creating or broadcasting a sensitive transaction, especially after a long period without using the wallet. A private connection is useful only while it remains the connection Sparrow actually uses. Periodic outage tests and endpoint checks are more reliable than assuming the initial green result will remain valid forever. ## Related security guides * **Verify a Sparrow Wallet download before installing it** * **Protect and back up Sparrow wallet files and labels** ## Official Sparrow sources * [Connect Sparrow to Bitcoin Core](https://sparrowwallet.com/docs/connect-node.html) * [Sparrow Quick Start Guide](https://sparrowwallet.com/docs/quick-start.html) * [Sparrow Best Practices](https://sparrowwallet.com/docs/best-practices.html) * [Sparrow Frequently Asked Questions](https://sparrowwallet.com/docs/faq.html) * [Sparrow server settings in release 2.5.3](https://github.com/sparrowwallet/sparrow/blob/2.5.3/src/main/resources/com/sparrowwallet/sparrow/settings/server.fxml)