Merge Avoidance is an idea to improve the privacy of payments on Bitcoin and other similar blockchains. The basic idea is that instead of merging multiple outputs into a single transaction, you keep the outputs separate by sending multiple transactions for one payment. This keeps your outputs from being linked on the blockchain, making it impossible to trivially infer a common owner between outputs.
To the best of my knowledge, no one has implemented merge avoidance in a production cryptocurrency wallet. However, it is an extremely effective privacy strategy. It is practical to implement, requires no changes to any transparent blockchain, and makes it almost impossible for third parties to infer the amount of cryptocurrency you own.
On any transparent blockchain, all transactions are public. The only thing preventing the public from knowing how much cryptocurrency you have is that they do not know which transactions are yours.
However, people commonly leak private information about their transactions in two ways:
While many cryptocurrency wallets avoid reusing the same address, which would offer no privacy, they destroy their modest privacy every time they merge outputs to create a payment.
Suppose a user wishes to withdraw their entire balance from one wallet and send it to another. Most wallets will merge every unspent output into a single transaction, publicly linking all outputs. When you send a transaction to someone else, they can examine blockchain data to determine your full balance, at least at the time of the withdrawal.
The goal of merge avoidance is to address the second of two fundamental privacy issues:
The basic idea of merge avoidance is that when sending a payment, instead of sending one transaction, you send one transaction per output. Thus, a single payment consists of multiple transactions. This ensures that the information linking the transactions is not on the blockchain, so no one can trivially infer that the payment was created by one person or that these transactions are related.
The most likely reason no one has implemented merge avoidance in practice is that it requires a different paradigm for sending cryptocurrency. The current industry standard is sharing an “address” for receiving payments, typically the hash of a public key. This “address” lacks the technical properties needed for merge avoidance, as it would require sending to many different “addresses” at once, which is impractical with the current paradigm.
However, a simple solution is to use email addresses. If the user has a username and uses a wallet provider with a domain name, their address can look like username@example.com. The wallet provider, which can be the user themselves, can host an API at a standard location that the sender’s wallet can use to retrieve as many addresses as necessary.
The email address approach has other technical advantages, such as enabling a standardized endpoint that can provide arbitrary services beyond receiving payments. However, explaining all the additional advantages is beyond the scope of this article.
A simple implementation of merge avoidance would dramatically improve privacy in any cryptocurrency wallet. Most transactions sent by a user link outputs together, gradually linking all of their outputs over time. This enables anyone the user transacts with to determine the user’s full balance, or at least a large portion of it. By removing the linking information, it becomes much harder to infer the user’s balance.
However, additional privacy considerations remain. Which outputs is the user spending? If the user spends outputs in the same order they are received, this information can be used, with much more effort, to infer other transactions likely owned by the same user. Spending outputs in a random order makes this inference much more difficult.
Some criticize merge avoidance, claiming it burdens the blockchain by producing a larger number of transactions. This is not entirely accurate. Merge avoidance does not increase the number of inputs being spent, which is the most resource-intensive part of validating a transaction.
Suppose you have 100 outputs. You could merge all 100 outputs into one transaction, resulting in a transaction with 100 inputs and 1 output, or you could send 100 transactions, each with 1 input and 1 output. In both cases, there are 100 inputs and 100 outputs. The only difference is that the merged transaction has 1 output, while merge avoidance results in 100 outputs. However, outputs are not the resource-intensive part of a transaction—inputs are.
Thus, merge avoidance does not significantly burden the blockchain. For most blockchains, the modest increase in total transaction size can be addressed by paying a slightly higher fee.
No one cares about your purchase of an item worth only 1.00 USD. For very small transactions, the privacy implications of merging outputs is very little. Thus, for every user, it makes sense to have a threshold of amount below which they do merge outputs, because at those sizes the fees may not be worth the irrelevant gain in privacy.
I have previously covered my intention to implement merge avoidance in EarthBucks, and recently made a video about my intention to create a Bitcoin Cash wallet, which will also support merge avoidance.
My goal is to create a polycoin wallet in the near term that supports both EarthBucks and Bitcoin Cash and uses merge avoidance to maximize privacy. This will be the first implementation of merge avoidance in a production cryptocurrency wallet, as far as I am aware. As I will argue, this will make the EarthBucks wallet the most private cryptocurrency wallet for transparent blockchains.
After starting with EarthBucks and Bitcoin Cash, I will also add support for other cryptocurrencies.