Sparrow Wallet privacy: Whirlpool is gone, so what works now?
Most people arriving at this page searched for Whirlpool or CoinJoin in Sparrow. The honest
answer comes first: that feature no longer exists in the wallet. The rest of the page is
about the privacy tooling Sparrow actually ships, ranked by how much difference it makes.
Whirlpool CoinJoin
Removed. The coordinator it depended on was seized; the integration went with it.
Any built-in mixing
None in official builds. Third-party forks exist and are not covered by this wallet.
What replaced it
Nothing single. Address hygiene, your own node, coin control, labels, Silent Payments.
Realistic ceiling
You can stop leaking new information. You cannot un-publish the old blockchain.
For several years Sparrow was the most comfortable desktop front end for Whirlpool, the
CoinJoin implementation built by the Samourai Wallet project. A CoinJoin is a
collaborative transaction: several people contribute inputs of an identical size and
receive identical outputs, so an outside observer cannot say which output belongs to
which contributor. Whirlpool ran that process in repeated rounds, and Sparrow gave it a
user interface, a premix and postmix wallet structure, and a higher gap limit for the
postmix account.
Whirlpool was never peer-to-peer. Like every Zerolink-style scheme it needed a
coordinator: a server that registered participants, collected the inputs, assembled the
round and handed back a transaction for everyone to sign. That coordinator was operated
by Samourai.
The founders of Samourai Wallet entered guilty pleas, and the coordinator and backend
servers were seized. This is where the practical consequence matters more than the
legal story: a CoinJoin client is useless without a coordinator to register with. Every
installation of Sparrow that still had the Whirlpool tab was pointing at infrastructure
that no longer answered. The integration was removed rather than left in place as a
button that could not work.
The third-party fork, stated plainly
After the shutdown a separate group, Ashigaru, published a forked Zerolink
implementation. It is worth knowing that it exists, because a lot of forum advice still
assumes Sparrow can mix and then points readers at it. Three facts are relevant. It is
not Sparrow, and the Sparrow project has neither reviewed nor endorsed it. It carries
whatever operational risk any small, young codebase handling your keys carries. And the
legal position of coordinated mixing varies considerably by jurisdiction, which is not
a question a wallet review can answer for you.
This site does not tell you to mix, does not recommend a coordinator, and does not walk
through installing one. What it will do is explain the tools that remain inside
Sparrow, because in day-to-day use they matter more than most people assume.
Why this matters for old guides
Any tutorial, video or Reddit answer that shows a Whirlpool tab in Sparrow predates the
removal. If a guide tells you to click something that is not in your build, the guide is
stale — not your installation. Check what version you are running against the
current feature set.
These are in order of how much they buy you, not in order of how interesting they sound. The
first one is worth more than the other five combined, and almost nobody does it first.
Stop leaking your addresses in the first place
A lightweight wallet cannot scan the whole blockchain itself, so it asks a server. That
request is the leak. To learn your balance, a public Electrum server must be told every
address your wallet derives — receive addresses, change addresses, the whole lot. The
operator therefore holds a complete map of your wallet, linked to the IP address that
asked, and can keep it for as long as they like. You have not lost your coins, but you
have handed a stranger your financial history.
Same wallet, same coins. The difference is who gets told which addresses to watch.
Running your own Bitcoin Core node, or your own Electrum server on top of it, removes the
third party entirely: your wallet asks a machine you control. Sparrow supports Bitcoin
Core directly and works with Fulcrum, ElectrumX, Electrs, Electrs-Esplora, EPS and BWT
over SSL and Tor. This is the change worth making first.
Connect Sparrow to your own node →
Tor is built into Sparrow and it is genuinely useful, but be precise about what it does.
Tor hides your IP address from the server you are talking to. It does not hide the
addresses you asked about. Query a public server over Tor and the operator still sees a
cluster of addresses arriving together as one wallet; they simply cannot attach your home
connection to it. Tor plus a stranger's server is better than no Tor. Tor plus your own
node is the actual answer.
Coin control and UTXO management
Bitcoin does not have balances, it has coins. Every payment you receive creates an
unspent transaction output — a UTXO — which is a discrete lump of value locked to one of
your addresses. The number Sparrow shows you as a balance is just the sum of those lumps.
When you spend, you consume whole UTXOs and create new ones, including change back to
yourself.
This is where privacy is won and lost. If a transaction spends two UTXOs at once, it is
public and permanent evidence that one person controlled both. Wallets that hide coin
selection do that merging for you, silently, on the day the fee estimator finds it
convenient. Coins from an identity-verified exchange withdrawal and coins from a client
who paid you privately should never appear as inputs to the same transaction, and the
only way to guarantee that is to choose the inputs yourself.
Sparrow exposes the UTXO set as a first-class view: you select the specific coins to
spend, and the transaction editor shows you exactly which inputs and outputs you are
about to sign. Its automatic selection uses Branch and Bound and Knapsack algorithms
when you let it choose, but the override is always there. Treat separate purposes as
separate wallets or at minimum separate, never-combined groups of coins.
The consolidation trade-off
Eventually you accumulate a drawer full of small UTXOs, and each one costs bytes — and
therefore fee — to spend. Consolidating them into a single larger coin is cheaper
forever afterwards. It is also an irreversible public statement that all of those coins
were yours. Both halves are true at once, so consolidate on purpose: pick a quiet
low-fee period, and only merge coins that already belong to the same identity. Never let
a fee saving be the reason two separate parts of your life become one cluster.
Labels, the cheapest privacy tool that exists
Sparrow labels every transaction, every input and every output. This looks like
bookkeeping and it is actually the foundation of everything above, because coin control
is impossible if you cannot remember where a coin came from. Six months from now, an
unlabelled 0.03 BTC UTXO is a coin you will spend carelessly. The same coin labelled
"exchange withdrawal, KYC, March" is a coin you will keep away from anything sensitive.
Get in the habit of labelling at the moment of receipt, not later. It takes four seconds
and it is the only moment you reliably know the answer. Then treat your label file with
the same seriousness as your backup strategy: your seed words reconstruct the money, but
only your labels reconstruct the context, and without context you will merge coins you
spent months keeping apart. Export them and store them with your other records.
Silent Payments (BIP352)
Address reuse is the most common privacy mistake in bitcoin, and it is usually caused by
convenience: someone puts one address in an email signature, a donation page or an
invoice template, and every payment to it becomes publicly linked. The alternative used
to be the awkward dance of asking a payer for a fresh address every time.
Silent Payments fix exactly that. You publish one static, reusable code, and the sender
derives a unique on-chain output from it, so two payments to the same code do not look
related on the blockchain. Sending to Silent Payment addresses arrived in Sparrow 2.3.0,
with hardware wallet support for it in 2.4.0, and Silent Payments receiving wallets
landed in 2.5.0 — capabilities that are part of the current 2.5.3 line.
The limits are worth stating. It solves reuse, not everything: the person paying you
still knows they paid you, the amounts are still public, and support across the wider
ecosystem is still uneven, so some senders will not be able to pay a Silent Payment code
at all. It also does nothing about the inputs on your side of a later spend, which is
why coin control still applies.
PayNym and BIP47 payment codes
BIP47 solves a similar problem in an older way. You and a contact exchange reusable
payment codes once, and from then on each payment between you goes to a freshly derived
address that nobody else can associate with the code. Sparrow supports sending and
receiving to PayNyms directly, which is convenient for recurring payments to the same
person.
The honest cost is on-chain. Establishing the relationship requires a one-off
notification transaction of 546 satoshis to your contact, per contact. That transaction
is itself a permanent public record that the two of you set up a channel of payments, and
it is paid for by a coin from your wallet. For an ongoing relationship the trade is
usually worth it; for a single payment to a stranger it is not.
Stonewall self-spends
Stonewall transactions are described in the official privacy guide as transactions that
appear to involve multiple parties while actually being a self-transfer, which adds
entropy to the transaction graph. Nothing leaves your control; the point is that an
observer analysing the structure cannot be confident about what happened, which weakens
the heuristics chain analysis relies on. Sparrow requires wallet funds greater than twice
the payment amount to construct one, because it needs the room to build the extra
structure.
Understand what this is and is not. It is deniability at the level of a single
transaction, not the anonymity set a working CoinJoin round produced. It costs fees, and
it does not repair a history that is already clustered. Used alongside disciplined coin
control it is a reasonable tool. Used as a replacement for the first item on this list it
is theatre.
Every tool above narrows what new information you publish. None of them reaches backwards,
and none of them touches the parts of the system that are not on the blockchain at all.
Chain surveillance firms
Clustering addresses is a commercial industry with a decade of heuristics, subpoena power
on the exchange side, and no obligation to be right. Their models improve whether or not
you are careful, and they operate on data that is already public forever.
The exchange already knows
If you withdrew to an address, the platform recorded the address, the amount, the timestamp
and your verified identity. Nothing you do in a wallet afterwards deletes that row. Your
first receive address is the strongest link in most people's chain, and it was created
before Sparrow was ever involved.
Transfer information rules
Regulated platforms increasingly collect and pass on information about where withdrawals
go. That happens on their side of the transaction and is not something a self-custody
wallet participates in or can opt out of.
Your own habits
Privacy is a habit, not a button. One careless consolidation, one address pasted into a
public forum, one spend that combines a work coin with a personal coin, and months of
discipline collapse into a single cluster. The tooling only rewards consistency.
Everything off-chain
Your operating system, your browser, your email, the courier who delivered your hardware
device. Sparrow's threat model stops at the wallet — see
the security page for the rest of it.
A workable routine
None of this requires expertise, only consistency. If you want a default that is far better
than average and takes no ongoing effort, it looks like this: run your own node so no
stranger sees your addresses; keep exchange-sourced coins in a separate wallet from
everything else; label every incoming transaction on arrival; publish a Silent Payment code
instead of a static address; select inputs by hand on any spend that matters; and
consolidate rarely, on purpose, when fees are low.
That routine has no mixing step in it, and it is still a substantial improvement on how
most people hold bitcoin. It also survives the next tool disappearing, which — as the
Whirlpool story demonstrates — is a property worth having.
Your 12 or 24 recovery words are the wallet. Write them on paper, never in a photo, cloud note or password manager, and never type them into a website, chat window or "support" agent — nobody legitimate will ever ask for them.
Questions people actually search
Does Sparrow Wallet still support Whirlpool CoinJoin?
No. Sparrow shipped an integration with Samourai's Whirlpool for several years, but the coordinator and backend servers that made it work were seized following the guilty pleas of the Samourai founders. A CoinJoin client with no coordinator to talk to is dead weight, and the integration was removed from Sparrow. Nothing in a current release will mix your coins.
Does Sparrow Wallet support any CoinJoin at all now?
Not in the official builds. A third-party project, Ashigaru, published a forked Zerolink implementation after the shutdown. That is separate software with its own maintainers, its own coordinator arrangements and its own legal exposure depending on where you live. It is not reviewed or endorsed by the Sparrow project and it is not something this site tells you to run.
What is the single most effective privacy change I can make?
Stop broadcasting your addresses to a stranger. A public Electrum server has to be told which addresses to watch, so its operator learns your entire wallet and can tie it to your IP address. Pointing Sparrow at your own Bitcoin Core node or your own Electrum server removes that leak completely. See connecting your own node.
Does Sparrow have built-in Tor, and is that enough?
Yes, Tor is built in, and it hides your IP address from the server you connect to. It does not hide which addresses you asked about. If you query a public server over Tor, the operator still sees a cluster of addresses arriving together — they just do not know whose home network it came from. Tor and your own node solve two different halves of the same problem.
Should I consolidate my small UTXOs in Sparrow?
Only deliberately. Merging many small coins into one input is cheaper to spend later, but the merging transaction publicly proves that every one of those coins belonged to the same person. Consolidate during a quiet, low-fee period, and only combine coins that already share an identity — never mix a KYC exchange withdrawal into the same transaction as coins you received privately.
What are Silent Payments and does Sparrow support them?
Silent Payments (BIP352) are a reusable address that does not create a public link when someone pays it twice: the sender derives a fresh on-chain output from your static code. Sending to Silent Payment addresses arrived in Sparrow 2.3.0, and Silent Payments receiving wallets in 2.5.0, which is part of the current 2.5.3 release line.
Is Sparrow anonymous?
No wallet is. Sparrow never asks you for identity documents, but the bitcoin you put into it usually arrives from somewhere that did. Chain analysis firms cluster addresses for a living, and the exchange that processed your withdrawal already recorded the address it sent to. Sparrow gives you the tools to avoid making that worse. It cannot retroactively unlink what is already published.