Transaction batching: cheaper fees, more disclosure

The recipients of a batch are now connected to each other. They share a transaction, and an observer can see that they were paid at the same moment from the same inputs. For a business paying unrelated suppliers, that connection is usually harmless and often already public. For a business paying staff, it publishes the payroll: the number of employees, the timing, and — if the amounts are not equal — the relative pay of each. For an individual paying several people, it publishes that those people are connected to the same payer.

The inputs are the more sensitive side. A batch spends a set of outputs together, so the common-input heuristic merges them into one cluster, which is correct here because they really do share an owner. The problem is that the cluster is now also connected to every recipient in the batch. If any one of those recipients is later identified, the identification reaches back through the transaction to the payer's entire input set. A batch is therefore a single point of disclosure for everything it touches.

There is a subtler effect on the recipients' side. If a recipient receives a payment in a batch and later spends it, the spend is linked to the batch, and the batch is linked to every other recipient. Two recipients who have no relationship with each other can end up in the same cluster through their common payer. This is the same transitive merging that makes any shared input dangerous, and it applies even when the recipients did nothing wrong.

Batching helps when the recipients are already publicly associated with the payer. A company paying its own operating expenses, an exchange processing withdrawals, a mining pool distributing rewards — in each case the relationship is known or discoverable, and the batch saves fees without disclosing anything new. The recipients' privacy is not improved by splitting the payments, because the payer's identity is not in question.

Batching hurts when the recipients are not otherwise connected. A person paying two friends, a business paying contractors who do not know each other, a donation processor distributing to several causes — here the batch creates a link that did not exist. The fee saving is real but small, and the disclosure is permanent. The correct comparison is not "batch versus no batch" but "batch versus separate transactions", and the separate transactions cost more precisely because they disclose less.

There is a middle path that some wallets take: batch only payments that are already linked, and keep unrelated payments in their own transactions. That requires the wallet to know which recipients belong together, which in turn requires labelling. The coin control page covers the labelling discipline that makes this possible, and the consolidation page covers the case where the inputs, rather than the outputs, are the thing being combined.