Does Tor or a VPN Make a Bitcoin Transaction Private?

Open the wallet or node and find out what actually broadcasts the transaction. That single question decides which privacy settings matter, and it is the step people skip. A browser tab running through Tor tells you nothing about the wallet's own connection.

Find out what actually sends the transaction

Wallets broadcast in one of three ways: through the vendor's backend service, through a remote node someone handed you, or through a node you run yourself. Each has a different observer. A backend service sees your IP and the transaction together, a remote node sees much the same thing, and a node you operate sees the peers it gossips to. Identify which one you have before configuring anything at all.

If the answer is a vendor backend, no local proxy setting changes that path. The transport belongs to the vendor, and your trust in them is the actual decision.

Configure the transport in the program that owns it

For a node you run, the proxy settings live in the node's own configuration, not in the desktop environment. Bitcoin Core's Tor documentation covers proxy, onion and listen settings together, and they apply to that process only. A wallet pointing at that node inherits the node's connectivity, not your browser's.

A minimal outbound setup looks like this, and it is node-wide rather than per-wallet:

proxy=127.0.0.1:9050
onion=127.0.0.1:9050
bind=127.0.0.1
onlynet=onion

The first two are the outbound requirement; the bind and onlynet lines tighten everything else. After a restart, confirm what the node actually did rather than trusting the file. bitcoin-cli getpeerinfo reports a network field for each peer, and every entry should read onion if onion-only was the intent.

If you still see ipv4 peers in that list, the setting did not take effect the way you assumed, and the transaction is being gossiped over the clearnet no matter what the config file says.

Follow what an observer can still see

Tor hides your address from the peers you connect to and hides the destination from your network operator. It does not hide the fact that some node relayed a transaction at a particular moment, and it does not stop a peer from correlating what you relay with what you later ask for. A VPN moves the visible address to the provider and makes that provider one more observer.

The useful question is not which layer is stronger. It is which observer you are trying to exclude, and whether the configuration you actually deployed excludes that one.

Then look at the ledger, separately

Once mined, the transaction is public and permanent. Addresses, amounts, and the graph linking them stay available to anyone who cares to analyze it, and that record does not depend on how the bytes travelled. The Bitcoin privacy guidance is blunt about this.

Records outside the chain finish the job. A withdrawal from a service, an invoice, a message to a recipient or a reused address can tie a transaction to a person with no network observation at all. Changing the transport does not touch those records. That is why a single public-IP check is such a weak test: it measures one layer and reports on all of them.

Network-origin privacy and transaction linkability are different claims, and they need different evidence.

Check your own setup before you trust the label

Pick one real transaction and trace it through your own stack. Which program signed it, which program broadcast it, which peers saw it first, and what the destination address looks like on a block explorer. If any of those answers is a guess, the label on the tool is doing work that verification should be doing.

Use the supported configuration for whichever transport you chose, and check the connections the program actually opened. Then assess the ledger and the account trail on their own terms, because no transport setting will change them.