Encyclopedia How the network works · Entry 198
Your Bitcoin node versus a wallet server: who supplies the answers?
In this article
At a glance
Key facts
Trace the wallet’s actual connection
Electrum describes a client-server design in which a main server supplies wallet history and broadcasts the client’s transactions. The client verifies confirmed transactions through SPV, but the server can omit relevant history and is trusted for unconfirmed transaction information.
The server can also associate requested script information and observe the connecting network address. An encrypted connection protects transport; it does not prevent the server itself from seeing the requests it serves.
A private seed does not make queries private
Suppose a watch-only wallet queries one server about 30 derived receiving addresses. It sends no private key, yet the server can reasonably associate those addresses with one client. The signer remaining offline addresses key exposure, not this address-clustering issue.
Using your own compatible server can move that observation to infrastructure you control. Confirm the application has not silently fallen back to a public server.
A personal node still needs a trustworthy connection
Running a node somewhere does not automatically make every wallet use it. Check the wallet’s documented server or node configuration and its authentication behavior. Electrum’s protocol is distinct from Core’s administrative RPC, so the two interfaces are not interchangeable.
Protect access to the node and server host. Core warns that someone controlling the machine can compromise its reported results or privileged interface. Independent validation is useful only within a trustworthy end-to-end setup.
Direct answers
Questions people ask
Does a watch-only wallet protect my transaction privacy automatically?
No. It can avoid storing spending keys, but queries can reveal related addresses to the server. Spending authority and network-observation privacy are different properties.
Can a wallet server hide a transaction without forging a block?
Yes. Electrum’s documentation notes that a server can lie by omission, failing to mention relevant history. A valid inclusion proof for one transaction does not prove the server supplied every relevant transaction.
Inspect the evidence
The answer and key facts have stable claim links. These records retain the scope and qualification when reused.
A Bitcoin wallet needs a source of chain information, but that source is not always a full node running on the same device. Some wallets query a server for address history and proofs. A personal node, sometimes paired with a wallet-server index, changes who supplies those answers. It can reduce third-party exposure, but only if the wallet actually connects to the intended system and uses its results correctly.
Educational explanation. Product-specific behavior is scoped to the cited documentation, checked 2026-10-02.
Scope: Bitcoin · data through 2026-10-02. Verification: verified · 2026-10-02T19:29:20.637Z.
Link to this claimWallet server: Can learn the set of addresses queried
Scope: Bitcoin · data through 2026-10-02. Verification: verified · 2026-10-02T19:29:20.637Z.
Link to this claimSPV check: Does not prevent every omission by a server
Scope: Bitcoin · data through 2026-10-02. Verification: verified · 2026-10-02T19:29:20.637Z.
Link to this claimPersonal setup: May need a server layer as well as a node
Scope: Bitcoin · data through 2026-10-02. Verification: verified · 2026-10-02T19:29:20.637Z.
Link to this claimRevision history
- — First publication after primary-source research and separate automated verification.
Source register
Sources and references
Retrieval dates and locators are recorded individually.- Frequently Asked QuestionsElectrum
Electrum-specific sweep/import distinctions, seed recovery scope and address discovery.
Locator: Does Electrum trust servers?; Can I import private keys from other Bitcoin clients?; Can I sweep private keys from other Bitcoin clients?; What is the gap limit?; How do I upgrade Electrum? · Retrieved: 2026-10-02T18:53:56.378ZOpen source - Running a Full NodeBitcoin.org
Operational roles, synchronization, inbound/outbound connections and version-dependent resource guidance.
Locator: What Is A Full Node?; Initial Block Download; Network Configuration; Reduce Storage; Disable listening · Retrieved: 2026-10-02T18:53:56.154ZOpen source - WalletsBitcoin developer documentation
Wallet types, generated keys, deterministic wallets and offline signing.
Locator: Wallet Programs; Full-Service Wallets; Signing-Only Wallets; Wallet Files; Hierarchical Deterministic Key Creation; Loose-Key Wallets · Version / scope: Developer guide; historical implementation details require qualification · Retrieved: 2026-10-02T18:53:53.756ZOpen source - Hierarchical Deterministic WalletsBitcoin Improvement Proposals
Deterministic key derivation, backup scope and public/private child derivation.
Locator: Motivation; Extended keys; Security · Version / scope: Pinned BIPs revision · Retrieved: 2026-10-02T18:53:54.013ZOpen source - JSON-RPC interfaceBitcoin Core
Privileged RPC scope, authentication, local access and unencrypted transport limitations.
Locator: Introduction; Endpoints; Versioning; Security; RPC consistency guarantees · Version / scope: Bitcoin Core v29.0 · Retrieved: 2026-10-02T18:53:55.910ZOpen source
Research and drafting use AI assistance. A separate automated review checks claims against primary sources; no external expert or named human review is implied. Publication, substantive editing, source retrieval and verification are recorded separately. This version was independently checked by an automated reviewer on 2 October 2026.
Editorial method and correctionsDegrees of Satoshi editorial project. “Your Bitcoin node versus a wallet server: who supplies the answers?.” Published 2026-10-02; updated 2026-10-02. https://degreesofsatoshi.com/encyclopedia/bitcoin-node-vs-wallet-server/