# Understand Bitcoin servers and status

A wallet server can learn which addresses or scripts you query and can omit or delay data. A familiar balance does not identify the server that supplied it. Public-server privacy, private-node selection and network isolation are separate questions.

[Watch the overview: Understand your server](/watch#btc-overview-server-checks).

## Before you start

Record the application and selected server before testing. Electrum can maintain additional server connections even with automatic main-server selection disabled; use its documented single-server option when that is the intended policy. Its [official FAQ](https://electrum.readthedocs.io/en/latest/faq.html) explains the connection and privacy model.

## Understand public-server privacy

[Watch this step](/watch#btc-server-public-privacy).

1. A public history server can receive address or script-hash queries, learn transaction activity, and associate queries from the same connection. Some backends accept extended public keys, which reveal a broader account view. Public information can still be privacy-sensitive.
2. Your recovery phrase and private signing keys are a different boundary. A hardware wallet keeps signing separate, but it does not make the computer’s history queries anonymous. Never provide recovery words just to connect or synchronize a wallet.
3. Using a network proxy can change which network address the server sees. It does not erase the linkage between the wallet queries you send together. Avoid treating a proxy icon as proof that account activity is hidden.
4. Running your own synchronized node and compatible indexer moves these queries to infrastructure you control. It also creates an operational job: maintain synchronization, secure remote access, and verify which backend the wallet actually uses after a failure.
5. Choose the connection in each wallet deliberately and verify its status before relying on history. Avoid pasting account keys or transaction links into public support chats. For private troubleshooting, share only the minimum information needed for the specific check.

## Reject fake update messages

[Watch this step](/watch#btc-server-update-phishing).

1. In a historical Electrum attack, malicious servers returned transaction-broadcast error text that urged users to install a fake wallet update. The trick depended on persuading people to download malware. Bitcoin Core mining nodes were not automatically installing updates.
2. Electrum changed how those server messages were handled. That history does not establish that every modern Electrum installation is unsafe, or that another wallet is automatically safer. Keep the lesson focused on independent verification of software.
3. If a server response, pop-up, or support message demands an urgent download, stop the wallet task. Do not use its link. Open the project’s official site independently and check whether the requested action is documented there.
4. For Electrum, use electrum.org and authenticate the download signature with the expected signing key. For KeepKey Desktop, begin at keepkey.com/desktop. A matching filename or polished web page is not enough to establish the source.
5. Never enter recovery words into a downloaded repair tool or a server’s verification form. Record the error without exposing wallet identifiers, then investigate through trusted documentation. If software authenticity is uncertain, leave signing and wallet recovery paused.

## Read transaction status correctly

[Watch this step](/watch#btc-server-broadcast-states).

1. A transaction can be signed without being submitted, submitted without broad propagation, and observed before it is confirmed. Treat these as separate states. A transaction identifier can be computed before any server accepts the transaction.
2. After an intentional submission, read the actual backend response. Success means that endpoint accepted or recognized the transaction under its rules. An error may mean rejection, a connection problem, or uncertainty about whether the request reached the server.
3. On your own Core node, getmempoolentry can check whether that node has the transaction in its mempool. Its absence is a local observation, not proof that nobody else has it. Check the correct network and transaction identifier.
4. Check propagation through sources you deliberately trust. Querying a public explorer exposes the transaction lookup to that service. Block inclusion is a different check: inspect block and confirmation information from a synchronized backend, rather than a green submission message.
5. If status is unclear, investigate before creating another payment. Preserve the signed transaction and its identifier, check wallet conflicts and the intended recipient, and use the relevant troubleshooting path. Never interpret repeated clicking as a confirmation strategy.

## Verify the result

Inspect the connected endpoint and sync state, then distinguish prepared, signed, submitted, unconfirmed and confirmed. Compare a transaction hash with your own node or another source when appropriate, accounting for the privacy cost of an external lookup.

## If something fails

Never follow a server-supplied update link or enter recovery words to fix a connection error. Return to the software project’s authenticated download route. For private-node outages, use [the controlled failure check](/docs/guides/bitcoin/own-node#check-node-failure-behavior).

## Related

- [Choose your Bitcoin workflow](/docs/guides/bitcoin)
- [Address and account types](/docs/learn/address-types)
- [Device review checklist](/docs/desktop/verify-on-device)
- [Transactions and fees](/docs/learn/transactions-and-fees)