Merge avoidance

The term comes from a December 2013 essay by Mike Hearn, written when input clustering was already the easiest way to map somebody's holdings. His proposal went further than careful spending: a payer would send several parallel transactions to several of the receiver's addresses, so no single transaction gathered everything. Today it survives as a discipline rather than a protocol.

How it works

The merge avoidance rule is negative, which is what makes it easy to follow and easy to forget. Never build a transaction whose inputs come from two coins you want to keep apart.

In practice that means treating your wallet as a set of jars rather than a balance. One jar holds coins withdrawn from a verified exchange account. Another holds coins bought peer to peer or received as payment. A third holds long-term savings. Each spend draws from exactly one jar, and if the jar has no single coin big enough, you either send less, send from a different jar, or accept that this particular payment merges two coins and plan for the linkage.

Hearn's stronger version put the work on the payer. Instead of assembling one transaction from three coins, the payer would broadcast three separate transactions to three addresses supplied by the receiver, so the payment arrived intact while nothing in the chain data connected the pieces. The payment protocol he was designing for supported multiple output addresses in a single request; it was deprecated years ago, and no mainstream wallet automates the pattern now.

The cost is real and it is paid later. Refusing to merge means keeping many small coins, and small coins are expensive to move: spending one native SegWit input costs about 68 virtual bytes, so at a busy 150 sat/vB that is 10,200 satoshis, half the value of a 20,000 satoshi coin. Push it further and coins fall under the dust threshold, where spending them costs more than they hold. Merge avoidance protects privacy by accepting a permanent fee tax and a floor on how small your coins can usefully be.

Where you see it

Merge avoidance shows up as a feature in the wallets that take privacy seriously.

Sparrow, Wasabi, and Electrum all show which specific coins a spend will consume before you sign, which turns an invisible merge into a visible choice. Freezing works as a blunt enforcement mechanism: freeze the coins in the jar you are not spending from and automatic selection cannot reach them. Some people go further and run separate wallets, or separate accounts under one seed, so that no single send screen can even see both piles.

The place it is not optional is after a coinjoin. Mixed outputs derive their privacy from being indistinguishable from other people's mixed outputs, and spending two of them together immediately proves they belong to one person, which discards the whole result. The same applies to the change left over from entering a mix: it stays separate forever, or the mix was pointless.

Merge avoidance vs CoinJoin

Hearn framed merge avoidance and coinjoin as alternatives in the original essay, and the comparison still holds. Merge avoidance is free, needs no counterparties, and attracts no attention, because the transactions it produces look like everyone else's. What it cannot do is help with links that already exist: it protects the future, never the past. A coinjoin does the opposite, spending real money and producing an obviously collaborative transaction in exchange for ambiguity about coins whose history is already public. Doing the second without the first is wasted money.