Bitcoin’s privacy guarantees come from its pseudonymous addresses. They contain no information about the person who owns it. It’s just a human-readable representation of the smart contract that locks the coins deposited. Linking a coin to an entity is only possible when more information can be deduced.

Say that Alice works for a company that pays her with Bitcoin. Since the company knows which address belongs to Alice, they could track how Alice spends her money if they want. That’s how KYC works. 

When Alice buys Bitcoin from regulated exchanges, she’s linking her identity with a Bitcoin address. If she later uses that Bitcoin to open a public channel on lightning, the exchange can link the channel with her lightning node. This happens because nodes broadcast a message linking the funding transaction with them when the channel opens.

If Alice had more public channels with non-KYC Bitcoin opened with that node, she would have lost the privacy of that non-KYC Bitcoin. That’s why coinjoins are important.

What is a Coinjoin

A coinjoin is a method for combining multiple Bitcoin payments from multiple spenders into a single transaction. The goal is to make it more difficult for outside parties to determine which address belongs to each recipient.

Let’s see how Alice could use a coinjoin to make it more difficult to track her coins.

She starts by withdrawing the coins from the exchange, as she would normally. Then she gathers with 4 of her friends and transacts with them. Each friend collaborates with an input with the same amount as Alice’s. Everyone also provides a new address to receive the money-back, making a transaction with five inputs and outputs. Since the exchange does not know which output address is Alice’s, it has to assume that there’s a one in five chance that a particular output belongs to Alice.

If Alice opens a lightning channel using the coinjoin transaction as the funding transaction, the exchange can’t assume that the lightning node is hers anymore.

Coinjoins eliminate certainty and replace it with probability. It increases noise and obfuscates the signal.

Coinjoins and Lightning Network – The Naive Approach

Having a coinjoin capable of supporting channel openings in coinjoin outputs would be nice, but unfortunately, there are some compatibility issues between coinjoin software and lightning node implementations. 

Nodes that intend to open a lightning channel need to communicate before Alice can send her coins to an address and there is a finite window where she can do this. To do this, Alice would need to use a coinjoin software that can fit the transaction’s registration, signing, and broadcasting within a 10-minute window. Without these guarantees, Alice is at risk of losing her funds.

Another issue is that most wallets use P2WPKH outputs whereas channel openings in lightning are implemented with P2WSH outputs. Having two different output types in a coinjoin transaction is not good because it reduces the possible interpretations of what happened in that transaction. If a coinjoin transaction appears highly uniform, it becomes more challenging to track someone’s UTXOs as there are many potential interpretations for the transaction.

Alice can make two transactions if she wants to use the available software. One that mixes her funds and a subsequent transaction to open the lightning channel. 

But this is an inefficient use of block space; the need for two transactions means more on-chain fees and more time until Alice can use her channel. Also, when the funding transaction is created, Alice removes her unspent Bitcoin from the coinjoin UTXO pool, which means that her Bitcoin can again be treated as a normal UTXO.

A Better Solution

A better solution would be coinjoin software enabling people to use the coinjoin transaction for multiple purposes. If people could share the same coinjoin transaction to open lightning channels, send funds to a cold wallet and pay others, then all participants would have more privacy as the possible interpretations for the transaction grow. An observer would not be able to tell which transaction inputs are being used to fund a lightning channel.

Another possibility is to put a cooperative channel closure inside a coinjoin. Unfortunately, the lightning protocol currently does not support this because constructing a coinjoin transaction is an interactive process with other inputs and outputs. The protocol to cooperatively close a channel can’t handle this interactivity.

If Lightning Nodes could specify a transaction for the channel closure instead of just an address, it would be possible to support channel-close coinjoins. Luckily, the Interactive-Tx BOLT proposal, which adds dual-funded channels support can be extended to allow construction transactions for closing a channel.

What can be achieved?

There’s an unrelated promised feature for the lightning network that if implemented can be used with coinjoin transactions to achieve a higher degree of privacy on the lightning network. That feature is called “Splicing”.

Splicing is a feature that allows lightning nodes to add or remove funds from their lightning channels. This was originally designed to fix the issue of having the total capacity of the channel fixed to the balances committed on the funding transaction. Splicing allows a node to do on-chain transactions with its committed balance without closing the channel.

The feature also relies on dual-funded channels and uses the same Interactive-Tx protocol mentioned earlier. This means that lightning nodes can interactively construct Bitcoin transactions with each other. It’s possible to have a channel that can remove or add funds at will. It can also splice a channel without changing its capacity.

All this can be used to create a coinjoin coordination mechanism that allows users to mix the funds committed to the lightning channel how many times they want, constantly changing the on-chain history of the channel in a steadily growing liquidity pool of mixed funds.

Concluding

A lot still needs to be accomplished to enable users to use coinjoin with Lightning effectively. Luckily, we have good developers working on awesome projects that strive to make the lightning network more private with channel coinjoins. Mutiny Wallet, for instance, plans to integrate on-chain and lightning privacy tools such as channel coinjoins. It’s definitely a project worth keeping an eye on.